Author: Anthony Towns 2022-10-18 07:00:45
Published on: 2022-10-18T07:00:45+00:00
The bitcoin-dev mailing list has been discussing whether accepting unconfirmed "on-chain" payments should be continued indefinitely or if a line needs to be drawn now. Some developers dismiss the risks, while others argue that they should be made clear to enable businesses to take action and avoid potential harm. The ongoing debate regarding the deployment of zero-conf applications has raised concerns over the immediate risk to existing businesses still accepting unconfirmed transactions.The initial approach of enabling full Replace-by-Fee (RBF) wasn't making the assumption that the enablement itself would reach agreement of the economic majority or unanimity. Full RBF doesn't need a majority or unanimity to have an impact, but it needs adoption by perhaps 10% of hashrate and some way of finding a working path to relay transactions to that hashrate.New data points have been learned since Dario's email, including the acknowledgement of the long-term full RBF to align miner incentives and the preference for a clear timeline based on a block height rather than pollination deployment. Releasing Core with full RBF support could mean that full RBF is usable on mainnet within two to three months, supported by perhaps 5%-20% hashpower, but it may still require special effort to find a peer that can relay full RBF txs to that hashpower.Core developers are supposed to be top technical experts at bitcoin, which means they're the ones that should have the best understanding of all the implications of policy changes like this. If people think core devs are wrong, they can still let that line blow away in the wind by running different software, configuring core differently, patching core, or whatever else.However, removing responsibility from core developers seems like it's very much optimizing for the wrong thing. If the choice is between "bikeshedding" and "merge a PR, then ignore feedback that it's harmful," it would be better to choose the bikeshedding. Moreover, relying on node operators turning on the setting provides a smoother approach offering time to zero-conf services to react in consequence. So the current path definitely belongs more to a 3) approach.It would seem that doing something like #26323 only after 24.0 is out does nothing to mitigate whatever immediate risk there is to bitcoin businesses/users. Slowing down the process seems like a big win for anyone who has been doing zero-conf, and having it easy to find a path to miners when it is supported seems like a big win even given a cost of a few months delay. What's the point of having rcs if you're going to ignore negative feedback?
Updated on: 2023-05-22T21:37:10.239667+00:00