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.
