CHIP-2025-03 Faster Blocks for Bitcoin Cash

tom · August 4, 2026, 3:01pm

I object to this proposal because there is a fundamental trade-off that will make faster blocks harm SPV wallets.
To keep Bitcoin Cash a peer to peer electronic cash, we need to safe-guard the SPV wallet usecase, as that is the only known way to scale to billions of people, without introducing centralization and thus control. Lose the SPV usecase and 10 years from now we will hit scaling bottlenecks that become impossible to solve without sacrificing the decentralized nature of the coin.

An SPV wallet without central servers uses a simple concept, it downloads filtered blocks from a full node. Filtering a block implies the wallet sends a filter to the full node in order to allow the filtering to happen on the ‘server’. To not use server side filtering implies the wallet needing more bandwidth and CPU as the blocksize grows, and is thus not viable long term. Server side filtering is it.

A filter will essentially be a list of all addresses, but spending FROM an address should also work and spending FROM an address is not something a full node can do. As such the filter ALSO has a txid-outIndex combination.
So if I send a full node a filter that is viable at block 400, which then returns a transaction which deposits money in one of the addresses, I need to update the filter in order to see the transaction that spends that same money again in block 401. Lucky for us, the server will do this updating for us. So we can just batch block requests.

But there are still trade-offs, if you send 50000 requests because your imported wallet is that far behind, it won’t work. The node that is your server will see you as a DOS attack because a cheap request forces that node to be occupied for a while. Even if you can test this with a (patched) full node in private, it will fundamentally be a DOS attack and thus a real-life healthy network will need to stop that. Which means that the trade-off is smaller requests and incremental handling of data. Full nodes want to serve data, but not just to one abuser. Standard network rate limits.

There are other reasons why you can’t just ask thousands of blocks based on one filter too. For instance the filter is intentionally fuzzy. Which means you get matches that are not actually for you. This fact together with the server self-modifying the filter (see a couple of paragraphs back) will means more and more false positives.
Next to that, with a properly setup privacy wallet you want to avoid reusing addresses. As such a filter you send will get out of date too as it progresses in block-time. There are unlimited number of addresses on a HD wallet, which is great for privacy, but you can’t send a filter for all of them. Practically that won’t fit, but similarly it will mean that your wallet is not being very private.
The trade-off here is also, smaller batches work better.

When you ask for a single block, then the next block-filter will change a little based on the result of the first block. Transactions found that can be spent. Addresses used that can be removed from the filter. Addresses need to be added to not miss transactions.
The filter needs to constantly be adjusted. While you could just make the server do all that, which is largely what fulcrum allows, this is basically giving up on the concept of privacy.
So to repeat the base requirement of peer to peer money, no central servers, this means the filter concept as explained above is the only solution we have.

Latency

The fundamental requirement for private SPV wallets is thus inherently linear. As transactions come in the filter may need to be uploaded again. And if you already asked for 1000 blocks, and figure out at block 50 that that filter needs changing, then that will simply not be processed by the server until it finished those 1000 blocks.

What you need is bi-directional communication. You process the results of a block and decide if the server needs a new filter or not.

But this means you inherently add latency to the protocol. You can’t act on a (filtered) block until it arrived.

My Experience

The p2p network is filled with nodes where some are very slow (maybe some Pi with slow storage) and some are nice and fast. Similarly we have some that have low ping and some have high ping. And naturally the mobile network has extreme gradients in reliability and connectivity. So it is very hard to give numbers. And laboratory tests are very likely optimistic.

Tests I did gave about 100 blocks per second in 2025/2026.

This comes from code and logic written by me which is the result of learning and understanding the trade-offs I wrote in the long part above.

Can it be made faster?
Yes, but you’ll ask the server for more duplicate blocks at best, or get blocked at worst.
You may also just go with a very small number of addresses and reuse those which will similarly make things faster.

So the honest question is this:
Can SPV be made faster without sacrificing the peer to peer nature of our coin?
Answer is: Not by much.

Why then object to the proposal?

Because the fundamental problem is the speed of light, how long it take to ask a full node a question and the answer getting back to you. And that can’t be changed or innovated to be improved any time soon.

Making the block time shorter makes the sync similarly slower than today, on a fundamental level. It will basically make SPV too slow to be usable.

Which will lead the majority of people to prefer centralized solutions and that will kill decentralized peer to peer cash because eventually those centralized solutions will start to censor or worse.

kzKallisti · August 4, 2026, 5:12pm

Thanks for writing this. I’d like to take some time to digest it before responding, but didn’t want to “leave you on read” since I explicitly asked you to post this.

nyusternie · August 4, 2026, 6:17pm

oh boy, perhaps my previous summary wasn’t “obvious” after all

if u would, please allow me an opportunity to address your issues
point-by-point

Your baseline is still BIP37
everything you describe – filter updates, false‑positive accumulation, the need for bi‑directional communication, the linear per‑block dependency – is true if and only if we assume a BIP37‑style bloom filter, where the client uploads a custom filter and the server scans blocks on its behalf
but that is NOT the only SPV model
BIP157/158 compact client‑side filtering eliminates every one of those problems: the filters are deterministic, pre‑computed, and downloaded in a batch with a single request there is NO filter to update, NO false‑positive drift, and NO per‑block handshake – this point was raised in my earlier post and you HAVE NOT addressed it!
Your own code contradicts the “fundamental limit” claim
bca’s test showed that by changing one line in your codebase (the batch size from 9 to 99), sync speed jumped from ~5 blocks/s to ~50 blocks/s.
that’s a 10X improvement with no protocol change – it clearly demonstrates that the slowness you experienced is, at least partly, a soft cap you yourself introduced; not an immutable property of the network
if a simple client tweak can produce such a gain, then the “speed of light” isn’t the bottleneck (at least not yet!)
Batching and DoS
u worry that asking for many blocks at once is a DoS – but that concern only applies when each request forces the node to search – compact filter serving is static I/O; it’s no more a DoS than downloading block headers – even within BIP37, the test above shows that a node can handle a batch of 100 blocks without trouble – a real‑world BCH full node can certainly serve a range of filters without being overwhelmed
DOGEcoin exists!
dogecoin has had 1‑minute blocks for its entire life, and its SPV wallets work fine – if 1‑minute blocks were an existential threat to light clients, we’d have seen it there – the fact that we haven’t strongly suggests the problem isn’t the block interval but the chosen SPV protocol and its implementation
BCH can and SHOULD adopt compact filters
if the CHIP for faster blocks moves forward, it should simultaneously specify that nodes MUST support serving compact filters – this is an incremental, well‑tested upgrade that would give BCH light wallets a level of performance that completely sidesteps the BIP37 bottlenecks you’re describing – there’s NO reason to stay wedded to a 2013 protocol when a better one is already standard in the wider ecosystem

in short, YOUR conclusion that “faster blocks make SPV too slow” only holds if Bitcoin Cash:

locks itself into BIP37 forever
ignores measurable improvements from simple client‑side tuning
disregards the existence of a lighter, more private protocol (BIP157/158) that is ALREADY LIVE!
and pretend that a 1‑minute block time has never been tried successfully elsewhere

that’s NOT a convincing case for rejecting faster blocks on Bitcoin Cash. it’s a case for upgrading the light‑client infrastructure alongside the block interval – and that’s a goal imho EVERYONE should be encouraging

looking forward to the benchmarks that will come out of the upcoming chipnets for this upgrade – that’s where these questions belong

(btw, it took literally every bit of strength in my being NOT to mention even once just how geriatric your wallet infrastructure is – as that would’ve been unkind)

cheers!

BitcoinCashPodcast · August 7, 2026, 2:18pm

In arguing with a 1 minute blocks skeptic, I have hit on this new framing.

I think this is going to significantly change the debate. It instantly demonstrates how 10 minute blocks is simply an argument for the status quo, it has no empirical basis. When said like this, it becomes much more difficult for skeptics to hide behind a lack of better solutions.

It is beholden on the CHIP proposers to demonstrate an overwhelmingly strong case to move. The default is the status quo, and that’s for very good reason. But in this case, the status quo is a significant liability, and nobody has produced any data to prove it isn’t.

Cashrider · August 11, 2026, 10:06pm

Hi everyone. This is my first post here, so please forgive me if I misunderstand some technical detail or repeat something that has already been addressed. I’ve been reading the proposal and the discussion, and I wanted to share some concerns and hopefully understand the case for the change better.

First, I want to say that I do see substantial benefits in moving to faster blocks.

Reducing the gap between instant 0-conf payments and transactions or services that require confirmation seems genuinely valuable. More predictable confirmation times, better UX for exchanges and wallets, faster recovery from situations where 0-conf cannot be used, improvements for some DeFi and cross-chain use cases, lower short-term mining variance, and potentially better behavior during large hashrate changes all seem like meaningful advantages.

So my concern is not that 1-minute blocks provide too little benefit to be worth discussing. I can see why this proposal is attractive.

What makes me uncomfortable is the amount of systemic change required to obtain those benefits, and especially the transition from a network and ecosystem that has been built around a roughly 10-minute block target for many years to one operating at 1 minute.

One concern is network convergence and propagation.

A newly mined block takes some non-zero amount of time to propagate, be validated, and become the chain tip that miners across the network are building on. I understand that blocks would become proportionally smaller, that modern block propagation is much better than it used to be, and that the proposal explicitly analyzes the expected increase in stale/orphan rates.

Still, bandwidth improvements do not eliminate network latency. Reducing the target interval by an order of magnitude necessarily makes fixed propagation delays a larger fraction of the interval between blocks.

I understand the argument that the resulting stale rates are expected to remain within tolerable limits. My hesitation is whether demonstrating that a loss of some propagation margin is tolerable is necessarily the same as demonstrating that consuming that margin is desirable.

Having better propagation technology can be used either to safely support shorter intervals or to leave the network with greater robustness under imperfect conditions. I am unsure where the best balance lies, particularly if BCH eventually operates under much heavier usage, less favorable network conditions, imperfect mempool synchronization, or temporary connectivity problems.

Related to this, I am also interested in the decentralization effects.

My understanding is that higher stale rates can create some advantage for miners with better connectivity and propagation infrastructure, because those miners may lose proportionally less work in competing-block situations. Even if this effect is small, a persistent advantage of that kind could create some centralizing pressure.

On the other hand, I also understand that finding blocks more frequently reduces short-term mining variance, which may benefit smaller miners and pools.

Because those effects point in opposite directions, I don’t think it would be accurate to simply say that shorter blocks centralize or decentralize mining. What I would like to understand is how confident we can be about the net effect in the real BCH network, and how much of that confidence comes from empirical evidence rather than models.

But my biggest concern may actually be the transition itself.

Bitcoin Cash is not only the consensus implementation. There is a large surrounding ecosystem of wallets, exchanges, explorers, indexers, SPV clients, mining software, payment processors, APIs, libraries, scripts, contracts, private integrations and services developed over many years.

Some of these systems may contain explicit or implicit assumptions about block frequency.

The obvious examples are applications that reason in terms of confirmation counts or use block height as an approximation for elapsed time. After the change, one confirmation would arrive much sooner and would represent roughly one tenth of the expected accumulated proof of work that one confirmation represents today. Applications that actually depend on the current security meaning of “1 confirmation” would need to adjust.

Well-maintained exchanges, wallets and infrastructure providers can be informed and updated. What worries me more is the long tail: old software, abandoned libraries, closed-source services, private scripts and integrations that nobody involved in BCH development necessarily knows about.

And I think the more dangerous failure mode is not necessarily software breaking completely.

A program that crashes after the upgrade is visible and can be fixed. A program that continues running while its assumptions about confirmations, block height, elapsed time or security have silently changed may be much harder to notice.

That is why I wonder whether the migration risk deserves as much attention as the steady-state behavior of the new network.

How can we know when the ecosystem is sufficiently prepared?

Would it make sense to have an extensive test period under realistic conditions, a formal compatibility/readiness process, documentation specifically aimed at third-party developers, an inventory of common assumptions that need to be audited, and outreach to major infrastructure providers well before activation?

I would also be interested in whether there is any practical way to identify less obvious dependencies on the current block interval before activation rather than discovering them afterward.

More generally, my inclination with consensus changes is to be conservative, but I don’t mean that the status quo should be preserved simply because it is the status quo. Ten minutes is not a sacred number, and if technology has advanced enough to safely obtain meaningful benefits from a different interval, I think that deserves serious consideration.

My concern is that changing an established consensus parameter by 10x has a very large blast radius. Some risks can be modeled reasonably well inside the protocol, while interactions with an open ecosystem of third-party software seem much harder to bound.

So at this point I am not convinced that 1-minute blocks are a bad idea. In fact, I think the benefits described by the proposal could be significant.

I am mostly trying to understand how confident we can be that:

the reduced propagation margin remains sufficiently robust under adverse and future conditions;
the net effect on mining incentives does not create meaningful centralizing pressure;
third-party software does not silently inherit incorrect assumptions after the change; and
the transition itself can be made conservative enough that we do not discover important dependencies only after activation.

For people who have worked on this proposal much more deeply than I have: what gives you the most confidence specifically about the transition risk? And what safeguards or readiness criteria would you consider sufficient before making a change of this magnitude?

I’m asking sincerely. I see real value in the proposed benefits, but I would like to better understand how we can obtain them without taking unnecessary systemic risk.

Warlock5150 · August 12, 2026, 5:15am

The code changes are fairly simple for any half decent programmer. Simply treat block index after a certain height as a tenth of a block for comparisons. Create an extra index variable so that OldStyleIndex=(BlockIndex-LASTSLOWBLOCK)/10+LASTSLOWBLOCK;

Then we just go through the code and figure out the spots where we need to use OldStyleIndex instead of BlockIndex. Personally, I would change the variable name from BlockIndex to NewBlockIndex so that the compiler would catch any code that I missed.

Crypto code engineers already plenty of experience working much faster blocks thanks to Litecoin, Dogecoin, Ravencoin, and lots of other lesser known crypto coins. Any concerns about faster blocks should show why this has been a problem for the previous noted coins. Many crypto coins have also changed block target times repeatedly without any issues.

Centralization is not really an issue any more. It was a deep concern in the early days of crypto because centralization would have allowed governments to work together to try and destroy all the mining farms at the same time. Those worries are long gone. We also have another form of decentralization via multiple cryptocurrencies.

I do think you are right about one thing. It will probably have an effect on some 2nd party code. But this isn’t a good reason to continue avoiding updating to one minute blocks. In fact, I believe this is good argument to stop delaying. This is the type of problem that actually gets worse over time. Delaying just makes the problem of 2nd party code worse, not better.

And there is another huge danger in constantly putting off this upgrade. A ton of peer-to-peer exchanges require at least one confirmation. This isn’t about hash rate or security, it is just how their software sets up escrow. The longer this upgrade is put off, the less relevant BCH to these exchanges.

websalga · August 12, 2026, 10:42am

What if we gave the network more intelligence and flexibility, allowing it to periodically elect a number of master servers that would serve for, say, 24 hours? Their addresses would be known only to the network, with no human intervention.

During those 24 hours, these servers would act as priority servers . Once their term expired, they would cease to have priority, and the addresses of the priority servers would change. The network itself would select and elect a new set of machines in advance, according to some randomized and protocol-defined rule.

In Brazil, they managed to create PIX , an extremely fast payment and transfer system, but it relies on centralized infrastructure. I understand that introducing privileged servers goes against the principle of decentralization, and that is not what we want. However, what if the network itself had a fair mechanism for electing servers to act as temporary leaders , with a clearly defined term — a beginning, a duration, and an end?

The network itself could then manage these fast transactions. The elected servers would have a very specific role during their 24-hour term, or whatever duration proved appropriate.

The other servers on the network would continue processing ordinary, smaller transactions and synchronizing normally. However, during the elected servers’ term, heavier workloads could be routed directly to them.

I am suggesting 24 hours merely as an example; the “reign” could be considerably shorter.

This way, the system could remain democratic: there would be no permanently privileged servers, and the network itself would manage the rotation of the machines that temporarily assume these roles — effectively taking the “throne” for a limited period.

A machine would also be prohibited from serving two consecutive terms within a predefined time interval , preventing the same servers from repeatedly occupying these priority positions.

ShadowOfHarbringer · August 12, 2026, 8:47pm

I think you have started entirely another big topic.

You should make your own thread. In this thread, almost nobody will read it because your reach will be smaller.

bitcoincashautist · September 6, 2026, 8:49am

Dogecoin has 0.15% orphan rate with 1-minute blocks. Given that empirical data, our modeled 0.41-1.94% is conservative. Nervos has 10s blocks and it sits at ~3% orphan rate. Should we consume some margin to reap the benefits of faster blocks? Hell yes, even with 1-min blocks we’ll be far from cutting it close. Satoshi was comfortable reasoning with ~10% orphan rate as his example for the 10-minute choice, five times our tolerable threshold.

Network will work fine even with imperfect conditions, even with 2% orphan rates. Why are orphan rates a problem? Because they skew mining payoffs. End users don’t typically notice orphans because their TX just gets mined in whichever block wins the race. But at 2% the skew is still too low for it to make much difference between miners’ profitability. BTC has lowest orphan rates and yet miners still clustered, why? There must be some other, more relevant, reason - like hardware, energy, and capital access, not orphan rates.

And it’s not the network who experiences “temporary connectivity problems” - it is individual participants, who will have incentive to resolve it ASAP. That’s the beauty of a distributed network - the network can’t go down or degrade just because some participants experience transient problems.

Both Monero and Zcash successfully transitioned, and Zcash is planning a 2nd block time change now! So, I think these fears are overblown. But this deserves its own section, so I added it here: ac-0353f40e / Faster Blocks for Bitcoin Cash · GitLab

On readiness: the safeguards are already specified in the deployment path — chipnet activates about six months before mainnet, with the full node implementation and boundary test vectors exercised there first; the lock-in date is fixed ahead of time so every stakeholder has a known deadline; and the outreach cadence (node teams, pools, exchanges, wallets, indexers) is the same one every prior BCH upgrade used.

bitcoincashautist · September 15, 2026, 2:29pm

From @cculianu, moving here because it’s technical:

The CHIP has a security analysis but this particular concern is not specifically called out even though it’s covered by the “Security Against 51% Attack” and “Security Against Double-Spend Attack” sections.

It’s still ~200 txns per 10 minutes and 0.025% of BTC’s chainwork per 10 minutes. Fundamentally our security is purchased by coinbase per hour, and that number stands still under this CHIP.

A 10% attacker mines about one in every ten blocks, at any target time. Over a 100-minute window that’s about one 10-minute block’s worth of his chainwork in the old world, or about ten 1-minute blocks in the new one. Same work either way, and the same expected interruption: one attacker block every ~10 blocks, which is one every ~100 minutes at 10-min blocks and one every ~10 minutes at 1-min blocks. An empty block here or there is noise; grief is a rate problem, and the rate is fixed by hashrate, not by block time.

What’s actually different for UX: with 1-minute blocks, you get more chances per hour to squeeze your honest block in between the attacker’s blocks. To really grieve the network takes continuous power sustained over time. The cost of sustaining it per hour is identical, because it’s paid in the same coinbase-per-hour that this CHIP leaves unchanged. Block frequency just doesn’t move that number.

kzKallisti · September 15, 2026, 9:44pm

In the ten 1-minute blocks 10% attacker scenario, how does that interact with BCH’s 10-block rolling checkpoint?

Edit: I’m not claiming that there may be a problem (per se) with that interaction btw - if you only have 10% hashrate, it’s very unlikely that you’ll mine 10 blocks in a row

bitcoincashautist · September 16, 2026, 4:52am

The checkpoint is after 100 in that case, it’s being specified in ticks so same wall clock time, and block count gets scaled to match.

kzKallisti · September 16, 2026, 5:23am

Right, that probably should have been obvious. Thank you!

bitcoincashautist · September 16, 2026, 4:37pm

@mainnet_pat copying the technical part of the statement here for discussion.

Which part of the proposed implementation concerns you? Just the ticks? Ticks are really just an abstraction layer: fully compatible implementations would be possible without using them. On what layer is your concern: the internal abstraction (rebasing internal consensus mechanisms to ticks) or the external API and proposed adoption by downstream software (which is opt-in, I expect many will stick to height)?

mainnet_pat · September 16, 2026, 5:40pm

I think both. As I understand it, ticks are a drop-in replacement for intervals between blocks aiming to be nearly constant. My concern is that regular newcomers will struggle to understand it. The API change is also what would possibly make the developer newcomers to struggle.

bitcoincashautist · September 16, 2026, 7:58pm

It’s exact idealized time, not approximate. Ticks are the cumulative sum of each block’s target interval: 600s before activation, 60s after. This is independent of actual mining time. Real solvetimes are random e.g. when measuring 1M blocks they will not add up to exactly 600M seconds; height 1,000,000’s tick is exactly 600,000,000 regardless of when its blocks were mined, and if we switch there then block 1,000,001 adds exactly 60 more instead of 600. Example getblockheader 912123:

{
  "hash": "0000000000000000019f64605d353ae88d8928361d8bce51b43bf474d4520e2b",
  "confirmations": 38737,
  "confirmations_ticks": 23242200,
  "height": 912123,
  "ticks": 547273800,
  ...

Ticks are just height and confirmations expressed in uniform time units. Existing height-based code and displays keep working unchanged. Height remains the block index, and the new fields can be ignored until a developer actually needs a uniform measure or forward compatibility with a future target-time change. Ticks only enter where a rule needs idealized time; nothing about ordinary chain reading changes.

One alternative was to keep 10-minute units and make the field decimal, so my 600,000,060-tick example would read height_10min = 1,000,000.1. See Wallet Default nLockTime Practices - #11 by bitcoincashautist. But “fraction of a block interval” is less natural and more error-prone for something that’s supposed to be exact.

For external API consumers: the fields are additive and opt-in. For newcomers, of all the concepts BCH devs meet, this seems like one of the easier ones. It’s just a measuring tape for a stack of uneven boxes: 600mm and 60mm boxes measured in millimetres. Ask for a 1,800mm stack and 3 × 600mm boxes satisfy it just as well as 30 × 60mm, or a mix of 2 × 600mm plus 10 × 60mm.

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.

Cashrider · September 18, 2026, 2:51pm

My only objection is that I don’t think these different networks are directly comparable. Their experience is certainly useful evidence, but each network operates under different conditions: block sizes, propagation mechanisms, topology, miner distribution, usage patterns, infrastructure, etc.

Treating one network as direct evidence for another feels a bit like saying ships can safely travel faster because airplanes travel much faster. They are different systems operating under different constraints.

So I wouldn’t dismiss the Dogecoin, Nervos, Monero or Zcash examples, but I also wouldn’t assume their results transfer directly to BCH.

BitcoinCashPodcast · September 18, 2026, 4:50pm

It’s more like saying X boat is faster than Y boat because we surveyed all boats and the ones with X-type engines outperformed the ones with Y-type engines as an overwhelming trend. Ok, we don’t know for OUR SPECIFIC boat what X or Y engine would work in practice until it’s put in there, but you can’t get better evidence than the closest comparisons.

Of course, BCH is its own system. Yes, nothing else is DIRECTLY comparable to it. But other cryptocurrencies are the closest analogues we have. So that’s what we’ve gotta go with, if we ignore those we’re just guessing blind & and if we can’t make some comparisons then we just have no data instead of some pretty good data.

vac · September 22, 2026, 9:20am

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 · September 22, 2026, 10:21am

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.