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.
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
@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)?
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.
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:
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.
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.
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.
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.
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.
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?
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?
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.
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.
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?
“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.
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.
