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

Consensus
#11

Approve
Name or project: BCH-1
Statement: BitcoinCash Autist has done extensive work on mapping all the benefits and fail modes of this project. I believe the architecture change is justified, with the pros far outweighing the cons. The main benefit is developers get an option like a slider to choose the level of security they want vs defaulting to 10 minutes. As he mapped, variance also adds considerable instability to Bitcoin Cash’s UX when apps do not accept 0-conf.

For everything that already accepts 0-conf , nothing changes, it remains a viable path for payments, but wider crypto to be sold 0-conf is a hard sell that BCH does not have outreach resources, Its simply easier for crypto apps to accept the common standard of confirmations as security. We cannot predict whether exchanges and so on will raise or lower confirmations, but we know for sure they cannot lower them under 10 minutes under the current design.

For DEFI and cross-chain applications, a 1 minute block time isn’t even fast compared to other blockchains, but it makes BCH at the range where it’s tolerable, vs 10-30 min waiting for a block. Every user that thinks BCH is too slow, is a user we lose, whilst the proposal does not ensure UX improves, it also has the double effect of apps that realize lowering the confirmation low and being safe, gets them to look at 0-conf eventually.

Optionality is the real win of this proposal, and the ticks design means adjustment to the blocktime in the future will be a non-issue for Bitcoin Cash in the case there is a clear argument for raising it back again.

The trade-offs are well documented in Bitcoin Cash Autists own work, these should not be ignored, for the apps again, I see far more enabled than is disabled.

Furthermore, my support of this is outside of the purview of whether this is engineering work that is achievable, that is not my expertise. I am an apps layers guy.

4 Likes
#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:

5 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