From: Antoine Riard <antoine.riard@gmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
Date: Sat, 9 Jul 2022 11:06:43 -0400 [thread overview]
Message-ID: <CALZpt+H6H3M49O=-NduYd99VwSywGPoJPavKs8EDzdBi9pT5qg@mail.gmail.com> (raw)
In-Reply-To: <YshE2QKBEVnbf+Bg@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 4680 bytes --]
> 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.
I think I agree that effectively a DoS-by-abstention is lower cost than a
DoS-by-RBF-otpout, as in the second case the UTXO double-spent must be
still acquired. However, I wonder if the second DoS case isn't more
economically efficient for the attacker as you can re-use the same UTXO (or
the lineage of it) many times as the coinjoin coordinator have a limited
visibility (in the very best case) of the network mempools to blame
confidently.
Acquiring thousands of UTXO, whatever the origin, isn't free. Electricity
burns if they have been mined, fiat if they have been acquired through
exchange, time and energy if they have been earned as income.
> 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.
I believe it's hard to make any open, p2p coinjoin services robust against
a deep-pocketed attacker practicing that type of DoS attacks. In theory, an
attacker could maintain the DoS for long enough to ruin the reputation of
the service until it's out of the market. It would be interesting to know
if you can design a DoS mitigation (e.g against DoS-by-abstention) offering
the advantage to the targeted service after one-round or a fixed number of
rounds.
> 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.
Yes, that's of the annoying concern with DoS-by-RBF-optout against
DoS-by-abstention, while the latter can be mitigated without assuming a
on-chain cost for the participant, the former might be crafted such that
on-chain fees must be spent to sanitize the situation, worst in an
asymmetric way bounded by the max size of the coinjoin, I think.
> Double spend attack requires only one laptop and a few UTXOs. Even if
spent in some cases, would pay a few sats per transaction which won't be an
issue for governments or competitors that normally perform such attacks.
That's an interesting question. Interactive transaction construction
protocol being formalized by the BOLT process implied (hopefully) that
sooner or later multi-party coinjoin capabilities should be well supported
across the ecosystem. From that, we might seen a large-scale p2p market of
coinjoin (in the same way we have a HTLC routing market with LN), where a
participant can enter into them, without the high cost of installing
another wallet. I believe how do we mitigate all those classes of DoS to
avoid malicious coinjoin service providers to outlaw competitions that stay
open (reminder Minecraft and the Mirai Botnet story).
Antoine
Le ven. 8 juil. 2022 à 10:53, Peter Todd <pete@petertodd•org> a écrit :
> 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
>
[-- Attachment #2: Type: text/html, Size: 5402 bytes --]
next prev parent reply other threads:[~2022-07-09 15:06 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-14 0:25 Antoine Riard
2022-06-15 2:27 ` Peter Todd
2022-06-15 2:53 ` Luke Dashjr
2022-06-15 3:18 ` Peter Todd
2022-06-16 0:16 ` alicexbt
2022-06-16 1:02 ` Greg Sanders
2022-06-16 1:45 ` alicexbt
2022-06-16 5:43 ` linuxfoundation.cndm1
2022-06-16 12:47 ` alicexbt
2022-06-16 13:24 ` Greg Sanders
[not found] ` <gmDNbfrrvaZL4akV2DFwCuKrls9SScQjqxeRoEorEiYlv24dPt1j583iOtcB2lFrxZc59N3kp7T9KIM4ycl4QOmGBfDOUmO-BVHsttvtvDc=@protonmail.com>
2022-06-17 1:34 ` Antoine Riard
2022-06-17 4:54 ` alicexbt
2022-06-19 10:42 ` Peter Todd
2022-06-21 23:43 ` Antoine Riard
2022-06-26 16:40 ` alicexbt
2022-06-27 0:43 ` Peter Todd
2022-06-27 12:03 ` Greg Sanders
2022-06-27 13:46 ` Peter Todd
2022-07-05 20:46 ` alicexbt
2022-07-08 14:53 ` Peter Todd
2022-07-08 15:09 ` Greg Sanders
2022-07-08 19:44 ` alicexbt
2022-07-09 15:06 ` Antoine Riard [this message]
2022-06-20 23:49 ` Peter Todd
2022-06-21 23:45 ` Antoine Riard
2022-06-23 19:13 ` Peter Todd
2022-08-24 1:56 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALZpt+H6H3M49O=-NduYd99VwSywGPoJPavKs8EDzdBi9pT5qg@mail.gmail.com' \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox