Also on a second thought:
Would it be possible to separate the tick mechanism from the change to blocktime and make it two separate changes?
I mean it’s such a great invention and a great idea, we could (for example) have ticks early and then decide on the precise blocktime later.
Just a suggestion.
Yes it’s possible.
But it’s kinda impractical to split them up, because if we aren’t going to change the block time, why even bother creating a new ticks system? Why merge it unless we are already confident that we will change the blocktime at some point. And if we are going to change the block time, why not set it to the currently optimal value (1 minute)?
What would be required to turn this into approve?
Understood, but without demonstrated support where will the motivation to make the code ready come from? It would suck to have social support and then miss the window just because code is not ready. Is it humanely possible to get at least a preliminary code-build ready to fork chipnet, and maybe be slightly late with final binary signed release (December)?
You’re the 2nd to bring this up today. It’s a technical concern, let’s discuss it here: CHIP-2025-03 Faster Blocks for Bitcoin Cash - #179 by bitcoincashautist
Sure, I even have a test branch somewhere that just adds ticks to RPCs, but what’s the point? I fear it’d only be used as excuse to postpone the actual upgrade, so could end up being self-defeating. We ship ticks, then what? Nobody bothers to start using them because there’s no impending activation that would prompt them, then that is indefinitely used as blocker to activation: “stakeholders are not ready yet because still not using ticks.”
Yeah, indeed this is a good point.
Stakeholders could just not adopt ticks and delay all of it indefinitely.
Approve
Name or project: BCH-1
Statement: BitcoinCash Autist has done extensive work on mapping all the benefits and fail modes of this project. I believe the architecture change is justified, with the pros far outweighing the cons. The main benefit is developers get an option like a slider to choose the level of security they want vs defaulting to 10 minutes. As he mapped, variance also adds considerable instability to Bitcoin Cash’s UX when apps do not accept 0-conf.
For everything that already accepts 0-conf , nothing changes, it remains a viable path for payments, but wider crypto to be sold 0-conf is a hard sell that BCH does not have outreach resources, Its simply easier for crypto apps to accept the common standard of confirmations as security. We cannot predict whether exchanges and so on will raise or lower confirmations, but we know for sure they cannot lower them under 10 minutes under the current design.
For DEFI and cross-chain applications, a 1 minute block time isn’t even fast compared to other blockchains, but it makes BCH at the range where it’s tolerable, vs 10-30 min waiting for a block. Every user that thinks BCH is too slow, is a user we lose, whilst the proposal does not ensure UX improves, it also has the double effect of apps that realize lowering the confirmation low and being safe, gets them to look at 0-conf eventually.
Optionality is the real win of this proposal, and the ticks design means adjustment to the blocktime in the future will be a non-issue for Bitcoin Cash in the case there is a clear argument for raising it back again.
The trade-offs are well documented in Bitcoin Cash Autists own work, these should not be ignored, for the apps again, I see far more enabled than is disabled.
Furthermore, my support of this is outside of the purview of whether this is engineering work that is achievable, that is not my expertise. I am an apps layers guy.
Disapprove.
If it aint broke, don’t fix it.
It wouldn’t necessarily turn it into approve right away but – it would certainly help to get the code over the finish line ASAP w/ more testing, etc. Maybe have Dagur or someone that has advanced AI skillz throwing their AI at it for review only wouldn’t hurt. That would improve the situation.
BCHN is going to do a release very soon for some updates that were planned for a while now, and then we can focus on ye faster block tyme.
I love you so much right now. 
1 minute blocks is extremely conservative in the modern era by all metrics.
If the code isn’t quite ready yet we can easily make it ready, we have the resources.
I, Luke Pryor, APPROVE.
The CHIP’s thesis is that 10-minute blocks are broke. 10-minute blocks are (for now) survivable for BTC because it won the “digital gold” market position. We don’t have the same luxury. Excluding BTC, we have the slowest blocks of any top coin, and of the UTXO-PoW set too: LTC 150s, XMR 120s, ZEC 75s, DOGE 60s. We can’t afford to pretend this doesn’t matter for user acquisition and retention, and I was hoping you’d see it, too. Relevant discussion between Brady and me happened here: 1, 2, 3, 4, 5.
Long shot, but what kind of argument could change your mind?
PS: we’re still agile enough to make this change now, but later we may not be. There’s a possible timeline where we get stuck with 10-minute blocks forever. Using this window now (and installing ticks alongside) prepares everyone for doing it again at much smaller cost: the next time, it’s basically one line of code. That means we’d actually get to benefit from future block propagation improvements instead of just reading about them, and one day we could step down again toward Nervos-style ~10 seconds.
PPS: The day before I wrote the above ZCash voted to go ahead with their 2nd target block time adjustment, which should be telling us something about activation costs and risks concerns. CHIP-2025-03 Faster Blocks: gathering statements of support (and dissent) - #23 by bitcoincashautist
Approve, but with caution
Name or project: mainnet_pat, projects I own or maintain
Statement: the idea is good, improvement of defi experience and block inclusion time variance is a must. But I am not sure about the proposed implementation. The ticks approach seems to bring more complexity.
Disapprove.
In balance doesn’t seem to be a good idea.
Noted. Your most recent substantive objection was the BIP-37/SPV one, and I think @nyusternie answered it point by point. I’ll log your Disapprove as stated.
Name/Project: 2qx, vox.cash, unspent.cash, futurebitcoin.cash, awesomebitocin.cash, CatDex, photons, SAFAs, etc.
Statement: Approve of the concept, if implementation is ready in time.
… with notes about future height nomenclature
And a more elaborate explanation of time systems and the advantages of height based contract logic.
FWIW 2 days ago ZCash voted to go ahead with the 2nd block time change, now from 75s to 25s. And they don’t even have ticks to make the 2nd change easier!
Their main concern was orphan rates, and they’re more tolerant than us (5% instead of our 2%): Zcash Block Time Reduction Appears Safe for NU7 w/ Zebra Only Devnet - Zebra - Zcash Community Forum
I did not see any concerns over activation costs / ecosystem migration. If they had a traumatic experience when moving from 150s to 75s back in 2019 I’d have expected some word about it now.
Thanks, and I’ll log these notes too. Some thoughts about the 10x idea: Wallet Default nLockTime Practices - #15 by bitcoincashautist
Approve
Name: Jon Goose
Project: No project, just a user 
Statement: As an SPV user, I like faster confirmations. I don’t see the 10x header growth being an issue. With regard to the nomenclature (ticks/blocks), I don’t care how it is implemented or if it adds more complexity, as long as it works and it is clear.
Approve
Name: PKR @maxbit_pkr on x
Project:
Statement:
BTC has already established itself as “digital gold” “strategic reseve asset” etc. lets be frank, that wont change. However, theres still a chance for BCH to become “P2P electronic cash”, Bitcoin’s original goal which started this whole crypto industry. For that to happen BCH has to out-innovate and differentiate itself, BCH is already on the right track fixing scalability with ABLA, now it has to fix UX, and nothing is a better UX improvement than speed. I would even go as far as saying that 1min block is the beginning not the end, just look at what zcash is doing. Also, as someone running an exchange / broker, 2-3 block confirmation is pretty standard for account crediting on fastblock coins like dogecoin and yes we trust it far more than 0 block confirmation. Let me close with this Elon quote:
“Ideally, Doge speeds up block time 10X, increases block size 10X & drops fee 100X. Then it wins hands down.”
BCH is probably the closest to what Elon is describing, cease this opportunity!
Disclosure:
Banger.
Welcome to BCH research! Glad to have you in the community & very glad you’ve spoken up on this issue!