1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
Return-Path: <alicexbt@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id BCE9DC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Jul 2022 20:47:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 85E04408BE
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Jul 2022 20:47:05 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 85E04408BE
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=VykizigC
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id uem1__5b2qor
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Jul 2022 20:47:03 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4BDE3408A0
Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19])
by smtp4.osuosl.org (Postfix) with ESMTPS id 4BDE3408A0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Jul 2022 20:47:03 +0000 (UTC)
Date: Tue, 05 Jul 2022 20:46:51 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1657054020; x=1657313220;
bh=9+L3xhxUDzwtXERMXpnqHJm7JYZ+xN02vzPi5ocYMZk=;
h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To:
Feedback-ID:Message-ID;
b=VykizigCz43AwPDmYVIPj9dpyp8Edc/723yRi908q/s8ZCaIO4zCGb0Yhtc+jr7+A
7Rnqji4BzYObkyU+mPlV2AySUtBKAxtAQV987H5aFAJpWhdn1Jzt356ogNmBxwAuj8
gUNf1pejyd/gTOKbdJCH7Hj7atQOConNzReacFUOWxEPcjQH/Pgs3XYSiMGdrdtoPl
06G/dMGQzOM1ef10wDzC6n4tZnF9lB84yuOTVRl0bpkjZlY7T+wfkwq4IXlLQ/JEtc
A+SOAf3aap3opKu3kfWwAv+PfaGopZuMdoF+T4jz5LTk9zBmb2qKKTGL7I7AD9yq4g
xPjuwerOKwImQ==
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
X-Mailman-Approved-At: Wed, 06 Jul 2022 07:41:23 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s
security
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jul 2022 20:47:05 -0000
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
|
