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

Consensus
#12

Disapprove.

If it aint broke, don’t fix it.

3 Likes
#13

It wouldn’t necessarily turn it into approve right away but – it would certainly help to get the code over the finish line ASAP w/ more testing, etc. Maybe have Dagur or someone that has advanced AI skillz throwing their AI at it for review only wouldn’t hurt. That would improve the situation.

BCHN is going to do a release very soon for some updates that were planned for a while now, and then we can focus on ye faster block tyme.

4 Likes
#14

I love you so much right now. :hearts:

2 Likes
#15

1 minute blocks is extremely conservative in the modern era by all metrics.

If the code isn’t quite ready yet we can easily make it ready, we have the resources.

I, Luke Pryor, APPROVE.

4 Likes
#16

The CHIP’s thesis is that 10-minute blocks are broke. 10-minute blocks are (for now) survivable for BTC because it won the “digital gold” market position. We don’t have the same luxury. Excluding BTC, we have the slowest blocks of any top coin, and of the UTXO-PoW set too: LTC 150s, XMR 120s, ZEC 75s, DOGE 60s. We can’t afford to pretend this doesn’t matter for user acquisition and retention, and I was hoping you’d see it, too. Relevant discussion between Brady and me happened here: 1, 2, 3, 4, 5.

Long shot, but what kind of argument could change your mind?

PS: we’re still agile enough to make this change now, but later we may not be. There’s a possible timeline where we get stuck with 10-minute blocks forever. Using this window now (and installing ticks alongside) prepares everyone for doing it again at much smaller cost: the next time, it’s basically one line of code. That means we’d actually get to benefit from future block propagation improvements instead of just reading about them, and one day we could step down again toward Nervos-style ~10 seconds.

PPS: The day before I wrote the above ZCash voted to go ahead with their 2nd target block time adjustment, which should be telling us something about activation costs and risks concerns. CHIP-2025-03 Faster Blocks: gathering statements of support (and dissent) - #23 by bitcoincashautist

6 Likes
#18

Approve, but with caution
Name or project: mainnet_pat, projects I own or maintain
Statement: the idea is good, improvement of defi experience and block inclusion time variance is a must. But I am not sure about the proposed implementation. The ticks approach seems to bring more complexity.

3 Likes
CHIP-2025-03 Faster Blocks for Bitcoin Cash
#20

Disapprove.

In balance doesn’t seem to be a good idea.

3 Likes
#21

Noted. Your most recent substantive objection was the BIP-37/SPV one, and I think @nyusternie answered it point by point. I’ll log your Disapprove as stated.

2 Likes
#22

Name/Project: 2qx, vox.cash, unspent.cash, futurebitcoin.cash, awesomebitocin.cash, CatDex, photons, SAFAs, etc.

Statement: Approve of the concept, if implementation is ready in time.

… with notes about future height nomenclature

And a more elaborate explanation of time systems and the advantages of height based contract logic.

3 Likes
#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