Playing with full-rbf peers for fun and L2s security

Summary:

In a recent email exchange, Antoine Riard and alicexbt discussed various aspects of Lightning Network (LN) security. They talked about how components beyond Bitcoin software play a role in LN security and how relying on a Bitcoin node policy and relying on an ISP internet traffic routing policy are logically equivalent. They also discussed how users can manage their LN usage by using better ISPs or adopting different mempool policies. They also talked about the importance of running economically rational policies like full-rbf on p2p network nodes for the security of LN usage. They also discussed the potential impact of different RBF policies on LN users. The conversation also delved into how allowing users to create different mempool policies is great and how documentation helps users. Finally, they talked about mempool DoS vectors and how they can affect certain use-cases like p2p coinjoins.The discussion revolves around the implementation of full-RBF (Replace-By-Fee) in Bitcoin Core, a policy that allows a multi-party transaction to replace an opt-out. The security implications of this change are debated, with one participant arguing that it would solve a vulnerability affecting various use-cases such as dual-funded channels, on-chain DLCs, p2p coinjoins, batched submarine swaps, etc. The discussion also touches upon other issues like selecting a full-node for secure Bitcoin infrastructure, understanding the interactions with network mempools, and the need for more RBF policy options in Bitcoin Core.A recent discussion among Lightning Network (LN) developers has brought back concerns about the security of multi-party funded transactions due to a lack of existent full-replace-by-fee (full-rbf) transaction-relay topology on today's peer-to-peer network. This has raised a low-fruit, naive denial-of-service vector against the funding flow of any such construction. While it does not consist in a direct loss of funds, if exploited well, it is annoying enough to inflict significant time-value loss or fee-bumping waste to the future providers or distributed swarm of users doing multi-party funded transactions.To address this issue, Antoine Riard has submitted a small patch against Bitcoin Core that enables it to turn on full-rbf as a policy, still under review. The default setting stays false, keeping opt-in replace-by-fee (opt-in RBF) as a default replacement policy. The author believes it would be beneficial to the flourishing of multi-party funded transactions to fix the DOS vector by seeing a subset of the network running full-rbf and enabling propagation of honest multi-party transactions to the interested miners, replacing potential non-signaling double-spend from a malicious counterparty.If you're a node operator curious to play with full-rbf, feel free to connect to this node or spawn up a toy, public node yourself. There is a chat available if you would like information on the settings or looking for full-rbf friends (though that step could be automated in the future by setting up a dedicated network bit and reserving a few outbound slots for them). If you're a mining operator looking to increase your income, you might be interested to experiment with full-rbf as a policy. Indeed, in the future, the multi-party transactions issuers who need full-rbf to secure their funding flow should connect by default to full-rbf peers.However, users have raised concerns about the security of relying on a policy that can be changed without breaking consensus rules and how it can affect vulnerable projects if majority of nodes use default opt-in policy. In addition, miners can only increase their income if users replace transactions with opt-in RBF, and only 2-3% transactions are replaced with opt-in RBF. Developers should provide basic replace-by-fee policy options rather than attempting to define what constitutes a good policy and removing the ability to disable something when necessary.The author suggests trying Bitcoin Knots instead, which already has an option to disable all RBF policies if required, opt-in, and full RBF policy. This can also be done using GUI if not familiar with config option mempoolreplacement. The author believes the Bitcoin ecosystem has matured a lot since there were a lot of concerns about full-rbf in the past. Overall, the discussion highlights the need for a fully-fledged decision-making process while selecting a full-node and emphasizes the importance of community engagement in advancing the state of policy options in Bitcoin Core.

Updated on: 2023-06-15T21:57:56.308043+00:00