Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-02 📝 Original message:On Wed, Nov 02, 2022 at ...
📅 Original date posted:2022-11-02
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221102/addb7935/attachment.sig>;
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221102/addb7935/attachment.sig>;