Sorry, I forgot one point which is pertinent to this conversation. *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(101kvb), or give 24 descendants, which means you quickly pay out the nose in rule#3 or are excluded from RBFing it if you have 4+ greifers in your coinjoin violating rule#5. If we instead narrowed this policy to marking a transaction output as opt-in to V3, it gets a bit more interesting. *Unfortunately, double-spending counterparties can still cause rule#3 pain, one 100kvb package of junk per peer,* but rule#5 violations is at least contained to coinjoins with ~50 peers(assuming two transactions booted per input double-spent, which would be the V3 max bumped per input). It's still worth exploring, but very speculatively. Greg On Wed, Nov 2, 2022 at 10:04 AM Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Nov 01, 2022 at 10:21:59PM -0400, Antoine Riard via bitcoin-dev > wrote: > > Hi list, > > > > Reading Suhas's post on mempool policy consistency rules, and the > grounded > > suggestion that as protocol developers we should work on special policy > > rules to support each reasonable use case on the network rather to > arbiter > > between class of use-cases in the design of an > > unified set of rules, reminded me there is another solution to solve > > multi-party funding pinning rather than wide deployment of fullrbf. This > > was communicated to me a while back, and it was originally dismissed > > because of the privacy trade-offs (and potential slight fees overhead > > cost). However, if widely adopted, they might sound acceptable to > > contracting protocol developers and operators. > > Strong NACK. > > Zeroconf is, at best, a very marginal usecase. The only services that have > spoken up in support of it are Bitrefill and Muun, and the latter says > they're > working to get rid of their vulnerability to it. People attempting to make > it > secure have repeatedly done sybil attacks against the network in attempts > to > measure transaction propagation. And of course, if transaction fees and > full > mempools are in our near future - as is widely expected - mempool > consistency > will even further diminish making zeroconf even harder to achieve. > > Incurring a bunch of engineering costs and harming privacy for the sake of > continuing this nonsense is ridiculous. > > If anything, we should be moving to full-RBF so we can undo the privacy > cost > that is opt-in-RBF: right now 30% of transactions are having to harm their > privacy by signalling support for it. Full-RBF will allow that wallet > distinguisher to be eliminated. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
