That works for me. With faster blocks so many annoying issues just solve themselves.
5 Likes
With Linux you will still see an error message when an app crashes. It will just recover faster than windows BSOD.
Obviously that’s not a fundamental improvement. We should solve the problem completely instead. Besides i never get BSOD personally. 
It’s different layers, the problem should be addressed at both layers.
1 Like
On bitcoin’s two “times”
This is just a follow up on comments in the thread about current wallet nLocktime practices. This is an exposition of height-based computing on bitcoin, and a potential reason it may have a renaissance in the future.
The bitcoin network was bootstrapped on it’s own timestamps (blocks). The height a transaction is committed to a block is the ultimate record, and most granular record, of the time it was spent. The standard Unix timestamps in a block header would never be used internally to resolve when a transaction was spent, because miners can fudge the time they write in a block header. All time logic started with heights as a base unit.
There is a Median Time Past (MTP) timestamp service on bitcoin, which is a derived aggregate byproduct of attested block unix timestamps. It’s created as a side effect of bitcoin’s primary height based timestamping service.
Since 2015, there have been two fairly powerful ways to program bitcoin on an absolute-basis (OP_CLV), or rolling basis (OP_CSV). Both of these OP_CODES came with functionality to enable using the primary timestamps (height) or the more ergonomic unix epoch timestamps (defined in BIP-113’s median time-past as endpoint).
The time op_code upgrades accommodated two ways of coding time on bitcoin. The pluralistic viewpoints about timestamps are as follows:
| Height (primary) | Unix Epoch (derived) |
|---|---|
| Blocks are timestamps | Unix epochs are timestamps |
| Blocks timestamp transactions | Block headers include timestamps |
| Blockchain is a timestamp service | Bitcoin has a timestamp service |
| Time is measured in blocks | Time is measured in seconds and minutes |
| We can know what height it is | We can know an aggregate time that has passed |
| Timelocks overflow after 500,000,000 | Timelocks overflow in 2108 |
Both of the above columns are valid statements about time and timestamps.
For the last ten years, it hasn’t really mattered which definition a time-locking system used. But there MAY be a strong case in the future for many types of financial instruments to use heights over MTP.
When blocks are slow, and the price is low, and things are going great, it can be really tempting to use the conventional definition of “timestamp” (MTP epoch) exclusively in defi contracts. And for contracts among known parties with signed spending paths, the derived epoch usage of the word time is totally fine.
However, if blocks are fast, and there are lots of contracts with MEV on the network with real money on the line, and if miners or institutional traders can find a way to game the MTP timestamps, they inevitability will begin to explore gaming MTP.
As a minority chain with low hashrate, it is somewhat trivial for a well capitalized actor to mine a block (or whole series of blocks), in the same way some people can DDoS all the major exchanges and somehow assure their trades clear. We can assume, as markets develop, if there is a pot of money to be had by gaming MTP that is greater than the cost of gaming MTP, then a well capitalized actor will take that money.
The detractors of decentralized finance seem to love financing market failures then decrying the failures they exploited. If, down the road, a well capitalized actor begins flash-mining chains of blocks to exploit mean time past, they can be expected to also turn around to decry that the system is unfair and rigged against normal users/investors.
The CashScript developer guide [archive] calls the signed and MEV paradigms the “Happy Case” and the “Adversarial Case” and categorically discourages contact developers from creating self-funded MEV-powered anyone-can-spend contracts. Much of the argument against using MEV on Bitcoin Cash is limited to the fact MEV is seen as bad on ETH. The potential, resilience and reliability of a system with eight billion potential executors is largely neglected. However, a number of contract systems have employed MEV and anyone-can-spend contracts with pretty great results.
If open markets using MEV systems with MTP timestamps begin to get gamed on a regular basis, there will be two obvious pathways to toward a fairer system. The slow path would be an upgrade the BIP-113 MTP definition through the CHIP process as a counter measure. Or alternatively, app devs can immediately begin deploying new contracts version using the OG non-MTP timestamps.
Depending on how far into the future an MTP contract system has been programed (decades/centuries), it may not be practical to revert to heights. If OP_CLV and OP_CSV continue to function as before with the old block heights, it may be somewhat maddening for new developers to convert by hand between new and old heights displayed in wallets and block explorers, especially if none of the tooling in the ecosystem supports it.
If block heights simply keep incrementing at CHIP activation, then future defi contract system developers will have to convert between new and old block heights by finding the intercept at the activation height and scaling from there. It’s a simple calculation about as difficult as converting from Fahrenheit to Celsius.
Two alternatives have been proposed to eliminate the need for that calculation. Blocks could increment by 0.1 after activation instead of a whole number; this keeps the old timescale. Or the block height could be increased 10X at activation and old blocks numbers (pre-activation) could be displayed with an extra zero in wallets or explorers that wanted that.
Regardless, apps that take the long view on the “Happy MEV” trail can keep showing a height-based block time equivalent calculated from the tick API. It would just be swell if all wallets and block explorers shared in the benefits of the long game by default.
As previously stated, I think the nomenclature the ecosystem ultimately uses for heights is NOT a blocking concern for this CHIP. All this is just to articulate the hidden value of continuing to accomidate the height-based times as a primary feature.
2 Likes
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.
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.
2 Likes
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!
6 Likes
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.
2 Likes
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.
5 Likes
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.
7 Likes
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.
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.
2 Likes
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.
4 Likes
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.
3 Likes
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
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.
3 Likes
Right, that probably should have been obvious. Thank you!
2 Likes
@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)?
2 Likes
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:
{
"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.
3 Likes
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.
2 Likes