Playing with full-rbf peers for fun and L2s security



Summary:

The email discusses the recent concerns of security vulnerabilities in multi-party funded transactions. The lack of existent full-rbf transaction-relay topology on today’s p2p network creates a naive DoS vector against the funding flow of any such construction. Antoine proposes that running full-rbf and enabling propagation of honest multi-party transactions to the interested miners would benefit the flourishing of multi-party funded transactions. Antoine has submitted a patch against Bitcoin Core enabling it to turn on full-rbf as a policy, still under review. If you're a node operator curious to play with full-rbf, feel free to connect to his public node or spawn up a toy, public node yourself. If you're a mining operator looking to increase your income, you might be interested to experiment with full-rbf as a policy. However, miners can only increase their income if users replace transactions. There is also a speculation about making full RBF default in an year which isn't relevant to discuss at this point without trying different RBF policies. If you're a Bitcoin user or business and you don't like full-rbf, please express an opinion on how it might affect your software/operations. Antoine is always interested to learn more about mempool and transaction-relay interactions with upper-layers and applications and to listen to feedback in those areas. He suggests Bitcoin Knots instead which already has an option to disable all RBF policies if required, opt-in and full RBF policy. 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.


Updated on: 2023-06-15T21:54:00.947834+00:00