Playing with full-rbf peers for fun and L2s security

Summary:

In a recent email exchange between Antoine Riard and alicexbt, the security of Lightning Network (LN) nodes and the impact of different mempool policies on LN usage were discussed. The conversation also touched on p2p coinjoin transactions and how they can be affected by mempool DoS vectors. An example was given where Alice, Bob, and Caroll wanted to coinjoin their inputs to outputs, but Caroll broadcasted a double-spend of her own input C with a low fee and no opt-in RBF signaling, causing the multi-party transaction to be rejected by the network mempools. Two alternatives were offered to the coinjoin participants, but both resulted in economic loss. Antoine Riard proposed a partial full-RBF deployment to solve this security issue affecting multi-party funded transactions. He suggests reaching out to Lightning vendors to recommend running LN nodes with full-RBF enabled, and mining pool operators to advocate potential increase in their income. However, some have raised questions and disagreements about the approach and its impact. Users changing RBF policies manually is one concern, and if the majority of nodes use default opt-in policy, vulnerable projects could be affected.Riard believes it would be beneficial 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. However, if something relies on a policy that can be changed without breaking consensus rules, how is it secure in any case with or without full-RBF?For now, there are few standards and Bitcoin software relying on multi-party funded transactions. If you're a Bitcoin user or business and you don't like full-RBF, Riard invites you to express an opinion on how it might affect your software/operations. He also recommends trying Bitcoin Knots instead, which already has an option to disable all RBF policies if required, opt-in, and full RBF policy.Overall, the conversation emphasized the importance of economically-rational policies like full-rbf and solid documentation to improve the security of LN nodes and transactions. Selecting a full-node to underpin any serious Bitcoin infrastructure or secure a significant stack of coins should be submitted to a fully-fledged decision-making process considering various factors. Developers should provide basic RBF policy options rather than attempting to define what constitutes a good policy and removing the ability to disable something when necessary, but Riard's proposed 'full-rbf' PR aims to propose a "good" policy for a Lightning node without actually seeking to change the default.

Updated on: 2023-06-15T21:59:10.386605+00:00