CHIP-2025-03 Faster Blocks: gathering statements of support (and dissent)

Consensus
#23

FWIW 2 days ago ZCash voted to go ahead with the 2nd block time change, now from 75s to 25s. And they don’t even have ticks to make the 2nd change easier!

Their main concern was orphan rates, and they’re more tolerant than us (5% instead of our 2%): Zcash Block Time Reduction Appears Safe for NU7 w/ Zebra Only Devnet - Zebra - Zcash Community Forum

I did not see any concerns over activation costs / ecosystem migration. If they had a traumatic experience when moving from 150s to 75s back in 2019 I’d have expected some word about it now.

3 Likes
#24

Thanks, and I’ll log these notes too. Some thoughts about the 10x idea: Wallet Default nLockTime Practices - #15 by bitcoincashautist

#25

Approve

Name: Jon Goose

Project: No project, just a user :smiley:

Statement: As an SPV user, I like faster confirmations. I don’t see the 10x header growth being an issue. With regard to the nomenclature (ticks/blocks), I don’t care how it is implemented or if it adds more complexity, as long as it works and it is clear.

6 Likes
#26

Approve

Name: PKR @maxbit_pkr on x

Project:

  • Maxbit Digital Asset, one of the largest SEC regulated crypto brokerage in Thailand
  • Maxme, one of Thailand’s largest e-wallet with over 500k MAU.

Statement:
BTC has already established itself as “digital gold” “strategic reseve asset” etc. lets be frank, that wont change. However, theres still a chance for BCH to become “P2P electronic cash”, Bitcoin’s original goal which started this whole crypto industry. For that to happen BCH has to out-innovate and differentiate itself, BCH is already on the right track fixing scalability with ABLA, now it has to fix UX, and nothing is a better UX improvement than speed. I would even go as far as saying that 1min block is the beginning not the end, just look at what zcash is doing. Also, as someone running an exchange / broker, 2-3 block confirmation is pretty standard for account crediting on fastblock coins like dogecoin and yes we trust it far more than 0 block confirmation. Let me close with this Elon quote:

“Ideally, Doge speeds up block time 10X, increases block size 10X & drops fee 100X. Then it wins hands down.”

BCH is probably the closest to what Elon is describing, cease this opportunity!

Disclosure:

  • Mainly a BTC holder, but still have a soft spot for BCH (yes we do exist xD)
  • Made this account just to post this.
5 Likes
#27

Banger.

Welcome to BCH research! Glad to have you in the community & very glad you’ve spoken up on this issue!

3 Likes
#28

Hi,

I support this CHIP conceptually. On the other hand, I don’t think it is necessary to push it for the next upgrade cycle if the implementation is not ready, ref: CHIP-2025-03 Faster Blocks: gathering statements of support (and dissent) - #4 by cculianu

4 Likes
#29

Welcome to BCH research! Good to see you here for sure.

The concept is that desire & implementation are a loop - either virtuous or vicious. If people want it a lot, the implementation will get done. If the implementation is done, it’s easy for people to sign off on.

On the other hand, if the approval waits for the implementation, then the implementation isn’t that much of a priority and doesn’t get done. Which feeds back to nobody feeling confident to approve. And everything stays stagnant as time passes & we miss the 1 time per year window to lock in an upgrade - and then spend the whole following year having the exact same problem instead of attention & mindshare moving to the next important topic(s).

So that’s why we’re pushing both forward as fast as we can.

3 Likes
#30

My full endorsement posted on the Podcast blog and copied to Twitter.

Time for 1 minute blocks.

5 Likes
#31

Endorsement of CHIP-2025-03 Faster Blocks for Bitcoin Cash

I have reviewed the faster blocktimes CHIP in depth and believe that the costs and risks to me and my personal projects are well worth it to reap the benefits of the faster and more reliable block confirmations. Many of my personal projects uses transaction confirmations in ways that would be significantly improved by faster blocks, and personally I regularly use services that do not rely on 0-conf alone, and I frequently find myself waiting for confirmations much longer than the average 10 minutes of today.

While I am strongly in favor of the goal of faster blocks, I do have reservation with regards to how we get there, and the CHIP proposal here is extensive and makes changes in many different systems. As such, any implementation carries higher-than-normal risk to malfunctioning and such outcomes could be catastrophic to the reputation of Bitcoin Cash and could cause impacted services like exchanges and mining pools to withdraw from our ecosystem entirely. Implementation experience and running the changes for an extended time is the single most important next step to address that concern. If that is not an option prior to lock-in, then contacting the people who built or maintained the various systems that are being changed is recommended as that calls upon their implementation experience instead.

In summary, I absolutely do want faster block times, I think 1-minute is a number to go with today but I am not a subject matter expert in each of the systems that requires changing and my endorsement is therefore conditional on people with implementation and operational experience having reviewed and not found significant objections to the recommended implementation.

The endorsment above is for:

It is explicitly not for the following:

4 Likes
#32

Statement from General Protocols as a business entity:

TLDR / Last Paragraph:

Faster block confirmation is a desirable property and we look forward to a future where Bitcoin Cash has improved on the user experience by significantly reducing block confirmation times. Despite this we choose to ABSTAIN until such time that sufficient review of the implementation costs and risks are done by respective experts. The cost of rushing a proposal far outweighs the cost of not shipping an update for 2027.

4 Likes
#33

I endorse CHIP-2025-03 Faster Blocks for the November 2026/May 2027 BCH upgrade cycle, targeting a 1 minute blocktime.

I believe the benefits are clear, the tradeoffs are acceptable, and the risks are known and bounded.

Faster blocks would be an essential step to improving the user experience of Bitcoin Cash in many dimensions. While 0-conf is excellent, and we should still utilize 0-conf whenever possible, Bitcoin’s fundamental design and security assumptions still ultimately rely on block confirmations.

If we walk through each of BCH’s primary use cases:

  • P2P Cash: payer and payee are more resilient to dsproof-hostile transactions. Multiparty transactions settle more quickly with less contention.

  • DeFi: Anyone-Can-Spend UTXOs that power BCH dApps can become contested due to simple latency between users and relay nodes. Faster confirmations means less downtime for dApps that encounter this regularly occuring issue.

  • Currency exchange: both CEXes and DEXes benefit from faster confirmations. We also have heard from Maxbit, one of the largest exchanges in Thailand, signalling an industry expectation for faster confirmations. This suggests to me that CEXes may potentially consider adjusting their confirmation limits after this change - a clear win for attracting BCH liquidity and facilitating real-world use.

  • Mining: Miners are afforded more certainty in their future earnings, while also smoothing out overall variance between blocks. Smoother variance also allows better calibration for the DAA and ABLA.

Almost every stakeholder can find a reason that faster blocks could benefit them.

From my point of view, all technical objections have been adequately addressed, and the problem space has been thoroughly explored. I initially had reservations about SPV header growth due to potential complications with a NFC payment card usecase. I later realized that there are other ways to design such a product where that’s not an issue, dissolving the last remaining concern I had.

The only barrier, as others have said, we cannot move forward if the implementation is not sound. I have confidence in our node developers’ capabilities, and if the will to upgrade is overwhelming, the community will find resources to make sure everything is developed and tested on time.

The ticks abstraction is just the right amount of engineering on paper. However, I expect the realities of implementing such a fundamental change to legacy node software will be fraught with skeletons and dragons. Luckily, our top wizards seem to already be on top of it, with a whole upgraded spellbook to boot.

My endorsement is contingent on sound implementation and a safe launch on a separate chipnet BEFORE November 15.

On behalf of myself and my enterprises, I offer my approval.

2026-09-20; Kallisti#159412⚖️; bitcoincash:qzvj8dvrj52fmnwcxz2dd2e2tgnmgze47u099rchsf

Signature: IPD5rtayVFdhmRutpzpmC+T2OTxT83ekUwDf9p1Nsm/5MgFqCvTbZktJH8lBloFEkfCOucDHgm7hqOazSQa5T/A=
Public Address: bitcoincash:qzvj8dvrj52fmnwcxz2dd2e2tgnmgze47u099rchsf

4 Likes
#34

My personal statement (not GP): Given everything that I have seen and the immense high-quality work @bitcoincashautist has put into it, 1 minute blocks are a high value change that will happen sooner or later.

My conservativism is that as usual with one-way streets that involve severe consequences, there are a few more things that should be considered:

  • Hard-eyed attempts to break assumptions, reveal hidden costs, etc. from experts who are not necessarily in the BCH ecosystem
  • Now that the CHIP is in a very well-developed state with significant support, it’s an opportunity to have a rational conversation with businesses who are “passive” BCH stakeholders such as pools, exchanges, processors who normally wouldn’t be aware of things going on.
  • More explicit analysis of the cost-benefit of the alternative form in which block times are shortened without the tick system. Ticks are non-trivial to implement in the node, and complexity is always best avoided if it doesn’t have excellent backing. A starting point could be “Flexible would be nice, but complexity is dangerous. How much relative value do ticks have in the case that block times are never changed again?”

GP and I will try to help with these under BCA’s guidance/organization if desired.

If backed into a corner to make a formal statement, I guess it is ABSTAIN, but that really represents a default (that everyone should have for all CHIPs) of REJECT combined with projection of an eventual APPROVE. It is very important not to conflate an eventual endorsement with endorsement of the current CHIP. We have multiple examples of CHIPs undergoing material changes before eventual inclusion into consensus.

It’s a great CHIP. Continuing the tradition of having a simultaneously solid and improving foundation under BCH’s feet. BCA is a literal legend.

5 Likes
#35

Did you see this? CHIP-2025-03 Faster Blocks for Bitcoin Cash - #185 by bitcoincashautist Does it address this concern? (please continue discussion about it there, since it’s technical)

For some background, ticks emerged from the pressure created by this framing of the problem (Jonathan Toomim’s 2019 comment on /r/btc):

I suspect that 2.5 minutes will be viable, but that 1 minute will be too short. However, I don’t know for sure. In 6 months or a year, I expect we’ll have much better data on the performance of the new block propagation algorithms (except Blocktorrent, which will likely take 1.5 years), so I suggest we postpone this discussion until later.

If we change the block time once, that change is probably going to be permanent. Changing the block time requires quite a bit of other code to be modified, such as block rewards, halving schedules, and the difficulty adjustment algorithm. It also requires modifying all SPV wallet code, which most other hard forks do not. Block time changes are much harder than block size changes. And each time we change the block time, we have to leave the code in for both block times, because nodes have to validate historical blocks as well as new blocks. Because of this, I think it is best to not rush this, and to make sure that if we change the block time, we pick a block time that will work for BCH forever.

The idea that we can only do it once bothered me because it’s a catch-22: do it now and we miss out on future gains. Postpone it for later and we miss out on any gains (like we already did 2019-2026) and risk indefinitely postponing. Imagine an alternative history: we implemented ticks in 2019 and switched to 2-minute blocks, and are now proposing to bump it down to 1-minute.

The only way to break out of that is to make it change-able, which is exactly what ticks do.

Thank you, I believe we can get this over the line if we focus our efforts and more people join in to contribute to the outcome where they can!

1 Like