Hi John,
Thanks for expressing your thoughts on the current state of `-mempoolfullrbf`, from the perspective of a merchant and zero-conf proponent. First and foremost, we're dealing with a nuanced and rich topic, implying not only the inner workings of Bitcoin Core mempool policy rules, the current topology of the peer-to-peer network and transactions propagation across it, the miner block construction strategy, but even further the consequences on multiple class of use-cases such as on-chain payments, Ligthning and coinjoins.
In the present case, and as always, I'm only speaking for myself, based on my years-long experience contributing to Bitcoin Core, the wider Lightning ecosystem and few other open-source projects. While there is a self-awareness of the scope of my statements expressed in one of my (rough) domains of expertise, as usual I invite anyone to reason by oneself and check my saying for opinions and wrongs.
That disclaimer said, in matters of feature removal, to the best of my knowledge the Bitcoin Core's "decision-making" process should be followed like any other code change, as documented by the CONTRIBUTING.md [0]. In the conceptual appreciation of the change in soundness, of course the ecosystem impacts or utility are lawfully decision grounds, as we've done in the past for many Lightning/L2-related PRs.
W.r.t `mempoolfullrbf`, it has been argued on one-side it would a benefit for some wallets usage (i.e replace non-signaling transactions from legacy software [1]) and multi-party applications/ contracting protocols (i.e remove a DoS vector [2]). On the other hand, it would change the security model expectations of the 0confs operators. Whatever the evaluation one can have of the soundness of those expectations, I think there is a lowering of the technical bar one should reach to accomplish a double-spend.
During the last months of discussions, we had a mempool policy design philosophy proposed aiming to accommodate all the Bitcoin use-cases alive on the network, under the conditions they're not harming the network interests [3]. Under this paradigm, we could have a policy regime for each use-case, and we can devise another special rule to solve the DoS vector affecting multi-party applications/contracting protocols have been proposed [4].
With that in consideration, there is still the open question if this mempool policy design philosophy proposed is sound enough in face of miner incentives and won't generate asymmetries in mining incomes. Not only now, but also in a future world where fee reward is most of miners income. To the best of my understanding, there isn't an established and practical model of miner incentives, at least among the Bitcoin Core developers. To underscore, from my perspective this is where the conceptual discussion is blocked, and where it would be opportune to spend time and energy on. Anyone is invited to contribute on that front.
Zooming out, I believe the lack of current fullrbf hashrate shouldn't be a disqualification that this mempool policy rule is not miner incentive compatible. In the realm of science, the value of a model is its performance to predict events, even if with a macro-system like Bitcoin mining it might take years for the empirical confirmation to happen (namely the exhaustion of mining reward). As we're seeing in physics, some lessons of Einstein's general relativity expressed in the 1900 were only confirmed by observation of solar eclipse in 1919.
In the meantime, as `mempoolfullrbf` is altering the security expectations of the 0conf operators and on the other side the Lightning/coinjoins folks have expressed low sensibility to the DoS vector [5], following a "first, do not harm" philosophy, I think as an ecosystem we're better off to remove the "risk-induction" `mempoolfullrbf` feature. Renewing here my position previously expressed in #26438 [6] and #26525 [7].
Qualifying the existence of a harm in the eyes of the community, I think this is valuable to have more merchants/services operators producing effective usage data, from the past years, as Bitrefill has done as an example [8]. Minding the lack of a verifiable process to attest the authenticity of such merchant claims raises a methodological issue in the discussion (and we could so in the future with cool ZKPs based on on-chain data!)
Of course, I think we shouldn't lose sight of the existence of a `mempoolfullrbf` patch, now widely disseminated across the ecosystem could lead to a situation where only a minority of node operators using it would damage the safety of the 0confs use-case. There is not that much the Bitcoin Core project could do in that regard. While I think the project aims to maximize the safety of the peer-to-peer network as a design principle, including when we might have to restrain user choice, policy rules are "soft" rules and the autonomy to modify them is only a function of one's technical ability.
On the qualification of the Bitcoin Core as a political process, I think this is an ignorance of the practice of day-to-day Core's process, where the best code and reasonings are winning based on scientific and engineering standards, even if we've always had a margin of improvements. People are striving their best to ensure we follow an idea meritocracy according to best open-source practice, and I think the project (and Bitcoin itself in its 10+ years of history) wouldn't have survived so far if it has been otherwise.
Finally, I can understand we have no economical data yet for the multi-party funded and p2p coinjoins use-cases, as the specification enabling them is still WIP and have not been implemented by all LN softwares. I also fully understand the skepticism on how mempoolfullrbf would solve a DoS vector for LN multi-party funded transactions, even if I've done my best to describe the issue previously. I'm staying available to demonstrate the pinning against a mainnet LN dual-funding flow if that would convince you further, and then explain how the wide deployment of mempoolfullrbf would block the DoS. I agree with you that instant channel opening or splicing is very valuable, but there are a lot of additional solutions that operators could deploy to have more fine-grained risk-management.
All that said, I appreciate when anyone in the community raises the voice to check-and-balance the work of Bitcoin Core contributors, this is really needed for the health of the development process, as long as it's done in a respectful and patient way.
Sincerely,
Antoine
[0]
https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md[1]
https://github.com/bitcoin/bitcoin/pull/26438#issuecomment-1304370679[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html[3]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135.html[4]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html[5]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021183.html[6]
https://github.com/bitcoin/bitcoin/pull/26438#issuecomment-1305042950[7]
https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1319499006[8]
https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1332823282