Playing with full-rbf peers for fun and L2s security [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2022-08-24T01:56:14+00:00


Summary:

The conversation discussed the vulnerability of open, p2p coinjoin services to DoS attacks. It was noted that attackers can disrupt rounds by failing to complete them or launching double-spend attacks. Mitigating these types of attacks is crucial to prevent malicious coinjoin service providers from outlawing competition. Punishing attackers in the case of failed relay transactions during coinjoin rounds is also challenging. The implementation of full-rbf as a policy in Bitcoin Core was proposed as a potential solution to improve the security and reliability of multi-party funded transactions. However, there are ongoing discussions and disagreements regarding the approach and its impact.Another proposal shared on GitHub aims to enable trustless DLCs on Bitcoin using dual-funded channels with Lightning Network-style HTLCs. This would provide a more secure and scalable solution for off-chain contracts. Antoine Riard suggests that users should be able to manage their LN usage by using better ISPs or adopting different mempool policies. Documentation was highlighted as important in helping users understand and navigate the complexities of RBF policies and mempool DoS vectors. Community engagement and collaboration are emphasized as necessary to advance the state of policy options in Bitcoin Core.The Lightning dual-funded channel proposal aims to increase the efficiency and usability of the Lightning network by allowing users to easily create secure and decentralized channels. The fund allocation and transaction signing process is outlined in the proposal. It has been shared on the bitcoin-dev mailing list where developers discuss technical aspects of Bitcoin.There have been discussions about the lack of basic options in Bitcoin Core for enabling/disabling different RBF policies. The implementation of full-RBF in Bitcoin Core is questioned, and the author suggests providing basic RBF policy options instead of removing the ability to disable certain policies. Antoine Riard proposes fixing the security vulnerabilities in multi-party funded transactions by enabling full-RBF as a policy in Bitcoin Core. He has submitted a patch for review and invites node operators to test full-RBF. Concerns about the impact of full-RBF on vulnerable projects and the lack of consensus among nodes and miners are raised. Some suggest using alternative implementations like Bitcoin Knots, which already has an option to disable all RBF policies. However, proponents argue that full-RBF is a simple and incentive-compatible step towards more robust layer two systems. Peter Todd suggests a similar approach to full-RBF but notes that he hasn't worked on the Bitcoin Core codebase in years.In summary, ongoing discussions revolve around the implementation of full-RBF in Bitcoin Core and its impact on multi-party funded transactions. The Lightning dual-funded channel proposal aims to improve the efficiency and usability of the Lightning network. Developers are encouraged to provide basic RBF policy options, and alternative implementations like Bitcoin Knots already offer these options. Node operators and mining operators can experiment with full-RBF to test its benefits and drawbacks.


Updated on: 2023-08-02T06:48:58.631630+00:00