Solving Multi-Party Flows Pinning with Opt-in Full-RBF Spent-nVersion Signaling



Summary:

In a bitcoin-dev mailing list, Antoine Riard suggested a solution to solve multi-party funding pinning by adopting zeroconf. However, Peter Todd strongly opposed the idea and argued that zeroconf is a very marginal use case with potential privacy trade-offs and engineering costs. He further stated that full-RBF should be adopted instead to eliminate the harm to privacy caused by opt-in-RBF. On the other hand, in a follow-up email, Greg Maxwell mentioned that even with fullrbf-everywhere and V3, pinning via rule#3 and rule#5 are still an issue in coinjoin scenarios. Each coinjoin adversary can double-spend their coin to either full package weight or give 24 descendants, which quickly leads to paying more or getting excluded from RBFing it if there are 4+ greifers in the coinjoin violating rule#5. Although narrowing this policy to marking a transaction output as opt-in to V3 is interesting, double-spending counterparties can still cause rule#3 pain, one 100kvb package of junk per peer; but rule#5 violations are at least contained to coinjoins with ~50 peers. Nevertheless, it is worth exploring, but very speculatively.


Updated on: 2023-06-16T02:42:44.006579+00:00