CHIP-2025-03 Faster Blocks for Bitcoin Cash

[vac]

I am intending to make an approval statement in the other thread, but I want to bring up a few items.

Overall thoughts:
The industry has proven that faster block times on the order of a minute work well. The user experience is much better. Having read through the CHIP, it is good engineering and its cleaning up a lot of stuff. I think there is risk in ossifying around a fixed block time. Last week BCH reached an all time low to BTC. That is the universe telling us to get better. The 1 minute block time itself has been de-risked by other chains, the main thing we’re facing is logistics.

Technical items

Confirmations vs ticks:
The main thing I want to point out is that we are going from fewer blocks to more blocks, so we get security benefits of going from fewer to more confirmations. We can simply multiply all the confirmation logic by 10. My concern is that, in the future, if we ever want to increase the block time, we can’t simply do that. A new contract or service that uses only ticks might go from several confirmations down to only 1 or 2 confirmations if we were to raise the block time in the future. Same amount of work, but less security because 1 or 2 confirmations is never really final from a statistical point of view, even if they were an hour. So what I am advocating is that the chip needs to set out guidelines for contract writers and service owners if we were to ever raise the block time. The chip should specify that if that were to happen, contracts and services that don’t specify confirmations would be in danger of going to fewer confirmations. And contracts and services that specify block height would be in danger of taking more time, because we would not proportionally reduce the number of confirmations in the future. We should make this clear now, so that AI agents who are coding up these contracts and services in the future will understand what going the other direction would look like, and can take that into account in their security assumptions. Confirmations and wall time are two dimensions which are not the same.

In summary, going to a tick system gives us flexibility, but we need to establish conventions and documentation now about what increasing the block time would look like in case it was ever needed, including say from shorter than 1 minute to back to 1 minute.

Furthermore, if we were to ever go with a dynamic block time, for whatever reason, this would only compound.

[bitcoincashautist]

@vac

My concern is that, in the future, if we ever want to increase the block time, we can’t simply do that. A new contract or service that uses only ticks might go from several confirmations down to only 1 or 2 confirmations if we were to raise the block time in the future.

Because we don’t want to break existing contracts, the contract locktime enforcement will continue to use 10-minute units, so +1 locktime in height mode will actually require +10 1-minute blocks. The locktime will function in “chunks” of 600 ticks.

So if a contract asks for +1, it is now satisfied with +1 10-minute block. After the upgrade, it will be satisfied with +10 1-minute blocks. If for some reason we change block time to 2 minutes, then the contract will be satisfied with +5 2-minute blocks. What I’m saying is: contracts in height mode will require higher underlying block counts - unless we’d change target time to >10 minutes. I think we can promise to never change block time to >10 minutes, so these contracts will always be getting more finality against minority hashpower, from a statistical point of view.

For contracts that specified locks in time mode, they were already exposed to the risk of variable block count, a contract asking for +40 minutes could be satisfied with 1, 4, or 8 10-minute blocks, depending on variance.

It’s outside the CHIP’s scope to offer finer-grained locktime opcodes, but I hope one day we can offer something like a full width 64-bit field which would let you specify:

• locktime in ticks
• locktime in block count
• locktime vs MTP

So contract authors can express exactly what they want.
With current locktime system that’s not possible, so we have to pick a trade-off.

But yes, we should highlight somewhere that we can’t promise that target block time will always monotonically reduce. We can at least promise the ceiling of 10 minutes, which will avoid some gnarly edges. This leaves us with the option to manually or dynamically (should we ever revisit that) change in the 0-10 minute range.

For services that gate on confirmations_ticks, the trade-off is the mirror image: a fixed tick threshold preserves chainwork but not confirmation count. If the target time ever rises, the same threshold is met by fewer confirmations, which weakens statistical finality against minority hashpower even though the chainwork is identical. The two dimensions are not interchangeable — ticks measure work, confirmations measure the exponential decay of a minority attacker’s catch-up odds — so a service that cares about both should keep a minimum confirmation-count floor alongside any tick threshold rather than relying on ticks alone.

Yeah, I’ll add this considerations to CHIP somewhere, good call to be explicit about the implications.

[bitcoincashautist]

@vac done: readme.md · master · ac-0353f40e / Faster Blocks for Bitcoin Cash · GitLab

[vac]

Great! Thanks. This captures this edge case within the CHIP. Not to make too many asks, but to me having these as part of the API doc strings for the data fields — with precise descriptions of the assumptions — is key. That way, it’s in the codebase, and design intent which can’t be learned from the code alone is captured at the point where the API is used. Is there any way we could craft the doc strings as part of the CHIP so that implementations directly have them?

[vac]

I added my approval, though I did put this paragraph in there:

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?

[bitcoincashautist]

@vac

balkanizes the internet

Could add a little section in risks. If that happens we’d have to evaluate exact conditions and decide whether to increase block time, or reduce blocksize limit, or both, or just suck it up if it is some transient problem, or engineer block propagation relays to keep working with the same network parameters even in those conditions – that would be ideal, use the crisis to further optimize our software and network topology and keep ticking with good UX even at a time of crisis.

[vac]

I think having such an analysis and plan ahead of time is extremely valuable so that its available in a time of crisis and everyone is on the same page about what options are available. Trying to figure all that out during the crisis could be a disaster.

[bitcoincashautist]

@vac

API doc strings for the data fields

Sure, we can look at that now, here’s the current WIP implementation doc string:

    return strprintf(
        "  \"hash\" : \"hash\",               %s(string) the block hash (same as provided)\n"
        "  \"confirmations\" : n,           %s(numeric) The number of confirmations, or -1 if the block is not on the main chain\n"
        "  \"confirmations_ticks\" : n,     %s(numeric) The confirmations as measured in ticks, or 0 if the block is not on the main chain\n"
        + sizeLine +
        "  \"height\" : n,                  %s(numeric) The block height or index\n"
        "  \"ticks\" : n,                   %s(numeric) The block ticks (seconds)\n"
        "  \"version\" : n,                 %s(numeric) The block version\n"

It should be a sentence or two max, not to clutter things, any ideas?

[vac]

@bitcoincashautist

        "  \"confirmations_ticks\" : n,     %s(numeric) The confirmations as measured in ticks, or 0 if the block is not on the main chain\n"

“How many ticks have been confirmed, calculated as confirmations*ticks” could be good way to show that this is a derived value that depends on two other things rather than its own primitive.

Overall though, these one liners are very concise. Maybe there is a more appropriate place to put in a bit longer documentation.

[emergent_reasons]

@bitcoincashautist

For internals: is implementing without ticks actually simpler? You still have to write a switch point and hand-adjust every time-sensitive consensus rule from 600s to 60s. That’s doing ticks-like math manually, once; a second target-time change would mean doing it again. Ticks make the switch a data-driven schedule. The initial activation is just the entry {H, 60} so internal code auto-adjusts, and a future change is another appended entry instead of another code pass.

You asked me to respond in this thread on the topic of ticks vs. just faster blocks. This is the key point, and we shouldn’t be confident about the answer to this without implementing it first. Then it should be obvious whether it’s a straightforward improvement that gives us the additional benefits of ticks, or if we need to seriously consider dropping ticks due to dangerous complexity.

[bitcoincashautist]

@bitcoincashautist

Could add a little section in risks.

@vac @albaDsl check it out, your inputs helped shape it!

“System Rigidity and Catastrophic Resilience”

[vac]

(I moved this here from the approval thread, responding to @albaDsl)

I can see a world where a 1 minute block time could help with resiliency. Lets say an undersea cable was cut. Most likely, the network would still work fine at 10 minutes or 1 minute. But with 1 minute, we may notice more variance. This will cause the community to dig into it, make optimizations around the network, build tools and plans, etc. Whereas with a 10 minute block time, perhaps less attention will be paid to such an event because 10 minutes is so long that its less interesting. With 10x faster blocks we have 10x the data to work with. In addition, all the technical work going into making the 1 minute blocks work gives us flexibility. We’re working on the systems needed, gathering learnings and figuring out things we couldn’t know without making the change. I think opening the hood and working on this is good for resiliency.

However, one thing I’d really like is some concrete contingency plans. Like, this configuration is the planned fallback if there ever was a problem. Kind of like how you are supposed to have a fire escape route planned out of a building, or a rendezvous point if there is a calamity. So if our communications channels get shut down (like we lose DNS), people will be able to ask their local AI what to do and it will know what config to try because its something we’ve already planned out.

Furthermore, a concrete fallback plan is useful for app developers so they don’t start making code that breaks if things ever change. Reviewers can always say “your app breaks if this fallback plan were ever implemented”. Having our resiliency analysis be principles only doesn’t give a real worked example people can point to and think about.

Maybe this kind of contingency planning would be its own chip or research, but I think tying it to this upgrade gives it the attention and thought that it would otherwise not get (however, that said, we have to focus on the real/essential work before spending too much time on hypotheticals like this).

@bitcoincashautist

@vac @albaDsl check it out, your inputs helped shape it!

“System Rigidity and Catastrophic Resilience”

Thanks! First half is great. I think the second half of the section could eventually have a concrete example worked in.

[BitcoinCashPodcast]

1 minute blocks in 1 image. Data attached from Claude.

[CashDragon]

When rediscovering BCH ~2023 I was rather surprised that blocks were still 10 minutes given all the upgrades that had taken place over the years. Really glad this is now front and center.

[bitcoincashautist]

@albaDsl 's latest post made me rethink the purpose of algorithmic adjustment (like what Nervos has): CHIP-2025-03 Faster Blocks: gathering statements of support (and dissent) - #106 by bitcoincashautist

I’ve reframed the “Evaluation of Alternatives: Algorithmic Target Time” and “System Rigidity and Catastrophic Resilience” to present it as a risk-mitigation option, in case we should further reduce the target time floor.

The idea: in normal operation the algorithm would sit at or near the floor set by a CHIP, and only slow down when presented with on-chain evidence of elevated orphan rates. The adjustment reads committed orphan headers, so it stays objective and deterministic — every node computes the same thing from the same chain, with no dependence on local observation.

In other words, lowering the floor doesn’t permanently consume the safety margin, because a future mechanism could widen the interval when conditions demand it. The margin becomes a response rather than a reserve .

It’s not needed for this CHIP — 1 minute is still conservative — and it’s out of scope here for a scope reason (it’s stateful, and depends on ticks existing first). But it’s worth keeping on the table for a future upgrade.

cc @vac

[albaDsl]

On your comment from the other thread:

Also, taking SN’s 10% consideration, suppose a bottleneck between regions happens and when announcing block to each other they have 10% (~6s prop time!), but when announcing to local miners they have 1%, it again averages out to 5.5% – if clusters have 50:50 hash distribution (e.g. America / Asia split).

I’m interested in the serious storms, so what happens when the block propagation time on the cross-regional link goes to 30s or beyond (for 1-min blocks). I think this can happen as the TCP connection capacity (C bits/s) across a cross-regional link drops and starts to approach the transaction rate (R bits/s). It could be driven by blocktx taking a long time on a constrained TCP peer link.

In this case there is the centralizing force on mining but we are also starting to get into continuous contention and reorgs. So a semi-failed state we would not want to get stuck in for an extended time.

@bitcoincashautist

purpose of algorithmic adjustment

Haven’t had time to think about adjustable block time. How do exchanges enforce a certain amount of proof of work? Rather than hard coding x confirmations they ask the node perhaps.

[bitcoincashautist]

@albaDsl

How do exchanges enforce a certain amount of proof of work?

Ticks! (cumulative sum of block target times)

If you want more than 1h worth of chainwork, just require confirmations_ticks > 3600 and you don’t have to care about target block time. Example upgraded getblockheader 912123 RPC output (so yes, ask the node):

{
  "hash": "0000000000000000019f64605d353ae88d8928361d8bce51b43bf474d4520e2b",
  "confirmations": 38737,
  "confirmations_ticks": 23242200,
  "height": 912123,
  "ticks": 547273800,
  "version": 939524096,
  "versionHex": "38000000",
  "merkleroot": "a0e4df906b7a0f3942047cc69cfbb58c38ee3171ed219e9f3230db52e0f012cf",
  "time": 1755484753,
  "mediantime": 1755482263,
  "nonce": 1127818599,
  "bits": "1801c7e2",
  "difficulty": 617418937555.0542,
  "chainwork": "0000000000000000000000000000000000000000027983ef0d3b834a13656daf",
  "nTx": 290,
  "target_time": 600,
  "next_target_time": 600,
  "previousblockhash": "0000000000000000011c79cc931a38e909e0fe6a84d545c581d29de1a99907ad",
  "nextblockhash": "000000000000000000390e68745785af37b18f5667c7b27bce8563837dd3db55",
  "ablastate": {
    "epsilon": 16000000,
    "beta": 16000000,
    "blocksize": 165322,
    "blocksizelimit": 32000000,
    "nextblocksizelimit": 32000000
  }
}

More on that here:

• Blockchain Height Abstraction
• Recommended API Changes

[albaDsl]

@vac

I can see a world where a 1 minute block time could help with resiliency.

Yes, I think there are aspects where 1-min blocks help resiliency. It should be less likely for that 10-block/100-block checkpoint rule to cause an accidental fork. And we reduce mempool RAM requirements on nodes. Yes, the ticks system gives the flexibilty to adjust the block time up if needed.

@vac

Furthermore, a concrete fallback plan is useful for app developers so they don’t start making code that breaks if things ever change.

In case of a catastrophic scenario, I think the fallback would be to manually increase the block time, which app developers should take into account in disaster planning.

[BitcoinCashPodcast]

I tend to be heavily in favour of anything which we can bake into the chain to make it automatically flexible & auto-healing. The per-block DAA is a huge win (in all kinds of scenarios - hashrate fluctuations driven by price, by changes in tx volume, by new chain splits occurring maliciously or not, by changes for miners worldwide, by outages, by anything) so I’m a huge fan of that. Same with ABLA, the flexibility & response to changing conditions is just baked into the chain.

In general, we want blocktimes to be consistent. But if we can code in some kind of algorithm that lowers or increases the blocktime under very extreme scenarios with on-chain proof of orphans or something like that, I think that’d be ideal. If we have a disaster recovery mode built into the chain itself for slowing down blocks, that sounds even better.

Wherever possible, we want BCH to “self heal” itself without direct community intervention. That’s an antifragile system, like most biological systems are.

Note that markets also work this way, although that’s not at the protocol level. So the peg mechanism for PUSD is another example of a “self healing” automatic mechanism.

[vac]

@bitcoincashautist

I’ve reframed the “Evaluation of Alternatives: Algorithmic Target Time” and “System Rigidity and Catastrophic Resilience” to present it as a risk-mitigation option, in case we should further reduce the target time floor.

Great additions. This is not only a good option for us, but it also makes this possibility clear to app and contract writers. For this to be a legitimate future possibility, we kind of have to state it now so that such a change wouldn’t break important systems in the future. So this future thinking now is critical.

We should also consider, in a disaster scenario if there are any side effect from going to a shorter to a longer block time, such as node memory requirements. We wouldn’t want our backup plan to actually itself cause a problem.

It is interesting that Nervos came up with this - they have 10s block times and so that drove them to this optimization which makes them more resilient. More support to the idea that going to a shorter block time could help spur improvements and actually make the system overall more resilient than if we were rigidly fixed to a single long time.

@bitcoincashautist

@albaDsl

How do exchanges enforce a certain amount of proof of work?

Ticks! (cumulative sum of block target times)

Shouldn’t we normalize and recommend that services have both a tick and a conf requirement? Saying ticks only could result in a single conf if the block time ever goes up and they don’t set a high enough tick number. (Though strictly for the question of how do we enforce a certain amount of proof of work, the answer is just ticks)