Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2022-06-26 📝 Original message:On Sun, Jun 26, 2022 at ...

📅 Original date posted:2022-06-26
📝 Original message:On Sun, Jun 26, 2022 at 04:40:24PM +0000, alicexbt via bitcoin-dev wrote:
> Hi Antoine,
>
> Thanks for sharing the DoS attack example with alternatives.
>
> > - Caroll broadcasts a double-spend of her own input C, the double-spend is attached with a low-fee (1sat/vb) and it does _not_ signal opt-in RBF
> > - Alice broadcasts the multi-party transaction, it is rejected by the network mempools because Alice double-spend is already present
>
> I think this affects almost all types of coinjoin transaction including coordinator based implementations. I tried a few things and have already reported details for an example DoS attack to one of the team but there is no response yet.
>
> It was fun playing with RBF, DoS and Coinjoin. Affected projects should share their opinion about full-rbf as it seems it might improve things.
>
> Example:
>
> In Wasabi an attacker can broadcast a transaction spending input used in coinjoin after sending signature in the round. This would result in a coinjoin tx which never gets relayed: https://nitter.net/1440000bytes/status/1540727534093905920

Note that Wasabi already has a DoS attack vector in that a participant can stop
participating after the first phase of the round, with the result that the
coinjoin fails. Wasabi mitigates that by punishing participating in future
rounds. Double-spends only create additional types of DoS attack that need to
be detected and punished as well - they don't create a fundamentally new
vulerability.

--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220626/fe2891b5/attachment.sig>;