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
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
