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

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:

3 Likes

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.

5 Likes

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?

3 Likes

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.

1 Like

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

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:

  • If a bull market comes, don’t we want to catch as many new users as we can? Block time matters to newbies. Excluding BTC, we’re the slowest antelope, and many will not even consider us with 10-minute blocks. Only BTC can get away with 10-minute blocks; we’re not reliving 2012, where Bitcoin was the only crypto in town.
  • This CHIP will continue to take a share of everyone’s attention for one more year, leaving them less bandwidth to work on other things. I for one want it off my back. It’s been exhausting climbing this mountain. Why rest just near the top? There are other mountains to climb.
3 Likes

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.

2 Likes

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.

5 Likes

On 1-conf being 1/10th the PoW

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.

On the side effects

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.

On the alternatives

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.

On testnets

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.

7 Likes

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:

  1. Cculianu (BCHN)
  2. Paytaca’s CEO Joemar_taganna or EmergentReasons confirm code ready. (That’s Time! LFG!)

BUT Honestly Real UX Gain also base on Binance/OKX/Kraken conf-count Policy.

Public Post:

5 Likes

FWIW, I initially had this opinion also but IMO BCA has bulldozed most of the concerns through solid analysis. The ones that remain for me are:

  1. implementation completeness, timeliness, complexity, risk, including assessment of complexity with/without ticks (all need to be assessed by experts after an implementation is done)
  2. as @1KBCH and others have mentioned - what are Binance’s and similar passive stakeholders going to do? At least to have a discussion with them to make sure BCH isn’t blindsided by a massive negative reaction (some of us are trying to coordinate this now)
7 Likes

I do not approve of this CHIP in its current form.

I agree that we need to improve Bitcoin Cash confirmation times, especially for users interacting with exchanges, custodians, and other services that do not use 0-conf.
However, I am not convinced that reducing the target from 10 minutes to 1 minute is the right solution. It seems to me that 1 minute is too fast.
Rather than a speed issue, I believe we have a problem with hashrate variability, which causes block times to fluctuate significantly.

I see two possible solutions:

1. Status Quo
Maintain the current 10-minute target.
If BCH manages to significantly increase its value—and consequently its hashrate and economic security—we could expect greater stability in block times, similar to Bitcoin’s.
Furthermore, a network with a higher hashrate would be more secure against certain attacks; this could help boost the confidence of exchanges and other services in Bitcoin Cash, potentially leading them to accept 0-conf transactions.

2. Increase speed conservatively
Reducing the target to 5 minutes per block seems reasonable to me.
This would be a significant reduction from the current 10 minutes without going to the extreme of 1 minute, while still allowing for faster confirmations.
It should be understood that users, exchanges, and other services interacting with Bitcoin Cash will sooner or later have to adopt 0-conf, since waiting for confirmations always takes time and Bitcoin Cash lacks a second layer for instant payments.

Bitcoin Cash Arequipa Educational Portal on Telegram (in Spanish)
BCH donations and donations via CashTokens (BCA, SDO, and SAT)

1 Like

This is not supported by the data, and easily disproven by comparing BTC and BCH block time stats. You can also run a simulation with perfectly flat difficulty and hashrate, which my block interval game does here: Block Interval Game

BTC and BCH had about the same number of blocks slower than 30 minutes (~5%). That is just the natural variance of a random process. There’s only some tail difference at 99% threshold which can be attributed to hashrate fluctuations. The big anomaly around height 500k was the horrible EDAA period. We activated ASERT at height 661,648 so the big anomaly before it was the fault of CW-144 DAA’s oscillations, which I believe is the reason many people still hold your (now wrong) belief that DAA/hash is responsible for variance. Your belief used to be partially correct in the 2017-2020 era. But now with ASERT, it’s no longer correct.

To get the intuition – if you keep throwing a 6-sided dice, it will take 6 throws on average to land a 6, but sometimes you will get lucky and get 2 sixes in a row, and sometimes you will get unlucky and it will take you 12 or more throws to get a 6. When you throw by hand your “difficulty” and “hashpower” are both fixed, so number of rolls between two 6s is nothing but the natural variance of a random process. Mining works the same, all miners are throwing lots of dice until they meet the difficulty requirement. Yes, DAA adjusts it, but not fast enough to be accountable for solvetime variance. If a block is 2h late ASERT will reduce its difficulty by only ~3%. If the network loses 10% of its hashpower it will only increase average solvetimes from 10 minutes to 11 minutes, and variance around the average will scale the same so the 5% outlier threshold will be 33 minutes instead of 30.

This is falsified above. BTC does have stable hashpower but block solvetimes are still scattered around 10 minutes and 5% of blocks will still be longer than 30 minutes.

This is true, but higher hashpower can lead services to reduce confirmation requirements to less than 10 one-minute blocks, so with faster blocks we get even more benefit from this future scenario. Also, faster blocks reduce the “risk window” for 0-conf which can actually help with 0-conf adoption – more on that here:

1-minute is conservative. A dino-coin like Dogecoin has been functioning fine with it since 2014. After adopting compact block relay (which BCH had from the start) — and with a much better Internet since — its orphan rate fell to ~0.15%. We’re far from the cutting edge which sits at ~10 seconds (e.g. Nervos network has 10s and ~3.3% orphan rate)

To me it is unreasonable because it doesn’t provide enough benefit (~5% of blocks would still be slower than 15 minutes) and has high image risks. How does this upgrade headline sound: “BCH made a complex upgrade to move from being the slowest non-BTC blockchain to still being the slowest non-BTC blockchain!”. We are the slowest antelope! 1-minute blocks are unremarkable and conservative and far from “extreme”. The 10x jump looks extreme not because 1-minute is extremely slow but because 10-minute is extremely slow! We will become faster than LTC and XMR, equal to Dogecoin, and still slower than Zcash (which has already voted to go 75s → 25s) and much slower than the cutting edge (Nervos ~10s, Kaspa ~1s).

Nothing supports this assertion. We have no power over big multi-coin services. They can just not adopt 0-conf, ever, and all their users will think BCH is slow. If their users BCH experience is slow, what will they do, change the service or change the coin?

This is a huge surface BCH has no control over. The only thing we have agency over is our target block time, and can use it to automagically improve UX for all users who use BCH through those services. Rare few will come to 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?

5 Likes

You are right that higher speed can improve the end-user experience. But we need to distinguish between two things: speed and the perception of speed.

We aren’t just talking about improving an application so it responds faster; we are talking about money.
And money requires clear, predictable, and stable rules. Money is sensitive to risk and uncertainty; when it perceives that the rules might constantly change, it flees the asset.

If it were just about speed, Fastcoin would have been a success. It had blocks of approximately 12 seconds!

https://bitcointalk.org/index.php?topic=218852.0

If it weren’t for Elon Musk, Dogecoin wouldn’t exist.
LTC and XMR are niche cryptocurrencies.

Bitcoin Cash operates at two speeds (for now): on-chain transactions (slow) and 0-conf transactions for fast payments. The user has to understand how Bitcoin Cash works and adapt to its operation.

That is what happens with Bitcoin: the market uses on-chain wallets for certain operations and Lightning, Liquid, or custodial services for others.

I repeat: it is a matter of perception.

I see two types of users:
• The user who wants to make fast payments. They usually move small amounts and prioritize convenience and speed.
• The user who wants to transfer and store large amounts of value. This user moves millions of dollars. For them, a few extra minutes are irrelevant compared to other issues like security, predictability, privacy, control over funds, and knowing who is responsible if something goes wrong.

That is precisely what is happening with the Bitcoin Cash ETF; major investors want exposure to BCH but want someone to be accountable for their money if something goes wrong.

A user won’t necessarily abandon a system just because they have to wait a few minutes. They might abandon it because they don’t understand the rules, perceive uncertainty regarding the currency, lack control over the asset, or feel the rules are constantly changing—as happens with Bitcoin Cash, which changes annually.

It is not just about winning users through persuasion; it is about winning users through conviction.

Not necessarily, but many will. And many, many more will never join to begin with.

Does higher block time increase user conviction? Are you advocating a change to 100 minute blocks? 1 000 minute blocks? Why or why not?

Or is it ossification that increases user conviction in your mind? Are you advocating that BCH never upgrades ever again for maximum conviction?

If you aren’t advocating for either a block time increase or for immediate ossification, then you have to acknowledge that conviction is nothing to do with decreased block times.

Of course we want users convinced & convicted in our project. And the way to acquire convinced & convicted users is to deliver the best possible product (which as the market overwhelmingly shows and the CHIP explains in detail is faster confirmations) and to embody a spirit of progressive improvement where the benefits of a change are clear (which in this case they are, so changing is a meta-benefit as well as a benefit, it shows we aren’t ossified morons waiting to be outcompeted like BTC).

3 Likes

The real concern, and the inversion

The one serious point here is the perception of stability: money flees assets whose rules seem to change unpredictably. That concern is real, and the CHIP takes it seriously. The Risk Assessment section on Bitcoin Cash Image Risks exists precisely because of it.

But the inversion is this: the tick abstraction makes this the last time block time is a breaking change. Future adjustments become a parameter change. Append an entry to the tick schedule, and every time-sensitive rule follows. So the CHIP is the anti-instability move. It is a one-time change that buys long-term stability, the opposite of “rules constantly changing.”

And BCH’s annual upgrades are not “constantly changing rules” in the sense that scares money. They are scheduled, coordinated, and documented. Money flees unpredictable change, not change everyone knows is coming on a fixed calendar. The annual cadence is a feature, not a bug.

The two-speed model you are defending is the problem

You say BCH operates at two speeds: on-chain (slow) and 0-conf (fast), and the user has to adapt. You then hold up Bitcoin’s Lightning, Liquid, and custodial services as the same model. But that is exactly the failure mode the CHIP is trying to fix.

Bitcoin’s two-speed model exists because BTC cannot change its base layer. Users flee to L2s and custodians because on-chain is too slow and too expensive. That is ossification, not stability. BCH’s 0-conf plus on-chain is the same two-speed model, and the CHIP does not eliminate it. It makes the slow lane less slow: 10 to 40 minutes becomes 1 to 3 minutes, with far less variance.

And there is a hidden instability in the two-speed model you are defending: the fast lane can collapse into the slow lane at any moment, through no fault of the user. A 0-conf payment that hits a mempool desync, a risky transaction shape, or a service that suddenly demands a confirmation is instantly downgraded to the slow lane. You are never purely 0-conf; you are 0-conf until circumstances force you out of your lane. With 10-minute blocks, that forced exit means a 10-to-40-minute wait. With 1-minute blocks, it means 1 to 3. The two-speed model does not disappear; its failure mode just stops being brutal.

So if you are fine with the two-speed model, the CHIP is a strict improvement to it. The only way to object is to say the slow lane should stay slow, which is the ossification argument. That is the thing that turned Bitcoin into a chain where normal people cannot transact.

Fastcoin is a non sequitur

Fastcoin failed because it had no adoption, no ecosystem, no network effects. Not because 12-second blocks are bad. The relevant precedents are chains that changed block time while already having users: Monero (1 to 2 minutes), Zcash (150s to 75s, now voting 75s to 25s), Dogecoin (1 minute from launch). Those are the controlled experiments. Fastcoin is a new coin with no users; BCH is an established chain changing a parameter. The two are not comparable.

And nobody claims speed alone makes a coin succeed. The CHIP claims speed is one improvement among many. “If it were just about speed, Fastcoin would have succeeded” is a strawman.

Dogecoin, LTC, and XMR were cited for viability, not success

Those coins were cited for one narrow purpose: proving that shorter block times work operationally. Not that they make a coin succeed.

“Dogecoin only exists because of Elon Musk” is false. It ran for seven years before Musk’s 2021 involvement, with 1-minute blocks the whole time. And it is irrelevant. The operational fact stands regardless of who tweets about it.

“LTC and XMR are niche” is wrong on both counts. Litecoin changed nothing from Bitcoin except faster blocks and a different PoW algorithm, and it held the number one altcoin spot for years despite a structural price headwind: it started later, so it sits a few halvings behind BTC on inflation. Its entire value proposition was “Bitcoin, but faster blocks,” and the market rewarded exactly that.

XMR is not niche either. It sits around #12 at roughly 10B market cap, ahead of BCH, and its selling point is privacy, not speed. Yet even a privacy coin finds 2-minute blocks necessary; 10-minute blocks would be painful for it. And XMR’s block time history is the most instructive precedent in this whole debate: it launched in 2014 with 1-minute blocks, then moved to 2-minute blocks in 2016, when propagation tech was inferior and compact block relay was still being adopted elsewhere. Even under those conditions, with adoption growth to worry about, the “conservative” move was 2 minutes, not 5, and not 10. A decade later propagation is far better, and what was conservative then is 1 minute now.

Their block times prove the technical point. Market size is a separate question, and the CHIP addresses it elsewhere.

Your two user types omit the actual target

The model is fine as far as it goes: small-value users want speed, large-value users do not care about minutes. But it omits the population the CHIP actually targets, and it misreads who that population is.

First, the onboarding user on a multi-coin service. BitPay, Moonpay, Trust Wallet, Binance. They cannot use 0-conf because the service does not implement it, and they are forced to wait 10 to 40 minutes with high variance. “Small-value users use 0-conf” is true inside the BCH-native ecosystem, but false for the majority who onboard through multi-coin services.

Second, and more importantly: existing BCH users. Even inside our own ecosystem, 0-conf is not always available. A Cauldron user who hits a mempool desync, or any 0-conf payment that trips a risk signal, is instantly downgraded to a 1-conf wait through no fault of their own. The CHIP targets existing BCH users first: our own experience improves for every scenario where we cannot avoid a confirmation. And it has a chance of converting more users on top of that. Even if it only improved the lives of existing BCH users, it would be worth it.

“Large-value users do not care about minutes” is true and irrelevant. The CHIP is not for them. The CHIP is for everyone else: the onboarding user who waits 10 to 40 minutes today, and the existing user whose 0-conf lane just collapsed into the slow lane. That is not “a few minutes.”

“Won’t abandon for a few minutes” contradicts itself

Three problems. First, for the target population the wait is not “a few minutes.” It is 10 to 40, with high variance: 25% over 14 minutes, about 14% over 20.

Second, as Jeremy put it above: not necessarily, but many will abandon, and many, many more will never join to begin with. The abandonment you can see is the small part; the onboarding you never see is the large part. Every user who would have tried BCH and bounced off a 30-minute first confirmation is invisible to you, but they are not invisible to the network’s growth.

Third, this contradicts your own fast-payment-user point. If minutes do not matter, the status quo is fine and the CHIP is harmless. If minutes do matter, the CHIP helps. You cannot have it both ways.

The honest version: minutes matter a lot for the onboarding user, and not at all for the large-value user. That is exactly why fine granularity is better than a coarse 10-minute quantum. It serves both.

The ETF point is a non sequitur

ETF investors hold through custodians. They do not care about block time at all. Bringing up the ETF actually supports your “large-value users do not care about minutes” point, which is irrelevant to the CHIP, because the CHIP is not for them.

Conviction is what evidence produces

Jeremy already landed the decisive blow here, and it is worth repeating. If conviction comes from higher block time, why not 100-minute blocks? 1,000-minute blocks? Why not? If conviction comes from ossification, are you advocating BCH never upgrades again, for maximum conviction?

If you are not advocating either, then conviction has nothing to do with block time. You have to acknowledge that.

And the meta-point is the real one: the way to acquire convinced users is to deliver the best product and to show that the project improves when the benefits are clear. Changing is a meta-benefit as well as a benefit. It shows we are not ossified, waiting to be outcompeted like BTC.

Conviction is not a thing you demand from users. It is a thing evidence produces. The CHIP is the evidence.


This post is a list of reasons to be cautious, and caution is fine. But caution is not an argument against the change. It is an argument for doing it carefully, which is what the CHIP is.

3 Likes

Logging these responses here which were collected as part of chasing up the General Protocols requested responses.

–

Tobias Ruck: “I spoke to Grok and it gave me this summary; it does sound very AI but the points stand IMO: Google Drive Link”

Amaury Sechet: Twitter conversation and follow up debate/arguing with me if you’re interested in that


My personal notes on these responses:

Tobias literally outsourced to an AI (and happened to choose one that consistently lags in BCH input, due to being trained on BTC-heavy populated Twitter data) & put seemingly almost no thought into it himself, or read the CHIP document. This basically disqualifies it from relevance on its face, plus it provides an example of how petitioning unaligned devs is not likely to produce real signal or critique. But that said, the Grok response is mostly arguments that have already been debated, debunked and/or addressed in the CHIP itself eg. exchanges will just raise the confirmations (still a win, addressed many many times), rescaling timelocks requires nodes to upgrade (duh) or just plain irrelevant hallucinations “Do not hide behind price” (???).

Amaury’s response also shows no indication that he actually read the CHIP or understood the point of it. He seemed to think it was intended to solve instant payments (it isn’t) or that it was mutually exclusive with those solutions (it isn’t, as shown in the Alternatives section), and fell apart immediately in the follow up as to why it isn’t a step forward on its own merits for the problems it IS trying to solve.

I’m very glad he wrote back, but I’m unsurprised he also didn’t take the time to review it thoroughly and genuinely. I am a little surprised he tried to debate for his point of view and got easily and publicly demolished on it as a result after such a poor effort on engaging with the proposal initially - but that also just speaks to his general disconnection or lack of interest in what BCH does or doesn’t do at this point.

BCHA and I are working on following up the requested people in the General Protocol’s statement, but my expectation is that responses will largely be of this calibre. Where we can get responses at all, unmotivated and at times even antagonistic developers are not likely to provide high quality reviews (why would they). So we can make the effort & show that we have, but the actual substantive improvement to the proposal itself that it will engender is likely to be very very limited.

3 Likes

Someone had already shared the link with me but I didn’t know if it’s public, here’s my answer: https://gist.github.com/A60AB5450353F40E/3f34040fcc89c78d32234c615e1a8c69

Did he comment on parking / finalization at all? Why did he come up with parking when finalization could’ve been enough, and why choose 4? And would he keep 4 count with 1-min blocks or scale it to 40? Anyway, I had some nice talks about this with Andrew Stone who should count as an expert, too. He’s the only person who actually gave parking / finalization scrutiny back in the day, and I re-implemented his simulations for our purposes (see “Security Against Parking Chain Split”).

As for other people on that list:

4 Likes

No he didn’t say anything about that.

As mentioned, he gave barely a cursory effort to even look at the proposal or think about it at all. Seems like he just wanted to lazily dismiss it as “incompetent BCH leadership” and he did so that’s all there was to it.

3 Likes

I’ve read the discussion with zawy and tom, and what I am seeing is that even after more careful looking and thinking about the impact on the ASERT algorithm, the discussion there landed on that it seems safe and they would’ve done essentially the same thing.

That is very re-assuring when it comes to the DAA impact.

I don’t think we’ll see as good discussion for all impacted systems, but appreciate the effort and outreach nonetheless.

4 Likes

I am advocating against breaking something that currently works correctly.

Among the options I am considering is maintaining the 10-minute block time and—only if there is a compelling, well-justified need—evaluating a reduction to 5 minutes per block.

I am not opposed to modifying Bitcoin Cash features when there is a strict necessity and when the change directly contributes to its purpose as peer-to-peer electronic cash.

My objection lies in incorporating features that no one has requested and that are not necessary for P2P cash.

I understand that, technically, a vast array of functionalities could be added. The question is whether we should do so. Each new feature takes us a little further away from the original design proposed by Satoshi Nakamoto. At some point, we could end up with a system vastly different from what we originally called Bitcoin—perhaps even turning into something like Ethereum 2.0?

Bitcoin according to Satoshi Nakamoto’s original design

Key features include:

  • Bitcoin as a peer-to-peer electronic cash system.
  • Proof of Work as the consensus mechanism.
  • A maximum supply of 21,000,000 coins.
  • A target block time of approximately 10 minutes.
  • Reward reduction via “halving” every 210,000 blocks—roughly every four years.
  • Precision to 8 decimal places.
  • A minimum unit: 1 satoshi = 0.00000001 BTC.
  • A distributed network of interconnected computers.
  • Transactions that do not rely on a central authority for reversal.
  • Direct payments between users.
  • The ability to handle both microtransactions and high-value transactions.
  • Low fees.

My point is not that these features must remain untouchable forever. Rather, my point is that there is an original design and purpose that should serve as a reference point before any system modifications are made. Among the Bitcoin forks—BTC, BCH, BSV, XEC, XBT, etc.—I consider Bitcoin Cash to be the one that currently retains many of the fundamental characteristics of the original design, even though it has also incorporated new features.

My criticism of other forks is based precisely on those arbitrary changes:

  • BTC is not Bitcoin because it requires a second layer, such as the Lightning Network, to make everyday payments.
  • BSV is not Bitcoin because it allows coins to be frozen.
  • XEC is not Bitcoin because it levies a tax on miners and operates using centralized nodes.
  • XBT, like BTC, relies on a second layer for certain payments and also uses a smaller block size.

That is why I consider it important to preserve the fundamental characteristics that ensure Bitcoin Cash remains Bitcoin.

Let me give you an analogous example.

Suppose I go to a dealership and decide to buy a pickup truck. I put down a deposit and return a month or two later. Then the salesperson tells me:

“A new model has arrived. It’s not a pickup, but an SUV. It’s more comfortable, has rear-view cameras and sensors, consumes less fuel, and comes with many additional features.”

All of that may be true. The SUV might be an excellent vehicle. But I didn’t go there to buy an SUV; I went to buy a pickup truck.

The problem isn’t that the SUV is bad. The problem is that the product I decided to buy is being changed.

The same applies to the characteristics of Bitcoin Cash.

I am buying Bitcoin Cash because I believe it preserves Bitcoin’s fundamental design as peer-to-peer electronic cash. I am not looking for a “faster” or “cheaper” currency, or one with more features.

When I speak of conviction, I do not mean that users should blindly accept that Bitcoin Cash is superior.

On the contrary, I believe every user should compare options, study the alternatives, and reach their own conclusion.

Bitcoin Cash’s superiority should be demonstrable through its properties, its functionality, and its utility as peer-to-peer electronic cash.

1 Like