public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: alicexbt <alicexbt@protonmail•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: Fri, 08 Jul 2022 19:44:24 +0000	[thread overview]
Message-ID: <IAIys3gW4J8HsVfdulv9lt6x2cHaWbgZ_pUg6Mzu-ZFLr3Ys-Uz5Ivg9IDAz4FvwFPFnTaq7ELMr-F_DPHiiYElP7Llrvx915Sl5-iV6Q0A=@protonmail.com> (raw)
In-Reply-To: <YshE2QKBEVnbf+Bg@petertodd.org>

Hi Peter,

> 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.


There are 2 things:

1) Based on my understanding, round will not be aborted if a threshold is met for inputs and will continue irrespective of attacker trying different things in the initial phases of round. I need to confirm this by testing although not feeling well today so it can take a few days.

2) Points mentioned by Greg Sanders are reasonable: There can be a different 'mempool view' for coordinator, users and attacker. Attacker could use minimum fee rate required for relay and this works differently when there is enough demand for blockspace.

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.

The vulnerability reported is different from the things being discussed and hopefully I will do a public disclosure this month. I observed some interesting things which I wanted to discuss. Full RBF pull request is already merged in bitcoin core and available in bitcoin knots if some users want to experiment.


/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Friday, July 8th, 2022 at 2:53 PM, Peter Todd <pete@petertodd•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


  parent reply	other threads:[~2022-07-08 19:44 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 [this message]
2022-07-09 15:06                 ` Antoine Riard
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='IAIys3gW4J8HsVfdulv9lt6x2cHaWbgZ_pUg6Mzu-ZFLr3Ys-Uz5Ivg9IDAz4FvwFPFnTaq7ELMr-F_DPHiiYElP7Llrvx915Sl5-iV6Q0A=@protonmail.com' \
    --to=alicexbt@protonmail$(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