Hi AJ,
> 1) Continue supporting and encouraging accepting unconfirmed "on-chain"
> payments indefinitely
>
> 2) Draw a line in the sand now, but give people who are currently
> accepting unconfirmed txs time to update their software and business
> model
>
> 3) Encourage mainnet miners and relay nodes to support unconditional
> RBF immediately, no matter how much that increases the risk to
> existing businesses that are still accepting unconfirmed txs
To give more context, the initial approach of enabling full RBF through #25353 + #25600 wasn't making the assumption the enablement itself would reach agreement of the economic majority or unanimity. Rather, it would give the tools to node operators to build full-rbf relay paths and as such to fulfill their applications requirements (e.g lightning dual-funding). Without denying that such equilibrium would be unstable, it was designed to remove the responsibility of the Core project itself to "draw a hard line" on the subject. 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. While this way cannot be denied to be a zero-risk deployment for business accepting unconfirmed transactions, it should be weighed in face of multi-party contracting protocols encumbering an annoying pinning vector. It sounds to me that an adequate way to resolve such a "split-risk" situation has been to adopt a "micro" release practice rather than a "macro" one, namely offer the options to node operators and let them vote with their respective economic traffics.
Since Dario's mail, I think we have learnt new data points, a) on the long term full RBF to align miner incentives is acknowledged and b) a clear timeline based on e.g a block height is favored over the pollination deployment.
As such, I think it makes sense to revise the full RBF deployment approach, concentrating the discussion on the reasonable time buffer we should adopt before activating full RBF on mainet. A time buffer realistic with respect to the engineering,
operational and vendoring needs of the zero-conf businesses/applications. I hope both #26305 and #26323 answer those criterias. Tie-breaking between both, I believe I would favor something like #26323 though only post 24.0 to avoid introducing a bikeshedding precedent in terms of release process, and with a longer timeline to be sure we ship 25.0 before the activation day. Though listening to more feedback and decision factors, if we have more things to consider.
> But if (3) *is* what we're really trying to do, I think it's a bit
> disingenuous to assume that that effort will fail, and tell people that
> nothing's going to change on mainnet in the near future [8] [9] [10]
> [11]. If pools are starting to allow replacements of txs that didn't
> signal according to BIP 125 and mine blocks including those replacements,
> then it's true that zero-conf apps are in much more immediate danger
> than they were a month ago, and as far as I can see, we shouldn't be
> pretending otherwise.
Concerning my statement only, it should be re-contextualize with the other statements calling the zero-conf operators to adapt their services, or raise concerns, or be proactive at least [0]. On the other hand, from my perspective, a status quo situation is also unsafe, as we left things like multi-party coinjoins being DoSed by deanonymizing attackers. So in case of risk arbitrage situation, as developers, best we can do is be vocal about it and if possible find a common ground among all stakeholders. And I think this is what this current thread aims to achieve, which I would say is a healthy release process.
Best,
Antoine
[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html