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

Consensus
#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.
6 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.

6 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:

6 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.

7 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

7 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.

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

4 Likes
#36

Disapprove.

If it aint broke, don’t fix it.

3 Likes
#37

Noted. Your objections were laid out here and I first covered them here in the post after. They actually inspired the “Bitcoin Cash Image Risks” addition to the CHIP. I’ll log your Disapprove as stated.

3 Likes
#38

On a side note:

I really enjoy the high culture of cooperation and discussion in this CHIP process :+1::+1:

We have come far from crazy 2015 times, as a community.

3 Likes
#39

It’s broke, and it’s past time to fix it, approve.

Confirmation time is one of the main considerations new users value when choosing a blockchain to use, let’s make BCH a coin that cannot be glanced over by them.

7 Likes
#40

I do think that at this point the argument “if it ain’t broke, don’t fix it” needs substantiation. I would argue that it is in fact broken in the sense that the expectation is 10 minutes but it often is significantly more or significantly less.

Let’s look at the variance of the last 10 blocks at the time of posting…

Screenshot 2026-09-21 at 5.20.55 PM
Screenshot 2026-09-21 at 5.20.55 PM734×708 63.7 KB

Only 2 of the last 10 blocks are even remotely close to the 10 minute target.

4 Likes
#41

I personally use sideshift to swap BCH to USDT on a regular basis, these swaps are done within one minute as sideshift has implemented 0-conf

Then i also use Trust Wallet, which does not recognize 0-conf and tx show up after one confirmation, but its because of their implementation that i do not use BCH within Trust Wallet, different block time wouldn’t change that because blocks would still be unreliable as that is the nature of mathematical variance

Even if blocks would confirm between 10 seconds and two minutes that would still not make me use Trust Wallet for BCH

I use cashonize with cauldron and paryon and had the most satisfying DeFi experience that is so fast and reliable with 0-conf that i can not see how faster blocks could improve that user experience

I also interact with Binance regularly, not that i have an account myself, but i frequently, every single day several times, deposit USDT to merchants Binance account, I use USDT because BCH deposits are just way too slow on Binance, they require two confirmations to acknowledge the deposit

Anyway nobody of the merchants that I frequently visit, which are ~20, would prefer to be paid in BCH as USDT has achieved to be the standard in Venezuela, the commerce has chosen that they want dollar pegged tokens, except if I would insist to pay with BCH then they would accept it, but why should I make them uncomfortable as I already enjoy absolute self custodial payments everywhere I go and I am grateful being able to live unbanked

In Venezuela the situation is that fifty percent of merchants accept Binance and everyone is using Binance as their “wallet”

I wonder what would Binance do when the block times change from ten to one minute, would they simply ramp up the deposit confirmations 10x?

That is a major question for me, if Binance would not ramp it up, then it would have some kind of benefit to lower the confirmation time, but I doubt that as Binance has no interest in helping BCH, they want users to rely on their Binance Smart Chain, so if I wanted to have quick deposits of BCH i could just convert BCH on the Bitcoin Cash chain to BCH on Binance Smart Chain and then have instant payments when i go to the merchants

In summary, my user experience would not improve at all by lower block confirmation times

I would not experience ANY practical advantage

I would want to have statements from mayor stakeholders, especially from Binance, to figure out how they would react on lower block conf times so that at least in theory there might be a benefit even if that would not affect my daily routine at all

Binance has the biggest BCH wallet of any other user, they should definitely be contacted and be asked for a binding statement

I am against the update as long as there is not absolute clarity that it would improve user experience more than it would hurt it

Because in the end, BCH will not be Bitcoin anymore as it would not follow the white paper anymore and that is a major emotional damage as that is what the BCH community has always been fighting for, to be the “real” bitcoin would not be an argument anymore

1 Like
#42

This is unavoidable when dealing with a random process like mining. With 1-minute blocks you’d have only 2 of 10 be close to the 1-minute target. You’d have the same pattern scaled down 10x. The relative-to-target distribution doesn’t change. Same chance for 4x target as it was before, and instead of the 0.5-40 minute range you’d have a 0.05-4 minute range.

That’s why it improves confirmations UX, because the old 40-minute outlier becomes the 4-minute outlier.

3 Likes
#43

Aware of that, but don’t they ask for 1-conf if swapped amount exceeds some threshold? Nice that you never hit 1-conf or N-conf thresholds, but I bet others have.

Thanks for confirming their implementation.

Yes, same chances for 4x outlier. But, 4-minutes with 1-minute target is much more bearable than 40-minutes with 10-minute target.

You’re deep into BCH so you know to use a better wallet. However, Trust Wallet has 100s of millions of users, don’t you think that at least someone’s first experience with BCH was through that wallet? Imagine they hit that 40-minute outlier block? Do you think they’d look for a better wallet or for a better coin? I believe that this is really hurting our user acquisition and retention prospects, and it is silent. They will never come tell you that they left or never given us a chance. Rare few will come complain on our channels, and what were we telling them? “It’s mining, can’t be helped, use a different wallet, learn to use 0-conf.” Sometimes they do try our wallet, and become happy 0-conf users. But for every 1 user we “won” that way, how many did we silently lose earlier in the conversion pipeline?

I guess you still haven’t hit one of those mempool desync events? Sometimes your Cauldron trading will get stuck/reversed and it will require a block to unstick. Faster blocks don’t remove the root cause, but they make the recovery faster.

This is the “progress bar” effect of faster confs. You’ll see it show in the deposit page sooner, and have progress update more frequently.

Assumption is that they would. CHIP’s recommendation is that they do. Because what they want for security is accumulated PoW - and asking for the same wall-clock mining duration means 10x the conf. number. This is fine, but it means faster blocks give only small benefit: more responsive “progress bar”, and lower total wait time variance. 100x1 is better than 10x10 because 100x1 will complete closer to 100 minutes, while 10x10 is more exposed to variance and could sometimes take 140 minutes.

Good for you, I wish everyone could have your UX, but unfortunately they can’t or won’t and so we’re leaking users before they even give your ways a chance.

We will reach out to them a little later. They were contacted for previous upgrades and haven’t respond, so don’t expect a response. They do follow BCHN announcements/releases and have in the past issued blog posts in May, just before activation. But that’s informing their users of the upgrade just before the upgrade, not making a statement about the upgrade.

I can log your statement as posted, but maybe your mind could change? Consider it from perspective of users who are not you, those who stick to Binance / Trust Wallet because they trust them and are not ready to jump to an unfamiliar niche wallet just like that.

It will still be the real Bitcoin to us, and to our enemies it was never real. Have whole three sections addressing this kind of concerns:

2 Likes
#44

Approve

Name: 9500/devetipo/Toma
Project: bch-ipfs-scrape

Statement:

I need this.

I’ve read the CHIP, and all my concerns are resolved.

10 min block frequency is obsolete and broken. I understand not everyone uses BCH, but whoever makes more than 1 transaction per month has faced the pain that 10 min block time brings. It’s not about making exchanges reduce number of confirmations, I’m perfectly fine with exchanges increasing number of confirmations 10x. It’s not about replacing the 0-conf payments. I still plan to use it wherever it’s supported, and continue to prefer the services that offer 0-conf payments.

It’s about continuously reevaluating what’s appropriate, and making changes that make the system keep up with time. 10 min block time was appropriate and more than good enough in 2009-2015 period, and we could have left it alone if adoption continued to capture the world, especially if we had no fork. It’s not good enough today anymore. 1 min blocks are technically achievable relatively easily, and similarly like the block size increase, we should make them a reality.

Bonus story, this is personal:
My biggest issue (but definitely not the only one) I have with 10 min blocks are shitty services that expect the payment to be made on-chain in certain time limit, usually 15 minutes. You may think this is made up, but I’ve faced this multiple times, last time when topping up bitcoin.com debit Mastercard! (but that’s definitely not the only example!). Please anyone share if you’ve experienced this as well. It looks somewhat like this: When you go to make a payment, the website shows the address QR code (bonus if no amount included in QR, additional bonus if old address format), and counts down second by second from 15:00 to 00:00. The most important thing - it doesn’t recognize the transaction in the mempool, it waits for the confirmed transaction on-chain. It must be confirmed in those 15 minutes! If it’s confirmed under 15 minutes - fine, you don’t ever notice the issue. You then wait for the needed 6 confirmations it requires, and everything is fine. But if it counts down all the way to 0:00 with no transaction detected on-chain - you get transaction timed out message, and transaction is never processed! Then you need to contact the shitty support to credit your transaction manually, if they are even capable of doing this. 1 min blocks would instantly fix this! This is not about number of confirmations, it’s time to first confirmation to even detect the transaction. I’ve never heard anyone talk about this, but this was the most irritating experience I’ve ever had when using any blockchain so far! Any new user experiencing payment fail like this will disregard BCH instantly and forever.

4 Likes
#45

I approve of this CHIP

Statement:

This CHIP contains engineering improvements and removes a friction point for both developers and users. It also improves security for a given hash power. To assume that the block time will remain 10 minutes for the next 100 years and that all applications going forward will be built with that assumption doesn’t make sense. If the block time will eventually become an engineering choice, the question becomes when and how we make the change.

If we make the change prematurely, then we can’t guarantee that everything will be taken into account in the design. If we make the change too late, then the ecosystem and risks simply grow, and indeed we may become obsolete by not changing fast enough.

I think the time is right. Five years ago, we didn’t have Starlink, AI, or DeFi on BCH. Data centers weren’t a measurable portion of GDP. Today, however, hardware and global connectivity are increasing faster than anyone in 2017 could have imagined. The decentralization risk of a miner with slow connectivity in a remote oil field has transitioned to the risk that the price of oil has changed 10% within that same time.

The question of whether we need to be able to change the block time seems to be an obvious yes, and then the second question of what that time should be doesn’t seem very difficult either. Other chains have already taken the risk and proven that block times on the order of a minute work well. An orphan rate of a percentage or two is in the noise compared to market fluctuations and the cost of hardware and energy. One minute covers Earth and the Moon, and can be changed in the future in case of an issue.

So the main question is the implementation and transition plan. To me, the CHIP implementation that I read seems to cover the necessary bases. Others will have to provide extreme technical implementation analysis. My main item was to ensure that we have a carefully planned-out conceptual model going forward for how we define and handle confirmation and time so that contracts and apps get exactly the security they need. We should have some kind of developer guide and roadmap for how we think about this, and maybe what we might want to add in the future.

So, as mentioned, I think the timing is right and the 1 minute itself is not an issue; the key thing is the implementation and, long term, how we think about this and how we build on top of it.

Other items:

One thing I’d like to bring up is we always need to be considering the scenario of a global war, cut undersea cables, or solar flare which damages or balkanizes the internet. This is one risk area I would like to see some thinking and analysis on, and what our contingency plan would be if that were to happen. Would block time make a difference here? What would make a difference?

1 Like