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)!
