I feel you but you’re reading it wrong, as if it’s somehow indicative of not believing we can scale. Sure we can, but everyone needs resources to do it, from where will those come? Who’s gonna invest resources way ahead of the network actually getting some traction and increased economic value? You think a fixed schedule will force people to do the work? I was triggered by your guarantees . There are no guarantees, best we can do is have faith in incentives and ensure that once incentives are there (network usage growing) that we won’t get stuck due to a stupid line of code.
Guys, polite reminder.
You’re in bikeshedding mode again.
We should really just get this done. Like really.
1 Like
We worked it out in PMs, I added this paragraph to CHIP’s “evaluation of alternatives”
It will likely become reasonable to increase the “stand-by” capacity simply because it will become trivial to support it even if it will be orders of magnitude underutilized.
After all, that is the current state (few 100 kBs utilized of available 32 MB).
However, it is impossible to predict what will be trivial in the absence of network growth, and the argument here is that it should be left to good judgement of network participants, e.g. some future CHIP proposing to lift the floor value to 64 MB in 2028, instead of being delegated to a fixed schedule.
To code a fixed-schedule now would be scope creep from my PoV. The CHIP never set out to predict what people will do - but instead to react to what they’re actually doing, remove the risk of dead-lock, and count on the incentives of TX load “pushing” people to keep upgrading, while still being slow enough at the extremes that it would be manageable.
1 Like
agreed with above & moving forward
my apologies to the group for being disruptive
1 Like
No need to apologize. You can be more disruptive next year.
We do not need a perfect solution right now. We only need a very good solution.
Once it is “locked in” in the brains of the populace (and especially miners) as a default way forward, we can bikeshed improvements ad infinitum.
2 Likes
This morning I have reviewed the complete CHIP and suggested a number of typo / grammar corrections to @bitcoincashautist.
My two non-typo points that I raised were:
- I would love some numbers demonstrating that new fast sync requirements won’t be an issue for light wallets (very relevant for Selene Wallet). Data addition should be trivial for this, but it would be worth having some clarifying maths to back it up. As we’re already seeing enthusiastic Selene Wallet users in Venezuela with very poor download speeds and so sync times are a critical issue for them - obviously this is something we don’t want to compromise going forward.
- I think the part of the CHIP that goes into “borrowing” future capacity is a little unclear and could be rephrased.
That said, I think there’s been an immense amount of quality work done on this proposal, and I am in full support of it.
I agree heavily with @ShadowOfHarbringer’s points about social consensus, we shouldn’t let perfect be the enemy of the good (or in this case, already very very good) & activating this CHIP in the 2024 upgrade would be a massive step forward. Delaying it for a year seems foolhardy, it seems pretty much everyone is onboard with an algorithm in the first place so it’s much better to be thereafter discussing a change to the algorithm rather than whether or not to do an algorithm and if so which exact algorithm.
@Jessquit it’s not exactly a topic for this thread, but I’m not so much a fan of the “Untethered” idea. I think the marketing play on words is fine, but I am averse to this kind of ““limitless”” messaging because it strongly reminds me of the endless BSV arguments and opinions which always seem to come down to “Well now the Bitcoin blockchain has been UNLEASHED! And you will see the TRUE power of Bitcoin/the free market now that we have UNLEASHED it with no blocksize/data limits/consensus changes etc.”. Their arguments always come down to some naive lack of engineering tradeoffs or un-nuanced belief in the supposedly endless powers of “free markets”. In my mind, their advocacy always turns into what sounds like some kind of Dragon Ball Z villain (“haha, my true powers have been unveiled, NOW you’ll see what I can do”). They’ve been “unleashing” BSV for years, and it’s not impressing anyone lol. So I think we should avoid marketing BCH in any style reminiscent of that, because it tends to attract loud and opinionated people with a binary and uneducated view that any kind of sensible engineering is an affront to their free market sensibilities. But that’s a separate discussion to have, and I like that you’re thinking up new promotional ideas - let’s workshop some of this some more in another venue.
1 Like
Oh, just discovered “Light wallets” affected by this change means full nodes syncing from a UTXO committment backwards, not pruned nodes and not SPV. That fixes my Selene Wallet concern entirely, hopefully the spec can be updated to avoid any confusion there.
2 Likes
That’s fine, nobody is required to use the idea. It’s there for people who find it useful.
1 Like
Proposed final draft of Executive Summary online now:
3 Likes
- Done
- Done
- In progress
- Todo
- Todo
- Todo
“CHIP-2023-04 Adaptive Blocksize Limit Algorithm for Bitcoin Cash” (ac-0353f40e / Adaptive Blocksize Limit Algorithm for Bitcoin Cash · GitLab) is implementation ready. Note that CHIP title has been updated.
If anyone want to have a go at test implementation or just review the CHIP and state approval/abstention/disapproval activating the CHIP, now is the time!
To get a feel for how it works, I suggest check out the risks section first:
The CHIP has reference implementations both in C and C++, and a simple test suite that locally generates simple .csv test vectors, covering full range of inputs to the algorithm.
4 Likes
My endorsement post:
Blocksize Algorithm CHIP endorsement
I (and The Bitcoin Cash Podcast & Selene Wallet) wholly endorse CHIP-2023-04 Adaptive Blocksize Limit Algorithm for Bitcoin Cash for lock-in 15 November 2023. A carefully selected algorithm that responds to real network demand is an obvious improvement to relieve social burden of discussion around optimal blocksizes plus implementation costs & uncertainty around scaling for miners & node operators. There is also some benefit to the community signalling its commitment to scaling & refusal to repeat the historic delays resulting from previous blocksize increase contention.
The amount of work done by bitcoincashautist has been very impressive & inspiring. I refer to not only work on the spec itself but also on iteration from feedback & communicating with stakeholders to patiently address concerns across a variety of mediums. Having reviewed the CHIP thoroughly, I am convinced the chosen parameters accomodate edge cases in a technically sustainable manner.
It is a matter of some urgency to lock in this CHIP for November. This will solidify the social contract to scale the BCH blocksize as demand justifies it, all the way to global reserve currency status. Furthermore, it will free up the community zeitgeist to tackle new problems for the 2025 upgrade.
A blocksize algorithm implementation is a great step forward for the community. I look forward to this CHIP locking-in in November & going live in May 2024!
Jeremy
3 Likes
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
(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
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
If that was not yet somehow clear enough from my previous comments, I hereby officially endorse this CHIP.
2 Likes
Post title updated as per author’s request.
3 Likes
Likewise, I formally endorse this CHIP.
4 Likes
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
I’ve been talking with them today and opened an MR as a result 
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
An interesting real life example of miners not self-limiting block size when block propagation breaks down during high transaction volumes:
[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