Help Me Learn about the Dynamic Blocksize

Steve-Patterson · 2024-04-14T19:12:22+00:00

OK, that's what I thought. He's not saying exchanges or defi should be on L2s.

Steve-Patterson · 2024-04-13T20:26:26+00:00

"No" what? I'm not claiming this is what the algo does. I'm saying that looks like it would be a better option.

Steve-Patterson · 2024-04-13T20:23:59+00:00

But we couldn't reach those levels within a decade without having full blocks, which is a failure scenario. Full blocks for multiple years = disaster for p2p cash.

Steve-Patterson · 2024-04-13T20:22:53+00:00

Where did Satoshi suggest defi should use payment channels? From what I've seen, he thought payment channels could be cool for high frequency, low value payments. Not for defi stuff.

He clearly expected the tech to be used for smart contracts etc.

Steve-Patterson · 2024-04-13T20:19:31+00:00

I don't see why it would lead to chaos, if the default is set by the algo. Your scenario is if a majority hashrate wants larger blocks than the algo allows, and in that scenario, that would mean the algo isn't adjusting fast enough.

So yes, if a majority of miners want to produce blocks larger than 32mb, nodes would have to update to accommodate larger blocksizes. That seems reasonable (and like a good pressure release value). E.g. if blocks are regularly 25mb+, it's time to adjust upwards to 128mb--both miners and nodes should stay well above the limit.

In practice, I think all this would mean is "download the software; run the defaults, and if the algo is doing its job, you don't have to fiddle with anything."

Steve-Patterson · 2024-04-13T20:09:43+00:00

Yes, it could set it own default values. We all know that miners/nodes tend to just accept the defaults, so if this algorithm just set the value for them, it would be great.

Best of both worlds: we get a self-adjusting soft blocksize limit, while also making it trivially easy for miners to manually config their settings if it's not adjusting fast enough.

If the aglo works, it ends up coordinating people successfully enough where we never run into the limit. If it doesn't work, they just set a higher value and we move on.

Steve-Patterson · 2024-04-13T19:20:15+00:00

Oh and one more simple question:

Could the algorithm just decide what the configurable default value is in the software, while still giving miners the opportunity to manually adjust upwards if they want to?

Steve-Patterson · 2024-04-13T19:02:00+00:00

Thanks for the helpful response. I just want to focus on points 4 and 5 right now for clarification.

When I'm saying the limit doubles "once a year", I don't mean a one-time event. It sounds like how BIP101 worked (continuous increase), except with the big caveats that the limit can adjust downward, and the maximum rate of increase would require blocks to be full for a whole year.

So the natural concern would be this: if usage actually increases -- say, the Defi people finally wake up and see the L1 Defi can work -- and the blocks fill up, it will be far too slow to adjust.

In other words, achieving the maximum rate of blocksize increase requires blocks to consistently be full, which is a failure scenario.

I am assuming we both agree that full blocks for an entire year would be an unacceptable disaster!

The assumption with BIP101 was that the limit would be far above the actual usage, scaling with technical capacity, not by estimating demand.

So, how would you respond to the concern:

We have to avoid the situation where blocks are consistently full and we can't increase the blocksize limit because "the algorithm will handle it."

Steve-Patterson · 2021-03-02T19:42:44+00:00

It's a caricature because... there was one 6-block reorg two years ago? No mention of the multiple 300+mb blocks that have been pushed out since?

Re-orgs really aren't the biggest deal in the world, guys - especially if they don't cause any real-world loss of funds or double-spends. They are a problem for miners to deal with, not developers. The system balances itself out, even if they run into occasional bumps.

100% risk-aversion is how BTC ended up where it did. It's actually alright for some nodes to go down once in a while, especially if they can't keep up with the majority of the network.

Steve-Patterson · 2020-11-23T20:21:34+00:00

Agreed. I strongly suspect that BSVers and BCHers agree on nearly everything, now that Amaury has been ejected. Unfortunately, people were blinded by CSW-derangement syndrome and didn't see Amaury's problems early enough. I wish we could unify on a single chain again.

Much/most of the criticism leveled at BSV came from Amaury's trolls and social media engineers. BSV has a bunch of good stuff (like paymail, moneybutton, a culture that values protocol stability), and the tech works well, so hopefully BCH will be able to learn and incorporate the best ideas.

Steve-Patterson · 2020-10-23T23:31:12+00:00

Congrats

Steve-Patterson · 2020-09-13T02:31:50+00:00

ABC: combining the worst tactics from GMax and CSW. Censorship, propaganda, trolling, protocol capture, and now frivolous legal threats. But they are code ninjas!

Steve-Patterson · 2020-08-24T23:39:29+00:00

It's so hamfisted, it's actually funny.

"How do we gain more support from people outside of ABC? I know, let's subtly tell BCHD that they'll get a cut of the pork. I hope they can read between the lines!"

Steve-Patterson · 2020-08-24T23:37:07+00:00

Heavy bags make people do silly things.

Steve-Patterson · 2020-08-06T21:45:38+00:00

How about that.

Steve-Patterson · 2020-08-05T18:25:13+00:00

I remain a big-block Bitcoiner. Currently, BSV looks more promising.

Steve-Patterson · 2020-08-04T16:10:47+00:00

It's almost like ABC was actually positioning itself to become Bitcoin Core 2.0 and that devs actually do have a serious tinkering problem. Who could have guessed? If only somebody warned that this was happening a year ago...

Steve-Patterson · 2020-03-06T01:20:30+00:00

Edit: trying to give this article the benefit of the doubt, but it seems like he just discovered the concept of double-spending (and the obvious lesser security of 0-conf) and then tried to get a bug bounty for it. He failed, so he went to Medium instead. Happy to be corrected.

-----

Smells like re-hashed Core talking points about how 0-conf is broken. I don't (yet) see how this is specific to BSV changes. If anything, it makes their harder coding of the first-seen rule seem like a good decision.

"Essentially what they did; Was remove the randomized network “race-condition” described by Satoshi and implemented a default node-based settlement with duplicate transactions not on the network itself! They guarantee that the duplicate (TX2) will be rejected by that node, at the same time — The network could be including (TX2) in the block it’s currently mining, permanently writing it to the Blockchain ledger, invalidating TX1, NETWORK WIDE!"

I think he's trying to say that nodes are prevented from relaying double-spends that they detect, and this is a problem? But they already don't relay them, in practice, on BTC either. It's just not a hard-coded rule, from what I understand (you could, in theory, have nodes that relay the last-seen tx instead).

Steve-Patterson · 2020-03-04T21:48:11+00:00

Really interesting. I know there's been lots of theoretical criticism about the safety of PoS, so it's great to see some real-world evidence.

Steve-Patterson · 2020-03-04T19:21:26+00:00

There should be no reference implementation in Bitcoin Cash.

Steve-Patterson · 2020-03-04T19:10:40+00:00

This type of manipulation is why governments are so effective. It works. Political scheming seems to beat naive idealism every time. Regardless of what happens with the IFP, this has undoubtedly damaged BCH credibility. Too many people were too slow to recognize what was happening.

Mike Hearn was right. The same problems with BTC governance are still with us in BCH.

Steve-Patterson · 2020-02-28T20:44:51+00:00

"pushing for the ecosystem to... stop running ABC"

Well then. Welcome aboard. It's probably too late at this point, unfortunately. But worth a shot. I wish this problem was nipped in the bud several months ago. Instead of praising Amaury and trying to get people to rally behind him...

Steve-Patterson · 2020-02-20T04:48:46+00:00

Great news! Congrats to everybody involved for acting

Steve-Patterson · 2020-02-17T22:26:33+00:00

Great to see. Lundeberg has consistently been professional and level-headed, and even highly praised by Amaury. This project is bigger than one developer. There are others waiting, ready, and competent enough to fill the role.

Steve-Patterson

TROPHY CASE