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.
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
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:
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.
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!
Disapprove.
If it aint broke, don’t fix it.
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.
On a side note:
I really enjoy the high culture of cooperation and discussion in this CHIP process 
We have come far from crazy 2015 times, as a community.
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.
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…
Only 2 of the last 10 blocks are even remotely close to the 10 minute target.
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
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.
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:
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.
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?
This argument and its author should be a show stopper.
I propose that BCHN and API compatible implementations develops and releases the addition of ticks to its JSON-RPC interface in the near future and postpone the block time adjustment for 2028.
He said “for now”. A show stopper is a design or security flaw that can’t be fixed by writing code. “Code is not ready” is the most fixable objection there is: you fix it by writing code, which is exactly what the ~2 months to chipnet activation are for.
This may be the first time a CHIP’s social consensus outpaced code development; it’s an interesting problem to have 
Re. your suggestion, I already said to Shadow above:
I don’t expect everyone to move to ticks. They will be exposed in our APIs so that specific kinds of downstream users can become agnostic of the block time change schedule: exchanges, pool software, cross-chain swap services, payment providers, DeFi frontends, and smart contract libraries. I expect many others will be happy to ignore ticks and just use height.
With 6 months of chipnet we’ll be giving everyone a much bigger window than industry standard. Take ZCash’s 2019 block time change, what did they do? Just ship new software, make an announcement, and all the downstream users adapted to that:
That’s about 2.5 months from first testnet release to mainnet release, and about five weeks from mainnet release to activation. We’re giving ~2 months to chipnet plus 6 months of chipnet before mainnet. What’s the point of preparing for preparation?
The obvious retort that “Zcash isn’t used in real-world commerce and has no covenants or time-locks” actually cuts the other way. The Zcash precedent is evidence about the downstream adaptation burden: exchanges, pools, wallets, generic multi-coin services. To them, BCH is just another coin wired via node APIs. The BCH-unique parts like covenants, locktime normalization, etc. are handled inside the CHIP itself, and they concern the BCH-native builders who are already engaged with it, not the generic services the comparison is aimed at.
Missing the '27 window has hidden costs:
We are working as hard as we can to get the code over the line so this isn’t an objection any more.
For the rest of the relevant factors, see @bitcoincashautist’s response above.
Position: Disapprove (for now)
Name: Joemar Taganna
Projects: Paytaca, PurelyPeer, CashTokens Studio, BCMR Indexer, BCHExlorer.info
I currently do not support activating CHIP-2025-03 for mainnet, but I would like to see it deployed on chipnet for further testing and validation.
I appreciate the substantial work that has gone into the proposal, and I recognize the problem it is trying to solve. Faster and more predictable transaction finality is important, particularly for applications that cannot rely on 0-conf. I am simply not convinced that changing the block interval is the right way to achieve it.
My main concern is the security represented by the first confirmation. A 1-minute first confirmation is faster, but it is not equivalent to today’s 10-minute first confirmation. At approximately the same hashrate, it represents roughly 1/10th the expected PoW. Equivalent accumulated PoW still takes approximately the same amount of time.
I recognize the benefit of finer confirmation granularity. Applications could choose one, two, three, or more minutes of accumulated work according to their risk tolerance. But I am not yet convinced that this benefit justifies changing the block interval, considering the potential side effects that extend well beyond confirmation time—particularly around block propagation, stale rates, mining dynamics, SPV synchronization, and implementation complexity.
I think there may be less invasive ways to achieve faster transaction finality without changing the block interval. Broader DSProof coverage, other conflict-signaling mechanisms, and Avalanche-style pre-consensus are alternatives I believe deserve further exploration before we change such a fundamental network parameter.
That said, I think the proposal has progressed far enough to warrant empirical testing. I support deploying it on chipnet and gathering actual data on its behavior, including propagation, stale/reorg behavior, mining dynamics, and performance under realistic load. That evidence could change my assessment.
So my position at this stage is disapprove for mainnet activation, but support chipnet deployment for testing and validation . I remain open to revisiting my position based on what we learn.
I’m surprised this keeps coming up, because it conflates two different numbers: how much work is in a block, versus how much it costs to reverse that block. A coinbase worth $800 or $80 doesn’t mean you pay some magic box that amount and get a guaranteed double-spend.
Against a minority attacker, reversal probability is a function of confirmations, not time — the whitepaper race math doesn’t care whether a block took 1 minute or 10. A service keeping 1-conf accepts the same probabilistic risk as today. Against a majority attacker, the cost is sustaining >50% of hashrate per hour, which is unchanged because the network still buys the same hashes per hour. The race may be shorter, but he still has to command that hashrate for its duration.
Against minority hash, 2 one-minute confirmations are more secure than 1 ten-minute confirmation, because minority-attacker odds decay exponentially with confirmation count. A 10% attacker needs a ~36× coinbase target just to break even on a 1-conf double-spend. Nervous about 1-conf? Take 2-conf and get more security in ~2 minutes instead of ~10.
Bitcoin’s design assumed an honest majority. We live in a world where hash can be rented, and BTC miners could in principle sell an attacker enough to reach 51% on BCH. However, that’s a sustained hash-war scenario, not something you can conjure reactively. One does not simply walk into a shop and rent 51% of the hashrate for the few minutes a 1-conf race lasts. The logistics are the real obstacle to low-value double-spends, whether the target is $800 or $80. For high-value targets, accumulated chainwork and finalization are the ultimate defense.
And if 1-conf is too weak, consider what we already rely on: 0-conf has zero PoW, and every miner gets a free shot at reversing it in a way DSProofs can’t always detect. If 1-conf is the worry, 0-conf is the thing we’ve been living with for years. Litecoin and Dogecoin have also run 1-conf services for years without a wave of cheap double-spends.
These are real concerns, and addressing them took the bulk of the CHIP. Propagation and stale rates are analyzed in Mining Centralization Risk with a 2% tolerable threshold and an impact estimate of 0.5 to 1.3%, where empirical studies done on Dogecoin and Zcash indicate our estimate is erring on the safe side. Mining dynamics (orphan skew, centralization pressure) are in the same section and in the Security Analysis. SPV sync is in Header Chain Growth, with MMR mitigations. Implementation complexity is the entire Activation Costs section.
None of this is “we’ll figure it out later.” It’s the document’s main body; “potential side effects” as a category is the most-analyzed part of the proposal. If any specific section doesn’t hold up, let’s discuss it in the technical thread.
The BCH-unique parts (covenants, locktime normalization) are handled inside the CHIP and concern BCH-native builders who are already engaged; to generic multi-coin services, BCH is just another coin wired via node APIs.
DSProofs detect a double-spend; they don’t prevent one, and they don’t give you a confirmed transaction. And they structurally can’t cover covenants: a DSProof requires exactly one key whose signature is always required, which any public covenant breaks by design. So composing a Cauldron swap into a merchant payment will always fall back to 1-conf no matter how much we expand coverage. And the direction runs both ways: Cauldron benefits from 1-conf because a block resyncs all mempools, resolving any stuck covenant chain. Expanding DSProof is worth doing, but it sharpens 0-conf detection; it doesn’t create a finer confirmation slider.
Conflict-signaling mechanisms are the same category: 0-conf tooling. They tell you a competing spend exists; they don’t confirm anything.
Avalanche is evaluated and rejected in the CHIP (Avalanche Pre-consensus), for reasons I won’t fully re-litigate here: it bolts on a second consensus mechanism, and PoW-weighted pre-consensus has a vulnerability (temporary hashrate buys lasting influence) that eCash’s staked Avalanche doesn’t have. eCash isn’t a drop-in existence proof for a PoW-weighted version on BCH.
All three solve “0-conf confidence.” None solve “confirmed, but faster.” The CHIP’s claim is narrower than “faster finality” — it’s that the confirmation-fallback experience shouldn’t be stuck at 10-minute granularity.
Last cycle we forked chipnet on Nov 15th off a code-build, and the mainnet lock-in release came in January! But what does “lock-in” even mean? Bugs can surface in chipnet phase, in which case we have to fix them after “lock-in” and do a new release ahead of activation. Could chipnet phase reveal a show stopper that would have us cancel the planned upgrade? If we did our job right up until now, that should be extremely unlikely, but it’s still a valid contingency.
But what’s the expectation from testnet or chipnet? What could it reveal that we don’t already know from empirical data from other similar chains or can model well because the problem space is well mapped? With regards to orphan rates I expect confirmation of analytical findings in the CHIP, so the most likely (and desired) outcome is we just continue smooth sailing towards chipnet and mainnet activation.
With this in mind, what do we want a testnet for?
a) we want data otherwise unknowable to us, data upon which a key specification decision would hinge
VS
b) running a testnet just to confirm the implementation is solid and bug-free, where the most likely outcome is the same spec going ahead — either no bugs were found, or they were found and fixed without touching the base spec.
In all past upgrades it was really just b) and chipnet served that role between code-build and signed release.
I think there’s still time for a preliminary “dirty testnet” before the Nov 15 chipnet upgrade. That would lower the stakes of the first live test.
Holding mainnet as formally provisional has a real cost: downstream integrators may read “not locked in” as “don’t prepare yet,” which makes post-chipnet approval harder, not easier.
Position:Neutra for NOW.
Projects:1KBCH、All IN APE、True Node、Bitcoin Cash Taiwan.
This will happen soon — Research is solid.
I’ll flip to support once：
BUT Honestly Real UX Gain also base on Binance/OKX/Kraken conf-count Policy.
Public Post:
