As a habitual gambler, I can tell you that your statistics do not win a game. Random is something that is next to impossible for a human to imagine. A coin toss with 1:1 odds could have a streak of heads for 100 flips. But statistics aside, my example of Litecoin would account for the reduced wait times, but it’s not about the time it takes, it’s about the expectation. If you plan to meet someone at 1 PM and they don’t show until 1:30, but you scheduled another appointment for 2 PM and need 30 min to travel, then it doesn’t matter that they were “only” 30 minutes late. What matters is that your expectations were not met. The shorter time differential you mention is valid, but in the crypto world where 0.5 second blocks exist, 1 minute is an eternity, unless that is the expectation. Really, the same can be true of 10 min, but that depends on the use case.
If, as the BCH Podcast likes to tout, BCH is the ‘world’s reserve currency’, it really needs to be reliably functional using primitive electronic transmission such as shortwave, where 10 min would likely be necessary. Maybe faster blocks could be brought on as an extension block, or sidechain? I sometimes wonder, if the timing of technology allowed, that the blocksize war could have been solved with the same, for BTC.
Several of us brought up the topic of resilience in the other thread. There is a section about it in the CHIP: System Rigidity and Catastrophic Resilience
For a HAM radio situation specifically, I think the main challenge would be the bandwidth, not the latency. Bandwidth and data usage is driven by network transactions per second. For latency, you can simply wait a few more confirmations.
For example, faster blocks could actually help you in a low bandwidth situation because security converges faster for a minority attacker scenario. Lets say you need 6 confirmations + 1 hour of network hash time to be safe. Well, with 10 minute blocks that could potentially take twice as much time and bandwidth to get those 6 confirmations + hash time whereas with 1 minute blocks it would be exactly 1 hour.
No it doesn’t. That’s nice if it is, but it’s cutting off our nose to spite our face to optimise for some kind of disaster-scenario apocalypse technosurvivability when doing so would hinder our ability to win in any other non-apocalypse (ie. reality). Some preppers build a perfect bunker in their house and die having never lived. Does the existing USD global financial system run on short ham radio? Of course it doesn’t. Be the winner in the real world, the 99.999% likely to occur world, rather than trading away your odds in that race to be the paranoid winner of a reality that is almost certainly not going to occur (and even if it does, we’ll all have far bigger problems).
https://bitcoincashpodcast.com/faqs/Other/what-if-the-internet-goes-out
Yes, 1 minute blocks is slow compared to many coins in crypto. But the real world has a diminishing returns floor. Between about 0 and 3 seconds, everyone sees things as “instant”. For that we have 0 conf. 1 minute is the best we can do on the confirmation requiring use cases (… for now), and the ticks system means we can trivially upgrade that in future as it becomes feasible.
Thanks for sharing my essay. I hope to make a good contribution to the technical debate around this CHIP, and I’m eager to see the results of the upcoming updates on chipnet.
The idea behind postponing is to give the community more time to understand the changes and their perceived benefits. This is the only proposal I know of that is not meant to solve an issue, but to mitigate the effects of the network’s rules and the algorithmic difficulty adjustment. Variance itself is not a problem for those who rely on 0-conf, and for those who require confirmations, waiting is already part of the process.
We would change a value that has been constant throughout Bitcoin’s history so that, in the best case scenario, a handful of users of faulty wallets, exchanges and services that rely on confirmations would benefit. For small amounts, DSProofs can deal with this. For bigger amounts, the number of confirmations required seems to align with the expected time to complete the transaction, so it already provides a safe margin for action. Instead, we could rely on the benefits of the existing 0-conf and BCH-native wallets and services.
The case for DeFi transactions is different. If the CHIP had been framed from that perspective, it would have made more sense to me, since it would mitigate (again, not solve) a concrete problem within the Bitcoin Cash ecosystem. As pointed out in the CHIP thread, if the mempool diverges a few seconds after each block, it stays divergent for about 99% of a 10-minute interval and about 91% of a 1-minute interval. Faster blocks shorten the wait until the next resync, but contracts would still be operating on a split mempool most of the time.
In general, I believe we should not solve a UX/UI problem by changing consensus rules.
Regarding this endorsement, it should be noted that the Bitcoin Cash community in Argentina is not unified on this issue. To the best of my knowledge, there were no prior consultations, tests or announcements. It is the opinion of some members, and it would have been better to present it that way. It would be more accurate to say that the community in Argentina is joining the international debate, and that both sides are actively represented.
Let me simplify my point, since none of the replies have addressed the point I am really concerned with.
Whatever the block time is, 1 min, 2.5 min, 10 min, is not a factor I’m addressing. I’m simply saying the actual block time needs to be within
+/- 1%-5% of it’s average.
Doing a transaction and EXPECTING it to confirm in a certain time frame can be frustrating when the average (expected) time frame triples or quadruples.
That is not possible with PoW mining 1-conf. Only with N-conf: higher N reduces total wait deviation from expected, which is why faster blocks offer benefits for e.g. 60-min target waits (60x1 is more predictable than 6x10).
Humans expecting 1 min will tolerate 2 min, but humans expecting 10 min will not tolerate 20 min. Our built-in tolerance is in absolute amount, not relative. +1 min is tolerable, +10 min is not. It’s just how our brains are wired.
Good point, noted. Very important this is made clear.
Approve / Neutral / Disapprove: Approve (one-minute blocks and November 2026 lock-in)
Name or project: Fernando Pelliccioni - Knuth
Statement:
This is an update to my earlier statement: CHIP-2025-03 Faster Blocks: gathering statements of support (and dissent) - #89 by fpelliccioni
I have completed the Faster Blocks implementation in Knuth, and my node has been synchronizing and validating blocks successfully on tempnet for several days. I have also reviewed the specification and found it solid.
Testing and review continue, but based on this work and experience, I now support the November 2026 lock-in as well.
Thank you to BitcoinCashAutist for carrying this proposal forward, to Jeremy for giving it momentum, and to everyone contributing to the specification, implementations, testing, review, and discussion.
Thanks, I got this from him through a private channel:
As an ecosystem supporter, a Fulcrum server operator, a founder of dropship.cash, and creator of whatiabitcoin.cash, I wholly endorse CHIP 2025-03 Faster Blocks for Bitcoin Cash.
After reading through the incredibly thorough discussions, having one-on-one talks with other service providers and developers, and through my own evaluations, I have no concerns with the activation of this CHIP nor with the infrastructure’s ability to continue operating effectively. Moreover, I believe this will be a massive improvement to our network, to average block times/difficulty adjustments, keep us further decentralized, further distribute mining, and greatly benefit end-user experience and app/contract performance.I fully expect, as devs have also mentioned, that projects I funded or contributed to will benefit greatly from this upgrade.
The substantial work put in by Calin Culianu and bchautist, and many others, is inspiring and demonstrates one of BCH’s many advantages over the competition: our collaboration and commitment. I can never truly express my gratitude.
Once locked-in, this upgrade will be added to Bitcoin Cash Network Upgrades | History & Future!
-minisatoshi (whatisbitcoin.cash)
This is my first post, I learned about this proposed change on X (twitter).
I’ve been using bitcoincash for payments on and off for a long time. I learned first about it on reddit (via the ironically named btc channel) but left reddit when most sane people did.
I’m a technical manager in a reasonably large company and from this perspective I see the change and I have to say I really hope smarter minds will reject faster blocks. While I’m not actually writing software, I have a long experience with managing those that do. And I have a nose for bullshit ideas as much as grand ideas and naturally awesome ideas. In reality the balance between those 3 is 70 / 20 / 10.
The faster blocks idea has a lot of obvious issues that are just hand waved away by the designers. Hoping that they won’t cause problems later? So whereas the first years of Bitcoin Cash were all about making sure it stays scalable for the next 20 years, faster blocks is ignoring all the wisdom and making it harder for everyone from the day this activates to get into BitcoinCash. Not to mention 20 years from now. The arguments that servers will do the heavy lifting is not very believable. That is just kicking the ball down the road, to become an issue later again.
When you expect 100% of the ecosystem to use (a handful of) servers, then you eventually end up with an ecosystem that can not work without such servers. And that means you need to re-assess your product. It no longer will be able to be nearly as decentralized as you want it to be. And that makes the proposal not just costly, it makes it a poison pill.
What products will you lose if you force the usage of servers?
How much lightning-like KYC danger does this introduce?
What about the political games that can be played if the cost of running a full server becomes too much for small starting companies?
This can’t be a good idea and the benefits are simply not there for people using BitcoinCash as money, for peer to peer PAYMENTS.
This is so low quality it is insulting, and the appeal to authority only aggravates me. Congrats, you win the worst critic of this upgrade cycle award!
It cuts both ways. I have a nose, too, and you wrote a lot of ignorant bullshit in the same breath.
They support it, as evidenced above.
Do you give ignorant “technical” opinions to your subordinates the same way you displayed here? I feel sorry for them having to work around you “managing” them.
Like what? Name 5 “obvious issues”. Nothing is hand waved, the CHIP (which you clearly didn’t even look at) is the product of multi-year research and hardening against much better critics than yourself.
Oh really? And how did it achieve that with flat 8 MB limit in '17 and flat 32 MB between '18 and '24. It was only in '24 when we forever solved the problem by introducing adaptive blocksize limit algorithm (“ABLA”).
How would it be making harder? You’re just asserting baseless claims. 0-conf will continue to work the same, 1-conf will get better. For whom will it be harder?
Which arguments? What “servers”? Did you know that in a P2P network every node is a “server”? Do you need help setting up an e-mail account?
Who is expecting that? Why would faster blocks require that? They don’t. You clearly did 0 homework on this subject.
Decentralized by what measure? Cost of running a node stays the same. Network throughput stays the same. How do faster blocks change the “decentralized” property in your mind?
This sentence is a marker of cheap AI slop.
Servers like what? Nodes, Electrum servers, block explorers? Same ones we already rely on to have smooth UX? We will lose 0 products.
What about flying elephants? “Full server”. What are you talking about? It’s called a node, a full node, and cost of running one stays exactly the same. It may even get cheaper due to reduced RAM requirements with faster but smaller blocks: ac-0353f40e / Faster Blocks for Bitcoin Cash · GitLab
Come back with some real arguments if you don’t want to eat the humble pie.
You are the owner of this proposal? Wow, you seem to really not want to hear criticism…
I’m not reading the whole post you made, just the part here quoted is rather telling. It attacks me personally (as opposed to the message) various times. It takes a point of mine and you select just one small part of it to make it look bad. Completely out of context. You seem to think the “bullshit” applied to you, that was not written. That was not the point made.
And then you come and literally break any sort of etiquette this site requires, remember I just signed up. I recently read them.
I’m afraid all your post has done is show very strong evidence that my worries are true. And if I were your manager, any and all proposals you made were going to be ignored until you learn to show better judgement…
Thank you for that reply, it was very informative.
Erm.
He is hearing your criticism right now.
You are not being censored, people are reading your criticism right now, including @bitcoincashautist
So what was your point again?
Thankfully you are not, and you needed to be put in your place for the entitlement and arrogance you displayed in your opening, not to mention concern trolling. You don’t “manage” me or anyone else here. Still waiting for those arguments. And I stand by my judgement that I should have flamed you exactly like I did.
This is extremely arrogant.
And I am an expert on “arrogant” because I can (actually: I could before I learned to do better) be super arrogant all the time.
You are not achieving much with your arrogant tone, just only because you are a manager.
Get back down to earth first and then we can talk, like reasonable men.
Implementation milestones have been reached:
- Bitcoin Cash Node (BCHN): Draft: Implement `CHIP-2025-03 Faster Blocks for Bitcoin Cash` (!2184) · Merge requests · Bitcoin Cash Node / Bitcoin Cash Node · GitLab
- Knuth: https://github.com/k-nuth/kth/pull/752
and tempnet has been operating without issues since Oct 15th.
Some responses were conditional on implementation state, so I’m pinging you all here hoping for an updated statement: @cculianu @albaDsl @Jonathan_Silverblood @kzKallisti @1KBCH @2qx @mainnet_pat @emergent_reasons (GP) @robchank
Statement on CHIP-2025-03 Faster Blocks for Bitcoin Cash, 2026-11-04
Introduction
General Protocols is a stakeholder in CHIP-2025-03 Faster Blocks for Bitcoin Cash (ac-0353f40e / Faster Blocks for Bitcoin Cash · GitLab) (FABLOUS CHIP). We believe that it is important that all changes to the consensus rules of Bitcoin Cash are done with sufficient research, extensive review and communication with the impacted stakeholders.
If research, review or outreach to stakeholders is found to be insufficient or not extensive enough, proposals should not move forward until the insufficiencies are addressed. It is not a requirement for Bitcoin Cash to ship upgrades at every lock-in or activation time, though it is desired to upgrade when upgrades are ready and in consensus.
All context from our previous statement (statements/CHIP-2025-03-Faster-Blocks-for-Bitcoin-Cash_Statement-2026-09-20.md · master · GeneralProtocols / Research / CHIPs · GitLab) remains relevant and this statement updates our position based on work that has happened between then and now.
Assessment of Risks
The FABLOUS CHIP owner and a group of stakeholders have done significant work to address what we perceived as insufficient engagement with two groups: 1) critical but mostly passive stakeholders such as miners, pools, exchanges, etc., and 2) non-stakeholding technical experts. Our opinion is that there has been sufficient feedback and consideration given by both groups without significant new issues coming to light, and we have not seen evidence of significant unconsidered risks.
Implementations
Since our last statement, two BCH implementations (BCHN and Knuth) have gained FABLOUS test implementations, extensive test coverage, and a 1-minute testnet has been under active use and testing. As expected, the implementations are significantly complex, reaching across many parts of the node systems, and deserving of great scrutiny. Based on the opinions we have heard from implementers, our opinion is that implementations are expected to be in a state of quality, maturity and review that is sufficient for deployment to the BCH network in accordance with CHIP process standards.
Statement
General Protocols formally APPROVES the FABLOUS CHIP for lock-in in 2026 and activation in 2027.