On mempool policy consistency

Summary:

The bitcoin-dev mailing list has been discussing the proposal for Full-RBF in Bitcoin Core 24.0, which would replace the opt-in RBF. However, some developers have raised concerns about the potential impact of this change on fast block propagation and the uniformity of mempool policies across different nodes.The current options for mempool policies are limited to a few parameters that are rarely customized, but the proposed transition to Full-RBF may encourage more significant differences between node policies. Some developers argue that a single policy that works well for everyone and the ecosystem as a whole is preferable, while others support providing users with more flexibility through different mempool policies.The removal of previously included RBF-related options, such as "permitrbf" and "mempoolreplacement," also raises questions about the precedent for including and removing options that protocol developers don't find useful.The debate surrounding full replace-by-fee (RBF) implementation in Bitcoin Core continues with developers discussing the potential risks and benefits of such a change. Some argue that offering policy flexibility to interested users only and favouring a gradual deployment of full RBF is better than erecting artificial barriers to prevent users from doing what they want.Efficiencies could be gained from similar mempool policies, including more reliable compact block reconstruction and efficient set reconstruction with erlay. However, gradual deployments of mempool policies may not be the best approach as it makes them hard to use during the gradual phase, and getting around that comes with worrying compromises on privacy and centralisation.One way to recover the good parts of core deciding on what's good for the network might be for people outside of core to recommend a mempool configuration; then core can just have an option to make that easy, similar to "-std=c++17" for a C++ compiler, and much the same as knots' "-corepolicy" option. This could work well if the majority of the network ends up following those recommendations because it's easy, it works, and it's recommended by all the apps they want to use.The Bitcoin Core team provides options for users and developers, without worrying about being seen as gatekeepers. However, the downside is that users may not make much use of all the available choices. Additionally, core has historically been happy to remove options that don't seem useful anymore. If people are following policy developed outside of core, core might well disagree with them and decide to remove some feature that others think should continue to be normal. As a result, the people maintaining the policy will end up maintaining an entire fork of bitcoin core, and all we've done is transition to people running software from a different repo, and a different set of maintainers.

Updated on: 2023-06-16T02:22:12.939456+00:00