The attacker isn't guaranteed to spend *any* funds to disrupt the protocol indefinitely, that's the issue here. In this scenario, her input double spend is at an impractical feerate, and is never included in a block, sitting at the bottom of the mempool.
The other users' only practical choice is to double-spend their own input to get their money back(at competitive rates much higher than the attacker), or wait and hope you win a propagation race somewhere. On Fri, Jul 8, 2022 at 10:53 AM Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Jul 05, 2022 at 08:46:51PM +0000, alicexbt wrote: > > Hi Peter, > > > > > 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. > > > > I agree some DoS vectors are already mitigated however punishment in > this case will be difficult because the transaction is broadcasted after > signing and before coinjoin tx broadcast. > > > > Inputs are already checked multiple times for double spend during > coinjoin round: https://github.com/zkSNACKs/WalletWasabi/pull/6460 > > > > If all the inputs in the coinjoin transaction that failed to relay are > checked and one or more are found to be spent later, what will be punished > and how does this affect the attacker with thousands of UTXOs or normal > users? > > Point is, the attacker is thousands of UTXOs can also DoS rounds by simply > failing to complete the round. In fact, the double-spend DoS attack > requires > more resources, because for a double-spend to be succesful, BTC has to be > spent > on fees. > > It's just a fact of life that a motivated attacker can DoS attack Wasabi by > spending money. That's a design choice that's serving them well so far. > > -- > 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
