Of what I understand, Amaury is right now considered “stakeholder” in the 1-min block CHIP.
So if that “stakeholder” came here right now and either approved or disapproved of this upgrade, would you
?
I would do 4) and perhaps 1) too. What would you do?
Now I retry the same question with
I wonder what is your opinion in this matter?
Lol I would do “2.” I would note Amaury’s opinion, review it for any valid points (and request those be factored into the CHIP), dispute it if important on points where I disagreed or were not valid. If it wasn’t that substantive, I would probably ignore it.Same thing I would do for any other stakeholder.
I would also do the same for Michael Saylor & Adam Back.
If your strategy for handling stakeholder opinion submissions is to try & censor them and attack the stakeholders instead of either appreciating or debunking their actual arguments & submission as necessary, well that’s fine you can do whatever you want, but it’s not going to be very effective & it will just get your opinion devalued for being full of ad-hominems (no matter how “bad guy” the commenters are) in the same way as stakeholders who submit poorly researched complaints.
If 90% of users are against us I want them to go away or whatever theymos said 
BCH is for everyone. If Amaury or Adam or Saylor or whoever has an opinion we take it on the same basis as everyone else’s opinions.
If an enemy is so kind as to let us know the peril we are walking into with hard / impossible to refute logic, we should thank them, and change course accordingly.
I personally endorse CHIP-2025-03 Faster Blocks for Bitcoin Cash.
Ten-minute blocks and a variance that often sees much longer waits are below the expectations of the masses. Permissionless money is the USP, but the UX needs to be much closer to fiat for any meaningful success of global money. People place convenience very highly on their priorities, and BCH should aim to meet that as best as possible while remaining decentralised permissionless money.
One-minute blocks would cut that wait sharply and give a more modern first confirmation that many sites and services that cannot or do not support 0-conf transactions. The implementation offers exchanges and BCH services more granular control over their own security rules. I am convinced that for platforms that require confirmations, this extra control will lower waiting times in practice rather than only on paper.
This endorsement depends on the software being ready for deployment, and see not urgent rush to deploy at the expense of careful node work, review, and testing.
I also want to recognise the author, bitcoincashautist. The research, the written CHIP, and the effort to reach stakeholders are serious, detailed, and in the open. That is how a change of this size should be done.
Bitcoin Cash is in a hard race, and competition, especially from fiat and centralised chains, has never been tougher. BCH has to keep adapting and improving. Although I think the larger part of that battle now lies in tooling, services and products rather than on the base layer, there are still several key improvements that can be made to improve BCH as sound money, and faster blocks is one of them.
BCH also has to protect the stability that global sound money needs. This CHIP, handled with that balance, is a step forward. Thank you to everyone who has argued for it, argued against it, and stayed in the process with care and signal. This is how healthy consensus is formed.
This is my personal endorsement and does not represent any other organisation or project I am affiliated with.
ViaBTC Customer Support replied on 28th September 2026 to BCH Alliance reach out regarding CHIP-2025-03
Dear Elliot Price ,
Thank you for contacting us.
We have reviewed the proposal and support this initiative.
Please keep us updated, and feel free to reach out if there are any dedicated testnets or testing tools available for pool operators in the future.
Kind regards,
ViaBTC Customer Support
Strongly agree, as long as there are problems to fix and improvements to be made an upgrade once per year is mandatory IMO.
Approve / Neutral / Disapprove: Approve (one-minute blocks); Neutral (November 2026 lock-in)
Name or project: Fernando Pelliccioni - Knuth
Statement:
As a Bitcoin Cash user, I support one-minute blocks: I don’t just want them; I need them.
I understand the idea behind “If it ain’t broke, don’t fix it,” but in this case, it depends on what we consider broken and from whose perspective we evaluate it. When I can use zero-conf, the experience is excellent. However, there are situations and services where zero-conf is unavailable or not accepted, and the experience can become deeply frustrating. From that perspective, there is a real problem worth solving.
One-minute blocks do not compete with zero-conf or seek to replace it. They complement it and significantly improve the experience when we must rely on confirmations.
My support reflects a clear need as a user, not an independent technical validation of the implementation. I have not yet reviewed the BCHN implementation or begun implementing the change in Knuth, so I cannot assess its current state. If Calin says it is not ready yet, we should take that seriously. With the lock-in so close, the time available to complete, review, and adequately test the change appears very limited.
I strongly support the move to one-minute blocks, but I remain neutral on the November 2026 lock-in until the implementation is complete and adequately tested.
At least you recognize him as an enemy, this is something some other people lack apparently.
You probably do realize that whatever he says can be a manipulation aimed to disrupt the project?
Possibly fatal mistake.
Oh yeah! Let’s let a fox into the hen house.
You know what ALSO could be a possibly fatal mistake?
Constant paranoia & self-protective isolation out of trauma & fear. BCH becomes known as a scared project which can’t even handle the vague involvement of former community members, too fragile to accept outside criticism and too stupid to differentiate between useful & non-useful feedback. BCH never gains any serious adoption & dies from lack of transactions as block reward runs out.
I guess we’ll just have to agree to disagree which risk is more likely.
What you should reflect on is: People generally (as a rule) do not change their ways. Super rare exceptions of course exist, assuming there is some kind of pivotal event in the life of a person. An event such as:
No such thing happened here. Amaury tried to take over the project, forked off and still made money on it.
Punishment was never applied. So there is really no reason for him to “change his ways”. He is not only “guilty”, but he is still convinced he was in the right.
The only thing he is capable of right now coming here is trying to destroy us, I don’t see any other way this could play out.
There exists no factual data that would prove your argument (community being perceived as “weak”, because it censors enemies) and there exists a lot of factual data that supports my argument (as in: people convicted of murder and fraud coming out of prison and commiting fraud or murder again), so…
I would say what I say is based on reality and what you said is based on vivid imagination and nonsense.
Can you take this somewhere else, please?
I would say we should purge them in fire.
Why the hell would we tolerate known enemies here?
What is the actual reason?
You seem to have this weird preconception that everybody should be respected the same way. So evil people that mean to kill you should also be respected the same way? No, I say they should be killed, in self defense.
This is not some kind of “feel good” kumbayah project, this is a seriously political project that is, and will be, in constant danger of being attacked and taken over, especially by known enemies.
What is the deal here? Do you not realize that not all people want you to live happily and some people are out to fuck you over and destroy you?
How the fuck are you gonna defend from them other than by isolating from them. By inviting them into your house?
Where does this naive nonsense preconception that everybody is a “good guy” and everybody should be respected come from? Especially that you ALREADY KNOW that “everybody” tried to kill you once?
What is the deal here?
OK, sorry for ruining your CHIP discussion, I will move into a separate topic.
A reminder that up-to-date stakeholder opinions from this thread & elsewhere are being tracked & visualised on Consensus.cash.
“Conditional approval” now added as a new status in response to this new category of endorsements.
Considering conditional support as support, the CHIP seems to have strong support. But on the other hand considering conditional support as not-support, or support needing work to be done to be convincing, there’s quite a lot still needed.
I am personally finding it quite useful & informative to have this kind of data available in a way that it wasn’t previously.
I disapprove mainly because the implementation is not ready, but I’m also wondering if we are giving up too much of our safety margin with 1-min blocks.
Benefits The user experience benefits of a lower block time, such as reduced confirmation time variance when interacting with centralized exchanges, are easy to understand. The trade-offs/downsides on the other hand are technical & economic and harder to understand and quantify.
Readiness of the implementation I believe the BCHN implementation of this CHIP got started a bit late considering its complexity. It touches many different parts of the codebase including things that may require system level testing. Since Calin is voting against lock-in it is a no-go for me.
Rigidity of the system / safety margin It seems to me that as the block time is lowered the rigidity of the system increases (in some respects). This makes it more sensitive to catastrophic events. Similar to how, in the old allegory, the oak falls in a storm while the flexible reeds stand. Since we want Bitcoin Cash to last hundreds of years and beyond it will face many “storms”. If a storm results in large block propagation times (relative the configured block time) for an extended period, the economic pressure on miners may lead to Bitcoin Cash splitting into two or more coins permanently.
The block propagation time has a fixed latency term and a term dependent on the block size. The fixed term is the one that matters when comparing the safety margin of 1-min blocks vs 10-min blocks, since a fixed term that is a detrimental share of one minute is a 10x smaller share of 10 minutes. In case of a catastrophic failure of for example key transoceanic cables, rerouting of packets and router queuing can lead to an increase in the network latency term (increasing the RTT). If remaining network links get overloaded with the additional traffic, packet loss will increase and in turn add TCP slow-start and retransmission latency. In addition, I think that getblocktxn/blocktx can be seen as a node level latency term for block propagation, since the size of this request, and thus its processing time, depends on the transaction delay and the overall transaction rate, not the configured block time. As network/protocol latency increases and effective bandwidth degrades, the processing time for this request increases. This term also grows as Bitcoin Cash scales to handle larger traffic volumes.
I believe we are giving up margin for catastrophic events by lowering the block time and the question is how much of it we are willing to give up and how to position ourselves relative other chains. Just because we can operate flawlessly with a given block time for an extended period of time does not mean it is the right choice for long term success. Staying relevant compared to other chains in the shorter term is an important factor to consider too, as there is a bit of a (chicken) race between chains to lower block times. One should keep in mind though that similar to Poisson-distributed blocks, disasters can arrive at any time.
(Jason discusses existential risks here: https://x.com/bitjson/status/2000944904394920082)
Reversibility of the change From a technical point of view this CHIP is reversible but socially it will be difficult and costly to later raise the block time as users/businesses may have come to depend on it.
Thanks to bitcoincashautist and Calin for their excellent work!
I can understand the cautiousness and I appreciate you acknowledging the benefits.
Readiness of the implementation: I’d gently push back on reading Calin’s “for now” as a no-go: it isn’t. He’s the one implementing it, and he stated the exact conditions that flip his vote: code over the finish line, more testing, and ideally an AI-assisted review pass (@dagurval has already provided one, BTW, which helped me close some gaps on the CHIP side). That’s a checklist to clear, and we’re working through it.
We’ll see where we are in a month, which I expect to be close to the go-or-no-go decision. I’d hate to see it spill into '28, because, apart from opportunity cost of missing the window, every CHIP carries a meta-cost that the whole ecosystem pays: as long as it’s live, it takes a share of everyone’s attention: across the forum, Telegram, Twitter, podcasts, dev calls. That attention is one of the scarcest resources BCH has, and it’s consumed whether the CHIP activates or not. Dragging it out doesn’t just delay this one upgrade; it crowds out whatever other CHIPs people would otherwise be working on for '28.
It may seem we’re tight because of the Nov 15th Schelling point, but really all we have to do before Nov 15th is fork chipnet with a frozen-specification code-build. It should pass quality tests, but even if some bugs surface later we have at least a few months to really iron them out (past precedent: signed release was in January). I can’t speak for maintainers, these are just my observations which make me believe we can make it by clearing that obstacle in time!
Rigidity of the system / safety margin: Yes, I acknowledged that here and it deserves more consideration, which I intend to add to risks. Still, I think the framing of the risk matters, and two points reframe it.
First, the failure mode under a storm is slowdown, not shatter. A cable cut or a period of degraded connectivity is a latency event, not a hashpower event. What happens is: propagation slows, orphan rate rises, blocks come slower. The chain keeps producing, and when connectivity restores, the shorter branch is abandoned and the network heals. A permanent split into two coins requires a sustained hashpower split of more than 33%: one side continuing to mine a minority chain indefinitely. Latency alone doesn’t produce that, and the Network Partitions analysis in security.md works through exactly this, including the split-hashpower timing table (10:90, 33:67, 49:51). A storm that doubles or quadruples network latency degrades us; it doesn’t fracture us.
Second, we can quantify the storm against the designer’s own anchor. Our worst-case model (1.94%) already includes the fixed terms you’re worried about: full block download, 100% missing transactions from the peer’s mempool, the ~25 ms internal constant, and the getblocktxn/blocktxn overhead. So a storm that multiplies propagation times by 2–4× pushes the worst case to roughly 4–8%. Satoshi reasoned with ~10% as acceptable when he justified the 10-minute choice. So, even the storm scenario stays inside the range the designer himself considered tolerable. That’s degraded operation, not existential risk.
And relative to the field, 60s is the conservative choice, not the aggressive one: we’d be slower than Zcash (75s → 25s), Kaspa (~1s), and Nervos (10s), and merely equal to Dogecoin. If we’re giving up margin, we’re giving up less of it than the chains we’re competing with. The question isn’t “are we perfect,” it’s “are we careful relative to everyone else” — and we are.
Reversibility of the change: Worth highlighting that the tick system actually lowers the cost of reversing or re-tuning block time. Without ticks, raising block time later means touching every height-sensitive rule again; with ticks, it’s a schedule entry. So this CHIP makes future adjustments cheaper, it doesn’t lock us in.
Note that the same dependency argument applies to bandwidth-driven throughput: a network that scaled to 100 MB blocks and then had to drop back to 10 MB would face the same user expectations, regardless of block time.
Re. Jason: he has since made a supportive post:
Still plenty of work to do, but it can and must be done. Beyond the UX gains, all Satoshi-derived nodes will continue to require security hardening this year, and spreading out confirmed throughput by 10× would meaningfully harden node security and tx censorship resistance.
Note that this isn’t a reversal — his earlier existential-risk post already points the same way. That post warns against network-centralized fast finality (PoS sub-second), and its “Aside: faster block times” explicitly lists the resilient model as:
a 1-minute block time target with few-hour finality: In day-to-day usage, 1-min blocks are fast enough to offer valuable initial assurance (yet slow enough to reduce competing blocks), while consensus finality remains slow enough (hours) to avoid partitions, even under extreme global conditions.
BCH with this CHIP — 1-minute blocks, finalization at ~120 minutes — is almost exactly the configuration he describes. So the post isn’t a caution against faster blocks; it’s a caution against single-point-of-failure finality, and it already identifies 1-min PoW blocks as the right shape.
On the bigger question — relevancy vs. storms: Our biggest risk is becoming irrelevant, and slow blocks are a big factor in that. Plan for the best, prepare for the worst. If we stick with 10-min, we’re not planning for the best — we’re planning for the worst, and ceding ground to competitors in the meantime. So if doom ever does come, will everyone rush to BCH, or will competitors just adapt and keep their dominance?
And thank you for yours, and I hope you can have your mind changed (by us finishing the work)!
