On Wed, Nov 02, 2022 at 10:19:00AM -0400, Greg Sanders wrote: > 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
...and the attacker also pays out the nose if they're exploiting 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). There's no hard technical reason for rule #5 to even exist. It's simply a conservative DoS limit to avoid having to do "too much" computation when processing a replacement in some replacement implementations. We shouldn't assume it will always exist. And like rule #3 pinning, exploiting it costs money. -- https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
