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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
|
Return-Path: <antoine.riard@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id BE5EFC0032;
Tue, 7 Nov 2023 15:44:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 9A093821D7;
Tue, 7 Nov 2023 15:44:35 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 9A093821D7
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20230601 header.b=HsGDeboZ
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 1BlpOdAOaHXk; Tue, 7 Nov 2023 15:44:34 +0000 (UTC)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com
[IPv6:2607:f8b0:4864:20::d2a])
by smtp1.osuosl.org (Postfix) with ESMTPS id 6CD028219C;
Tue, 7 Nov 2023 15:44:34 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6CD028219C
Received: by mail-io1-xd2a.google.com with SMTP id
ca18e2360f4ac-7a66b5f7ea7so218628339f.2;
Tue, 07 Nov 2023 07:44:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1699371873; x=1699976673;
darn=lists.linuxfoundation.org;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=fSPySw9lRn+RbO3aI3tEfWReeLqSHs/2FDJq9rwMYjg=;
b=HsGDeboZbn2zlPlx97xvXB6IK7hlmL5+nNbzEJO8tS3vjMxK52SyZayTpd9sFSJlRU
+CK64fzzQFDaASaLcezshqoP+7vXROC/A1ikGz9Z+pkT1GSb/W0zLuanurU/3aG7Mftk
kL6qg/ON3nIUdVPURZqWSa1FH558Vhi17GqK4boe/xvYupFxwft0RPpZ1vfK3W/0XTZt
SCNlHYwgJiYs9PgW45pxo9OofwK1r1rLVDsYaCeUZImwyYTGRCjorICtKrIzURdNfD8T
uigDqvQ/ahGvsb7Sb9kicwG/SywZowHxyGaUwstmqqkcqiNeZHax1Np7mtXAviSmCtIf
OIcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1699371873; x=1699976673;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=fSPySw9lRn+RbO3aI3tEfWReeLqSHs/2FDJq9rwMYjg=;
b=tI8/muhl7/QoKQzq0uqPsQwVtcqvJ1FqwInqqcx3BSpSTdnFEOIPWEb98UsrijDW7x
ezoZgrT7HinTcPxpWkGuk3vEmwJ6VlRKhNYg0LBA4nCQ/EW8kcSOl4oni2ONXoESEINw
/US8srvau6M/zP2Lkg5c4JexHrbJCTAn5lBoud0pglDqeavpXDNCbzr1htB3npLAj5ta
jQ9LMQXE3wwvPED0zp7tCQlmWTfQjLktUhFz+N5zyknhAf+afpVunu72tbVXeo39LxGQ
yNYuFgjPltlh2VlyjCfCfoCzFr7QpTwHUnrlKcmay3/CoiATexknrE2snr19OQEOCO74
UEmg==
X-Gm-Message-State: AOJu0YxianvFhAmOMGJdtpz2vmqK7YPZ5maRmeW+mRRtOtw2Z+q+1q91
Qi+k73Wz1LKXkaeTvChq61ZzKmD3FVMlF2T6VWk=
X-Google-Smtp-Source: AGHT+IEPTWQ8VyfnHUO1svwo4DiXUosEaR6SG8X5psB/2K6paKVP4q3g4Ox7alh3NNVaFEdp5D8Q+Esn6Vb9app4T8M=
X-Received: by 2002:a05:6602:15d0:b0:7a6:b272:fd92 with SMTP id
f16-20020a05660215d000b007a6b272fd92mr42874157iow.18.1699371873382; Tue, 07
Nov 2023 07:44:33 -0800 (PST)
MIME-Version: 1.0
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
<ZTMWrJ6DjxtslJBn@petertodd.org>
<CALZpt+GQ9g-uwAGYogdaJcinVHRxs4=67hML78KbramJg=davA@mail.gmail.com>
<ZUNBHsw2BldPLvPc@petertodd.org>
<CALZpt+GBcqquPtf0YB07Rcy2OS0kUhv86s6g=69VrfSE72cYJQ@mail.gmail.com>
<ZUXyICh45JP6OnDu@petertodd.org>
<CALZpt+GXGBbo0JjOyMr3B-3dVY2Q_DuzF6Sn3xE5W24x77PRYg@mail.gmail.com>
<iBopsZOx5TRDjjfxSLo9GLa00c7Jk0uMSae6_EPsPjnd10Aa87-lxVIZnL37GwEM3ppemBAxCwkv7r4w5AfDjLkKo0OhIpdB0jK0_OTRqf4=@protonmail.com>
In-Reply-To: <iBopsZOx5TRDjjfxSLo9GLa00c7Jk0uMSae6_EPsPjnd10Aa87-lxVIZnL37GwEM3ppemBAxCwkv7r4w5AfDjLkKo0OhIpdB0jK0_OTRqf4=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 7 Nov 2023 15:44:21 +0000
Message-ID: <CALZpt+EZqfj=G=E37hA+k9pKYfvE0jkc3UU+H8sJVm=H3CO-JA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000dab734060991d8c8"
X-Mailman-Approved-At: Tue, 07 Nov 2023 15:52:05 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
"lightning-dev\\\\\\\\@lists.linuxfoundation.org"
<lightning-dev@lists.linuxfoundation.org>, security@ariard.me
Subject: Re: [bitcoin-dev] [Lightning-dev] OP_Expire and Coinbase-Like
Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
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, 07 Nov 2023 15:44:35 -0000
--000000000000dab734060991d8c8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Zeeman,
> Neither can Bob replace-recycle out the commitment transaction itself,
because the commitment transaction is a single-input transaction, whose
sole input requires a signature from
> Bob and a signature from Carol --- obviously Carol will not cooperate on
an attack on herself.
The replacement cycling happens on the commitment transaction spend itself,
not the second stage, which is effectively locked until block 100.
If the commitment transaction is pre-signed with 0 sat / vb and all the
feerate / absolute fee is provided by a CPFP on one of the anchor outputs,
Bob can replace the CPFP itself. After replacement of its child, the
commitment transaction has a package feerate of 0 sat / vb and it will be
trimmed out of the mempool.
This is actually the scenario tested here on the nversion =3D 3 new mempool
policy branch (non-deployed yet):
https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2
As of today commitment transactions might not propagate if dynamic mempool
min fee is above pre-signed commitment transaction, which is itself unsafe.
I think this behavior can currently be opportunistically exploited by
attackers.
In a post-package relay world, I think this is possible. And that
replacement cycling attacks are breaking future dynamic fee-bumping of
pre-signed transactions concerns me a lot.
Best,
Antoine
Le mar. 7 nov. 2023 =C3=A0 11:12, ZmnSCPxj <ZmnSCPxj@protonmail.com> a =C3=
=A9crit :
> Good morning Antoine,
>
>
> > Once the HTLC is committed on the Bob-Caroll link, Caroll releases the
> preimage off-chain to Bob with an `update_fulfill_htlc` message, though B=
ob
> does _not_ send back his signature for the updated channel state.
> >
> > Some blocks before 100, Caroll goes on-chain to claim the inbound HTLC
> output with the preimage. Her commitment transaction propagation in netwo=
rk
> mempools is systematically "replaced cycled out" by Bob.
>
> I think this is impossible?
>
> In this scenario, there is an HTLC offered by Bob to Carol.
>
> Prior to block 100, only Carol can actually create an HTLC-success
> transaction.
> Bob cannot propagate an HTLC-timeout transaction because the HTLC timeloc=
k
> says "wait till block 100".
>
> Neither can Bob replace-recycle out the commitment transaction itself,
> because the commitment transaction is a single-input transaction, whose
> sole input requires a signature from Bob and a signature from Carol ---
> obviously Carol will not cooperate on an attack on herself.
>
> So as long as Carol is able to get the HTLC-success transaction confirmed
> before block 100, Bob cannot attack.
> Of course, once block 100 is reached, `OP_EXPIRE` will then mean that
> Carol cannot claim the fund anymore.
>
> Regards,
> ZmnSCPxj
>
--000000000000dab734060991d8c8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Zeeman,<div><br></div><div>> Neither can Bob replace=
-recycle out the commitment transaction itself, because the commitment tran=
saction is a single-input transaction, whose sole input requires a signatur=
e from</div><div>> Bob and a signature from Carol --- obviously Carol wi=
ll not cooperate on an attack on herself.<br><div><br></div><div><div>The r=
eplacement cycling happens on the commitment transaction spend itself, not =
the second stage, which is effectively locked until block 100.</div></div><=
div><br></div><div>If the commitment transaction is pre-signed with 0 sat /=
vb and all the feerate / absolute fee is provided=C2=A0by a CPFP on one of=
the anchor outputs, Bob can replace the CPFP itself. After replacement of =
its child, the commitment transaction has a package feerate of 0 sat / vb a=
nd it will be trimmed out of the mempool.</div><div><br></div><div>This is =
actually the scenario tested here on the nversion =3D 3 new mempool policy =
branch =C2=A0(non-deployed yet):</div><div><a href=3D"https://github.com/ar=
iard/bitcoin/commits/2023-10-test-mempool-2">https://github.com/ariard/bitc=
oin/commits/2023-10-test-mempool-2</a><br></div><div><br></div><div>As of t=
oday commitment transactions might not propagate if dynamic mempool min fee=
is above pre-signed commitment transaction, which is itself unsafe. I thin=
k this behavior can currently be opportunistically exploited by attackers.=
=C2=A0</div><div><br></div></div><div><div><div>In a post-package relay wor=
ld, I think this is possible. And that replacement cycling attacks are brea=
king future dynamic fee-bumping of pre-signed transactions concerns me a lo=
t.</div></div><div><br></div><div>Best,</div><div>Antoine</div></div></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=
=A0mar. 7 nov. 2023 =C3=A0=C2=A011:12, ZmnSCPxj <<a href=3D"mailto:ZmnSC=
Pxj@protonmail.com">ZmnSCPxj@protonmail.com</a>> a =C3=A9crit=C2=A0:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,=
204);padding-left:1ex">Good morning Antoine,<br>
<br>
<br>
> Once the HTLC is committed on the Bob-Caroll link, Caroll releases the=
preimage off-chain to Bob with an `update_fulfill_htlc` message, though Bo=
b does _not_ send back his signature for the updated channel state.<br>
> <br>
> Some blocks before 100, Caroll goes on-chain to claim the inbound HTLC=
output with the preimage. Her commitment transaction propagation in networ=
k mempools is systematically "replaced cycled out" by Bob.<br>
<br>
I think this is impossible?<br>
<br>
In this scenario, there is an HTLC offered by Bob to Carol.<br>
<br>
Prior to block 100, only Carol can actually create an HTLC-success transact=
ion.<br>
Bob cannot propagate an HTLC-timeout transaction because the HTLC timelock =
says "wait till block 100".<br>
<br>
Neither can Bob replace-recycle out the commitment transaction itself, beca=
use the commitment transaction is a single-input transaction, whose sole in=
put requires a signature from Bob and a signature from Carol --- obviously =
Carol will not cooperate on an attack on herself.<br>
<br>
So as long as Carol is able to get the HTLC-success transaction confirmed b=
efore block 100, Bob cannot attack.<br>
Of course, once block 100 is reached, `OP_EXPIRE` will then mean that Carol=
cannot claim the fund anymore.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>
--000000000000dab734060991d8c8--
|