Author: John Carvalho 2022-10-27 09:56:45
Published on: 2022-10-27T09:56:45+00:00
In an email to the Bitcoin Protocol Discussion group, John Carvalho expressed concern about the current RBF movement and its push into commercial Bitcoin use cases. He believes that Core developers need to be more conservative with change proposals and focus on efficiencies, bugs, cleanup, and reducing overhead. Carvalho argues that superficial features should be decided at the app level instead of in the protocol or node.Carvalho believes that the behavior of RBF implementation will result in more mempool types, more implementations, and a more difficult to modify protocol. All feature changes, default settings that make decisions for users, and even all scaling changes are speculative risks with unpredictable outcomes. He urges the culture of Core to respect these dynamics and become much more conservative with proposing change. The market should not be obligated to prove it can defeat RBF in a stronger form if it really wants to prove other use cases.The controversy around full RBF (replace-by-fee) option in Bitcoin has raised questions about the philosophy behind the development of the cryptocurrency. There seems to be a shift towards giving people different mempool policies from which to choose. This change leads to concerns about how this will impact transactions' propagation, privacy, centralization pressure on mining, and efficiency.To ensure transactions get propagated well, one approach is to set a service bit and preferentially peer with other nodes that advertise that service bit; another approach is to have a separate relay network. However, these approaches increase the centralization pressure on mining and hurt privacy. While some argue that users should have the freedom to choose their own relay/mempool policies, this change raises questions about what it means for people to choose their own relay/mempool policies and for users who expect to have different mempool policies from most of their potential peers.The possibility of recovering the good parts of core in Bitcoin and deciding on what's good for the network is being discussed. One way to do this could be for people outside of core to recommend a mempool configuration, with core providing an option to make it easy to implement. If people are following policy developed outside of core, core might well disagree with them and decide to remove features they think are unnecessary. This could result in people 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.Ultimately, the hope is to find a solution that keeps most stakeholders happy and allows for efficient design of apps and transactions. Carvalho suggests that we realize the Bitcoin we already have, which includes largely unexplored canvas of taproot, lightning, UX, etc. He argues that it is okay to leave things as they are, and it is okay if RBF remains a niche feature.
Updated on: 2023-06-16T02:28:33.747993+00:00