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
>