Date: Tue, 05 Jul 2022 20:46:51 +0000
To: Peter Todd <pete@petertodd.org>
From: alicexbt <alicexbt@protonmail.com>
Reply-To: alicexbt <alicexbt@protonmail.com>
Message-ID: <0ikzVrbv3tA2fyv4iW7b_gPJ-qkrJS3x9HzouSqLabK3yHthgigPt9YZhGlr4_nCutAlRREfFSw1JW0k5KhBgSj1aBI2MSDTLqYHGYbqNrg=@protonmail.com>
In-Reply-To: <Yrj9N7k8osWsxhY4@petertodd.org>
References: <CALZpt+GOh-7weEypT9JrzcwthZJqHOfj7sf9FMuqi5_FZv0g7w@mail.gmail.com>
 <gmDNbfrrvaZL4akV2DFwCuKrls9SScQjqxeRoEorEiYlv24dPt1j583iOtcB2lFrxZc59N3kp7T9KIM4ycl4QOmGBfDOUmO-BVHsttvtvDc=@protonmail.com>
 <CALZpt+FJ-R9yCoMLP=Vcxk1U7n=-LKHUGctFZj0K-vTMsz==ew@mail.gmail.com>
 <RJEFmrnjbzKQCBr4L7ebwBLzg7QHGXlaE19zj6jfkxL6xjfodgbfssZBQSYxm783Y4X5awuhL9Gj8IaBc4npE2oh3d1xoudKTrSsJ-dk0VQ=@protonmail.com>
 <CALZpt+HXB=xh3qtxJFM7yUzRu1uj-pPtLQmT=5QV0dNfVuTpfQ@mail.gmail.com>
 <Pb8H4PbeS-RaNOKfekOPdY8gQo4_Syd3HoTK26AO872f7tCKyGnty56KtcvmvrXFOJdC7nQgNHoQ37M4MNXQ6vqQ9du6BFbvGLbY3BdYVpY=@protonmail.com>
 <Yrj9N7k8osWsxhY4@petertodd.org>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s
	security
Precedence: list

Hi Peter,

> Note that Wasabi already has a DoS attack vector in that a participant ca=
n stop
> participating after the first phase of the round, with the result that th=
e
> coinjoin fails. Wasabi mitigates that by punishing participating in futur=
e
> rounds. Double-spends only create additional types of DoS attack that nee=
d 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 c=
ase 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 chec=
ked 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?

/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Monday, June 27th, 2022 at 12:43 AM, Peter Todd <pete@petertodd.org> wro=
te:


> 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-spe=
nd 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 r=
eported details for an example DoS attack to one of the team but there is n=
o 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 i=
n coinjoin after sending signature in the round. This would result in a coi=
njoin tx which never gets relayed: https://nitter.net/1440000bytes/status/1=
540727534093905920
>
>
> Note that Wasabi already has a DoS attack vector in that a participant ca=
n stop
> participating after the first phase of the round, with the result that th=
e
> coinjoin fails. Wasabi mitigates that by punishing participating in futur=
e
> rounds. Double-spends only create additional types of DoS attack that nee=
d to
> be detected and punished as well - they don't create a fundamentally new
> vulerability.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org