cash-improvement-proposals VS ebaa

Bitcoin Cash upgrades through the CHIP emergent consensus system. Developer bitcoincashautist has published a new CHIP which aims to end the scaling debate by having the BCH blocksize scale via algorithm and is now implementation ready. For details on testing please see the CHIP.

One time increases in maxblocksize are an ongoing and unpredictable effort. While the CHIP process offers some stability and transparency to the effort, it nevertheless subjects the network to regular episodes of uncertainty regarding what some would consider its raison d'etre. Putting a predictable, sane plan into action reduces that uncertainty and increases confidence for all parties - users, businesses, infrastructure providers and developers.

"Our Dispute Resolution: We circumvent the need for one" which alludes to our permissionless nature, much of which is encapsulated in the CHIP process.

Along the way, we have the CHIP process to help keep us going in a good direction.

Yeah, I think I'll move that to a CHIP and see if we can get consensus for it

BCH ecosystem is unique in crypto that it booted even the reference client. Not just a random minor client that no one mines with. Now BCH ecosystem uses the CHIP process (some chips) rather than following a reference client or company. Huge difference. Also note that CHIP is a full on process, not just a technical document like BIP.

Bitcoin Cash upgrades through the CHIP emergent consensus system. Developer bitcoincashautist has published a new CHIP which aims to end the scaling debate by having the BCH blocksize scale via algorithm and is now implementation ready. For details on testing please see the CHIP.

Based on historical data, it would err on being too slow. Or, more to the point, of moving the block size limit in the wrong direction. Actual network capacity has increased a lot since 2017, and the block size limit should have a corresponding increase. Your simulations with historical data show that it would have decreased down to roughly 1.2 MB. This would be bad for BCH, as it would mean (a) occasional congestion and confirmation delays when bursts of on-chain activity occur, and (b) unnecessary dissuasion of further activity.

It's miner's own self-limits that would make us feel it in fees a little, the "hard" limit should never be the cause of fee pressure IMO, BTC users didn't feel the "hard" limit until end of '14. Here's an alternative history 2009-2017 with the algo: https://gitlab.com/0353F40E/ebaa/-/raw/main/img/fig2-alternate-history.png

Anyway, look at historical limit of 1MB... it wasn't being hit for a long time (the green curve didn't hit the limit, it was miners self-limiting their mined sizes), it started taking hits beginning of 2015, and that's when it should have started moving.

Yes, I get it, the "max produced" (now at 8MB) is the tool miners can use to negotiate size & fees with the market. BTC started having problems somewhere end of '14 start of '15 when first blocks at max_produced=max_accept started to appear. Later the frequency of such blocks increased and they couldn't raise the max_produced more in response to demand (it was 500kB, then 900kB, then hit the 1MB ceiling). The EB is firstly a DoS limit, ideally nobody would know it's even there, but it would prevent an adversary from announcing an obscenely-sized block and having nodes choke on it. Regular miners would just keep moving their "max produced" up in response to adoption, and the DoS limit would magically hover at some distance above that.

Yes, it would be a config parameter. I made a little tool that takes a list of blocksized and spits out a list of EBs, it's run with: