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

Consensus
#54

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

image
image785×458 38.6 KB

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
#55

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.

#56

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
#57

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
#58

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

image
image962×1306 216 KB

image
image848×1384 234 KB

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
#59

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
#60

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
#61

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
#62

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
#63

There is an enormous CHIP documented, compiled & discussed over 2 years, full of the justification. You’ll need to address that seriously to have a credible position.

A LOT of people have requested this. As you can see from:

  • The detail/time/care put into the CHIP document
  • The polling at Consensus.cash
  • The various endorsement statements already appearing in this very thread (with more being added daily)
  • Community discussion in Telegram, Twitter, the BCH Podcast etc. if you’ve paid any attention for the last 2 years

If 10 minute blocks suits you, that’s fine. I’m very happy that BCH is serving your needs perfectly and you don’t feel any urgency to change. That’s one BCH adopter we have successfully satisfied. But BCH is not a project built to serve you & you alone.

The rest of your response is not really relevant until you will demonstrate evidence of at least recognising or appreciating the overwhelming volume of evidence from OTHER (not you, other) BCHers that this change is desired, well-researched & popular.

4 Likes
#64

Jeremy already answered it well; I’d just add a couple of things.

On “a target block time of approximately 10 minutes” as a key feature:

The whitepaper mentions 10 minutes exactly once — as a “suppose” in a back-of-the-envelope header-storage calculation, not as a design commitment. Satoshi’s pre-release code used 15 minutes. So even by your own reference point, 10 minutes was a practical guess, not a promise. There’s a whole section on this: “But Bitcoin Cash Always Had 10-minute Blocks, Will It Still be Bitcoin?”

On “Bitcoin Cash’s superiority should be demonstrable through its properties”:

This is the strongest argument for the CHIP, not against it. Block time is the one property where BCH is slower than essentially every major coin except BTC. Declaring it immutable — for no reason other than “it was in the original design” — means freezing in the one place we’re losing. You’d be making it impossible to demonstrate superiority through properties in exactly the dimension where we’re behind.

On “features no one has requested”:

This is empirically false, and the evidence is in this thread: Maxbit, a regulated Thai brokerage, said 2–3 confirmations is their standard for fast-block coins and they’d trust it more than 0-conf. Selene/Kallisti, BCH-1, and others have all endorsed it. You don’t have to agree with them — but “no one has requested this” is not a position you can hold while the endorsements are piling up in front of you.

On conviction:

You said every user should study the options and reach their own conclusion. Agreed. The CHIP is the study material — two years of analysis, every objection answered, every number sourced. The endorsements in this thread are other people’s conclusions after doing that study. Conviction is what evidence produces. If the evidence doesn’t move you, that’s fine — but that’s not an argument against the change, and it’s not a reason anyone else should be bound by it.

4 Likes
#65

It would be worth seeking the views of the top three exchanges—Binance, OKX, and Kraken.

Coinbase—the only exchange with a publicly traded stock in the US and the custodian for Grayscale—is also, in my view, a key indicator.

If the feedback is positive, the answer becomes obvious: we should push hard to lock this in for this year.

3 Likes
#66

I want to push back on the framing here, because it reads like exchange approval is the gate. It isn’t, and it never has been, and never should be. Between upgrades we do “BCH bank runs”, “not your keys, not your coins”, “we will displace fiat!” but now we seek permission and offer them power over our protocol!? This kind of framing bothers me.

Outreach is informative, not decisive. The CHIP’s legitimacy doesn’t come from Binance’s blessing, and it never has. Exchanges don’t get a veto over BCH upgrades — and they’ve never asked us for permission before changing a confirmation policy or a listing. The asymmetry cuts both ways. We don’t owe them deference, and they won’t give us binding statements anyway: we’ve reached out ahead of past CHIPs and the large exchanges simply don’t respond. Their silence has never been the gate before, and it shouldn’t be now.

The forks (2017, 2018, 2020) were special cases. A fork is special: there are two chains, and exchanges have to pick a side, so they follow liquidity and the incumbent ticker. A regular upgrade has one chain. There is no side to pick — an exchange either updates its node or it’s off the network in May. That’s a maintenance task, not a political decision. And the empirical record is clear: exchanges delist over volume, legal risk, or chain splits — not over routine upgrades.

They get the signed release and ~6 months. That’s roughly seven times what Zcash gave its downstream in 2019 (five weeks from mainnet release to activation), and it went through without incident. The exchanges will get the memo the same way they always do — the official release — and they’ll have half a year to prepare. If they wanted to weigh in earlier, the door has been open since the CHIP went public a year ago.

So what is the outreach actually for? Three things, none of which is permission:

  1. Blast-radius mapping. The real concern isn’t Binance — it’s the long tail of smaller exchanges and services that don’t have floors of devs and might not update in time, leaving users with broken experiences. Knowing that ahead of activation lets us target the nudges where they’re needed. That’s logistics, not legitimacy.
  2. The paper trail. If a service misses activation, the outreach record means it’s their failure, not BCH’s. We’ve seen this before: a service goes down on upgrade day, checks its inbox, and finds it was contacted multiple times and dropped the ball. That’s the value of having asked.
  3. Satisfying our own process. Several of the conditional approvers in this thread have made “have you talked to the exchanges?” a condition of their support. We run the outreach to answer them, not to get Binance’s approval.

On “if the feedback is positive, the answer becomes obvious”: the answer is already obvious from the endorsements in this thread — Maxbit, a regulated brokerage, has told us they treat fast-block coins at 2–3 confirmations and trust that more than 0-conf. That’s the headline case, witnessed by a real counterparty. What the exchanges tell us is how much of the benefit is headline versus fallback — not whether the upgrade is right. If Binance keeps low confirmation counts, great, that’s Maxbit’s answer again. If they scale up 10×, the CHIP still stands on variance reduction, DeFi recovery, and the progress-bar effect, none of which depend on exchanges at all. If they say nothing — the most likely outcome — that’s fine too, because their silence has never been the gate.

We’ll keep the outreach going and log it, because it’s cheap and it’s the right thing to do. But we shouldn’t wait for it, and we shouldn’t treat it as binding. The exchanges are stakeholders to inform and de-risk, not arbiters of whether Bitcoin Cash upgrades. That’s been true for every CHIP before this one, and it’s true now.

5 Likes
#67

Since I am taking a neutral, I mean that if an exchange offers positive incentives,
I would immediately shift to supporting it, rather than waiting for the technical conditions to fully mature.

4 Likes
#68

Great, thanks for clarifying!

2 Likes
#69

Maxbit, a regulated brokerage, has told us they treat fast-block coins at 2–3 confirmations and trust that more than 0-conf. That’s the headline case, witnessed by a real counterparty.

This part really should be better known. I had read their statement in passing above and I’m an active participant, but if we have a clear reported case where “less than 10 minutes is fine, as long as there’s blocks”, then that gives significantly more credence to the value of earlier confirmations.

4 Likes
#70

After careful consideration, I’ve changed my opinion on CHIP-2025-03 (Faster Blocks). I now approve it.

As I stated in my earlier opinion statement:

Reading the security section of the CHIP, the questions and responses on the subject, and private conversations with @bitcoincashautist narrowed my concerns down to specific assertions I thought needed further scrutiny. So I proceeded to work out the details independently, primarily for my own understanding.

Here’s what I found:

The PoW arithmetic is still correct: a single 1-minute block contains 1/10th the chainwork of a 10-minute block. However, in a minority-attacker scenario it doesn’t matter, because at the same number of confirmations the reversal probability depends only on the count, not on chainwork. On the other hand, in the majority-attacker scenario it does matter: redoing the work of one 1-minute block costs 1/10th that of a 10-minute block, but the chainwork needed per minute is unchanged, so just requiring ten 1-minute block confirmations erases that difference.

In the end, I realized what really mattered was whether a 1-minute block results in so much less security that even minority attackers could easily double-spend transactions with 1 confirmation. This turned out not to be the case.

If anyone is interested on the analysis I did, the complete report is here:

8 Likes
#71

Awesome, thank you so much! It’s so cool to get validation in this way, I was in awe when you first showed me this in private!

6 Likes
#72

This is the single best two paragraphs written about Bitcoin in the last 5 years.

Everyone should read it as necessary until they understand, there’s a lot in there.

6 Likes
#73

This is my personal statement and view [not a statement on behalf of OPTN Lab].

I’ve reviewed the CHIP again, and I think @bitcoincashautist has put a lot of quality work into it on multiple fronts, including the proposal itself, the honest evaluation of alternatives, the well-studied effects on light wallets that use BIP37, and the infrastructure around it. I’ve personally worked on integrating SHV/MMR on OPTN Wallet in anticipation of 1-minute blocks.

Overall, I endorse the CHIP. However, implementation readiness, raised by Calin is what concerns me. I’d like to see this happen, but I don’t think there’s any need to rush if more time is needed for review and testing.

So I’m Neutral on activation for now, and will move to Approve once there’s enough confidence that the implementation is ready and safe.

6 Likes