CHIP 2023-04 Adaptive Blocksize Limit Algorithm for Bitcoin Cash

CHIPs Standards Track
,
#81

The revisions to this CHIP have made it significantly easier to understand and clearly addresses all major concerns that I’ve seen raised in regards to this issue.

As a Fulcrum server operator, I endorse this proposal. I know I’d be able to keep up with operation costs even if we implemented BIP-101 instead, which would presently have us at 64mb block capacity.

I also recognize the urgency of solving this potential social attack before it becomes a problem again. I encourage adoption of this proposal for the November 2023 lock-in, allowing it to be activated in May 2024.

Like Jeremy, I also endorse this CHIP on behalf of Selene Wallet.

6 Likes
#82

(Ignore this, I got confused).

Summary

I support this CHIP but I do want to point out one thing:

Once this is deployed “pruned nodes” aren’t technically fully validating anymore until there is a blocksize commitment – a node can’t verify if a block is valid without knowing the historical blocksizes and can calculate the state of the algorithm.

The CHIP touches on it when discussing (potential) fast-sync schemes but I think more clarification is needed that it does impact the nature of some current nodes.

2 Likes
#83

But they are if they validated the history before pruning it - they will know the algo’s state and can resume from there, you only need algo’s state at any 1 block to be able to continue calculating the limit. Same with UTXO state tracking. So nothing fundamentally changes there, right? They have to build their UTXO state somehow - and while they do that they can work out the algo’s state too, and they can locally store the entire blocksize history while at it, since it’s a small dataset anyway.

It affects implementation of pruned nodes, though - in addition to UTXO state they’ll need to keep track of algo’s state at least some X blocks back to be able to recover from crash or something. That part we could highlight for implementers.

2 Likes
#85

If that was not yet somehow clear enough from my previous comments, I hereby officially endorse this CHIP.

2 Likes
#86

Post title updated as per author’s request.

3 Likes
#88

Likewise, I formally endorse this CHIP.

4 Likes
#89

I personally would like agreement and early implementation on at least two clients by November if at all possible.

Has there been any official statement or acknowledgement from BCHN, BU, or BCHD on this?

2 Likes
#90

I’ve been talking with them today and opened an MR as a result :smiley:

Pinged Josh (Verde) too, he’s busy migrating node’s DB from MySQL to custom solution, after which he’ll have bandwidth to resume work on fast-sync and check out this CHIP.

BCHD is busy getting up to speeed with CashTokens etc., I’ll reach out once they catch up.

Fernando (kth) has been busy with other stuff, too.

Not sure about BU, I had some talks with Andrew months ago and he informally blessed the approach, maybe @Griffith knows better? How’s dual-median been performing for your new chain? You guys wanna replace dual-median with this one while at it?

4 Likes
#91

An interesting real life example of miners not self-limiting block size when block propagation breaks down during high transaction volumes:

https://www.reddit.com/user/SignificantRoof5656/comments/15h9reh/pirate_chains_045_spam_attack_2_months_later/

[The spam]'s impact on mining was significant and immediately apparent. At times, up to 80% or more of the network’s total hashrate was dropped, but this number stabilized at approximately 60%. This “lost” hashrate was unable to keep up with the blocks from other miners, resulting in at least 3 distinct and competing chains which I was able to identify. At some points, some of the slow miners were able to catch up with the main chain, only to split off again soon after. The numerous forks relatively quickly re-established consensus after the conclusion of [the spam].

Pirate chain is a code fork of Zcash that permits only private shielded transactions. The block verification time per transaction is much slower than bitcoin’s.

2 Likes
#92

Nice find!

How do we avoid the risk for BCH? The maximum rate of change is chosen such to stay under original BIP-101 (What if too fast?) which is a good estimate for Bitcoin-tech growth of deployable capacity. Another blockchain like Zcash would need their own variant of BIP-101 with lower base and maybe lower rate.

Fees are the 1st line of defense against irrational use of the network, and I think Zcash / Pirate Chain simply had it too low. On BCH, one can not just run a “Free And Unscheduled Scalability Audit” (FAUSA)" as they did on Pirate Chain, because 1 satoshi / byte is not free. It is cheap for regular use, but it is not free, meaning introducing an artificial TX load at scale will still cost any single actor too much.

I’ll add some good numbers specific to BCH, which Jonathan Toomim laid out here. For those going to the original comment, his remarks about the algo are referring to an older iteration with 4x/yr rate limit at the extreme, which was deemed too fast, as it could more easily intercept the original BIP-101 curve.

The BCH network currently has enough performance to handle around 100 to 200 MB per block. That’s around 500 tps, which is enough to handle all of the cash/retail transactions of a smallish country like Venezuela or Argentina, or to handle the transaction volume of (e.g.) an on-chain tipping/payment service built into a medium-large website like Twitch or OnlyFans.

If you mine a 256 MB block with transactions that are not in mempool, the block propagation delay is about 10x higher than if you mine only transactions that are already in mempool. This would likely result in block propagation delays on the order of 200 seconds, not merely 20 seconds. At that kind of delay, Gorilla would see an orphan rate on the order of 20-30%. This would cost them about $500 per block in expected losses to spam the network in this way, or $72k/day. For comparison, if you choose to mine BCH with 110% of BCH’s current hashrate in order to scare everyone else away, you’ll eventually be spending $282k/day while earning $256k/day for a net cost of only $25k/day. It’s literally cheaper to do a 51% attack on BCH than to do your Gorilla spam attack.

If you mine 256 MB blocks using transactions that are in mempool, then either those transactions are real (i.e. generated by third parties) and deserve to be mined, or are your spam and can be sniped by other miners. At 1 sat/byte, generating that spam would cost 2.56 BCH/block or $105k/day. That’s also more expensive than a literal 51% attack.

Currently, a Raspberry Pi can keep up with 256 MB blocks as a full node, so it’s only fully indexing nodes like block explorers and light wallet servers that would ever need to be upgraded. I daresay there are probably a couple hundred of those nodes. If these attacks were sustained for several days or weeks, then it would likely become necessary for those upgrades to happen. Each one might need to spend $500 to beef up the hardware. At that point, the attacker would almost certainly have spent more money performing the attack than spent by the nodes in withstanding the attack.

7 Likes
#93

honestly… not sure… has not had a good go yet. not enough tx volume. we had some issues early on because it was not possible to adjust the blocksize higher for the first… year? (i forget the exact params) due to the algo median windows and the baseline block size that was configured for the dual median approach was too small (100KB). there was not enough baseline space to accommodate short term spikes in the network tx rate due to exchange output consolidation. when enough time had passed for the network to consider raising the maximum block size, the exchanges had already fixed all of the consolidation issues so the size still has not risen off of the baseline.

1 Like
#94

BCHN implementaion ongoing: Draft: Work-in-progress ABLA implementation (!1782) · Merge requests · Bitcoin Cash Node / Bitcoin Cash Node · GitLab

4 Likes
#95

I was ignoring this proposal as I believe it can never ever pass a public vote and I believed that bchautist would arrange that vote as Dreyzehmer did with cashtokens

Now apparently some guy started implementing something and bchautist started insulting me on Twitter after that I critized this nonsense CHIP

I prefer to talk in a public space as we should have clear documentation for the years to come, who talked what and when…

Please engage with my Twitter timeline, everyone is free to engage there and if anyone is banned for historic reasons then I will unban, of course I also ban everyone who insults others, check BitcoinMap, bchbeach or realbitcoinclub on Twitter

I hope we can continue ignoring bchautists attempt to make himself important w nonsense CHIP

So we can focus on actually creating the libraries necessary so that frontend devs can bring transactions to the BCH backend

Its time to create traffic, not another pointless blocksize debate that changes absolutely nothing and just drains energy and ressources from investors who pay devs

#96

This proposal already passed a public vote.

The proposal is being implemented as we speak.

And not “some guy” but one of the most active BCHN devs.

You are talking in a public space. This space is more “public” than Twitter. On Twitter random people or Twitter itself can censor and remove content. Here, content is practically never removed.

How about no? Did you come here to advertise your Twitter account? This place is not for advertisement, but development discussions.

If you banned people, that literally means that everyone is NOT “free to engage”. You just contradicted yourself.

Seems like you’re late to the party.

There is no debate any more. The decision has been made and has full consensus from relevant parties.

3 Likes
#97

That’s not what happened. I did insult you and you deserved the insult, but it was for another thing: I insulted your “Barrio” account because you were using the George Donnely drama as opportunity to throw FUD at BCH.

So you plotted to wait last minute to stir-up trouble, eh? And I will send the query to same list of stakeholders Jason did. Jason himself advised me to wait for BCHN to implement it and fork testnet before reaching out to broader industry, and Jason himself was supportive of this CHIP.

Everyone following BCH developments is aware of this CHIP and in support of it, and we will not allow some lone-wolf detractor using dishonest tactics to stand in the way of BCH future.

You used the “bchbeach” account to throw FUD at my post here then quickly blocked me so I can’t directly respond. I did see it and I did respond here.

Tough luck, lots of discussions already happened, good luck undoing that “PoW”:

I’m just a vessel for something that’s been started in 2016 with BIP-101 and with BitPay’s adaptive block size limit proposal based on median. Someone had to do the work, and that someone happened to be me. I stand on the shoulders of giants and I merely finished the work of others before me, to do what is necessary to remove the risk for BCH once and for all.

Signed TXIDs or it didn’t happen. How much did you donate? How about you ask actual investors what they think about this proposal?

8 Likes
#98

Full agreement on everything, but generally you don’t even need to explain yourself to some Twatter troublemaker.

His post should be regarded as trolling simply, there are no valid arguments present.

6 Likes
#99

This proposal is years in the making. BCA is carrying something over the goal line that many of us have been working toward even since before BCH split. BCA has achieved consensus from most if not all the key dev teams and every dev on those teams has had over a year of kicking this can down the road. Twitter is just one platform and it is not where real work gets done. The real work gets done when one dev reaches out to another and works to understand their issues and work together to come to consensus. Then the first dev goes to a third and the second dev goes to a fourth. And so on. That is how consensus has been built for this proposal.

Your primary complaint seems to be that devs should be working on other stuff. Attention: BCH split off from BTC because we believed that it was possible to achieve onchain scaling. A key missing piece – I’d say, THE key missing consensus piece – of this was to come up with some sort of approach that could potentially eliminate the need to do mass-coordinated upgrades. This plan does that. So, no, devs aren’t working on the wrong stuff. They’re working on the mission of Bitcoin Cash. You do support that mission, right?

I was ignoring this proposal

That was your call. At any rate, at this point you are too late to stop this proposal. Short of a detailed technical analysis complete with simulations that will prove beyond shadow of doubt that the proposal will fail badly. Do that, then come back and we will listen. Anything less, you’re wasting your time at this point.

Because BCA did the analysis, and the simulations, and the data-gathering, and the back-and-forth, and the rest of the consensus-building that you yourself claimed you ignored. Well. You can’t ignore something, then come back all hand-wavy starting drama with nothing more concrete to be concerned about than “devs should be working on other stuff.”

So if you have some specific gripe with this proposal, then please, go away, and come back with science.

Late edit: also if you think devs should be working on frontend libraries then please feel free to create a CHIP for the frontend libraries that you think devs ought to be working on, then go through years of consensus building for your CHIP. Because that’s where we’re all at here. That’s how it works.

7 Likes
#100

Forgot to link this here 3 weeks ago. General Protocols statement of support for the CHIP.

Also I think it’s worth re-iterating that there is no voting going on here. Every party chooses what to do independently. The escalation of support and stake is a signal, but not a vote.

9 Likes
#101

Indeed, however this state of affairs will become unmaintainable as BCH grows. In time people from different countries will create countless groups of people, and each of such group will have a different leader and all of these groups will not be sufficiently connected to what is happening here and on most popular BCH groups.

However, there might be another way.

I have noticed that due to BCH’s decentralization we have evolved into a loose collection of like-minded individuals that achieve agreement and synchronicity though closely arguing on instant media, like Telegram.

So the way out of this inevitable mess and contention that will be created in the future is to have people discuss in public frequently and directly (not over DMs) about the issues with the honest intention of actually achieving agreement of what needs to be done to make BCH the world money and retain these basic properties such as low fees, instant transactions, 21M coin limit etc.

Closed door meetings is what created Core, SegWit, 1MB and all that unwanted insanity.

During the public discussion it is possible to make it clear for everybody who is a bad actor and drive such bad actors out, just like it recently happened with George Donelly.

Sorry this turned out a little offtopic, but you inspired me to write it.

3 Likes
#102

That’s what we have been doing! Recall main points from this great article by @mtrycz, which I feel was an inspiration for the CHIP process, and certainly it was inspiration to me:

  1. Communicate early and clearly
    1a. Specifically: no surprises
  2. Brainstorm in good faith
  3. Don’t hold grudges
  4. Face disagreement gracefully
    4a. Reach out directly
    4b. Try a multiparty meeting
    4c. Check with the ecosystem
    4d. A split is always an option
7 Likes