Author: Gloria Zhao 2022-10-27 12:36:47
Published on: 2022-10-27T12:36:47+00:00
The discussion on the implementation of full Replace-By-Fee (RBF) in Bitcoin Core has raised concerns about how the project should approach changes to mempool policies. The proposal suggests that full-RBF could be implemented as a one-time thing, but the main concern raised is whether someone else's transaction will invalidate others'. This controversy extends to RBF for zeroconf transactions which rely on there being no path from someone else's full-RBF node to a full-RBF miner. The email highlights the differences between node policies supported by different nodes running core and the limited number of options available.On the other hand, Knots supports and encourages different mempool policies with its own set of options. However, the GitHub discussion shows that there is a shift toward giving users more options to choose their own relay/mempool policies, rather than implementing one policy that works well for everyone. Gradual deployments of mempool policies are also seen as problematic because they can make it hard to use during the gradual phase, and compromises on privacy and centralisation may be necessary.To address these issues, the bitcoin-dev mailing list discusses the possibility of developing a single mempool/relay policy that satisfies the majority of network users. This potential policy would be developed by someone who listens to the concerns of various parties, such as zeroconf businesses, lightning and coinjoin devs, and miners. The hope is that 70-90% of the network will follow these recommendations because they are easy, effective, and recommended by the apps they use. This proposed policy would not put pressure on miners to centralize, and it would not compromise user privacy. Developers could design their apps confidently, and there would be no need to add new p2p layers. Additionally, this policy could provide a contact point for developers struggling to create new projects within existing relay policies. However, one potential downside of this approach is that users may not make full use of all the options available. Another issue is that core has historically removed options that were deemed obsolete, leaving some users to run forks. If people are following policy developed outside of core, then core may disagree with their decisions and remove certain features. In this case, the policy maintainers would end up maintaining an entire fork of bitcoin core. Despite these concerns, if core is willing to add new options while being reluctant to remove them, this would not be an issue. Core developers would only provide options and would not be viewed as gatekeepers. The goal is to eliminate ways that users might inadvertently shoot themselves in the foot.
Updated on: 2023-06-16T02:26:49.224259+00:00