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
|
Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 02A1FC0032;
Fri, 3 Nov 2023 05:25:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id C6DB14357E;
Fri, 3 Nov 2023 05:25:40 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org C6DB14357E
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20230601 header.b=nShnSXD9
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 smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id C1W79Kiu0RxT; Fri, 3 Nov 2023 05:25:36 +0000 (UTC)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com
[IPv6:2607:f8b0:4864:20::d29])
by smtp2.osuosl.org (Postfix) with ESMTPS id 739DF40017;
Fri, 3 Nov 2023 05:25:36 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 739DF40017
Received: by mail-io1-xd29.google.com with SMTP id
ca18e2360f4ac-7aca968a063so63574439f.0;
Thu, 02 Nov 2023 22:25:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1698989135; x=1699593935;
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=gVKLaYxdOab+rJB4hFcMeun7X5mq1kP+a/G5fKzSRTU=;
b=nShnSXD9DlIMNaY9AEpwAF1pYcCB6SSlfurcsnxPQulKYD53ISvxss4rm8YK1U+V5B
D33w9hLGbF7NPzl5xXbsIKm3J2VzE4D49YeazpU/9sWhvTNP2dnnrJ/27U996tB2TAgW
dqucIJ8SZBUgwF6agLQ2GhvkoyO059S+N+/NuswoNyreuvRMuSRCEjk0auzlHMc5PPdH
acl92Ob0dPV0x6TEzUkhktj6pmf8QaO5HjczfGukKLURTy7GsqpXg+IcaTLGHnEvHtba
VSschiPaHDrhTr2UatsM9zZYjVlSwNWFw8RgC1EXWQMipnjK1b9bqfEW5a0H/BBlT+EN
s+vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1698989135; x=1699593935;
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=gVKLaYxdOab+rJB4hFcMeun7X5mq1kP+a/G5fKzSRTU=;
b=ZL4I/mEExjo50aIT5RahbR8R8+WUCP+8mnLqtSjoDtnCFXuHsmVES38CfVaECi55re
SCT8AvGCcgIqREZ+Z/3YuSo6sYUTPQSgN4mOBJYpWITt33Jmz2xKPKo8HvNHRDEYdwvQ
yPhpEecwcOCN//PbqHWur7vLc0JawpxOIKkeq53KNJuLMUyFhDaHkBm00/ZR9w40fblq
sguhqgc3W/15AJ94F9qSbZZj0hEFP6kTZoJLwZKI6G2h/OXePlqKVQ45ls/FcBEldEux
pMC2+OHFoHCh6iWAQ2YK4LtyAqww7aIIvohOOpmjy3YDwJu5BNz9xhTf8cBtWjML4c/e
qbmg==
X-Gm-Message-State: AOJu0Yz3XQ4nzaUhTcun69qi2jfNU9RT6dsiJt7Ixp19SxGs+0vhWn3y
gwQlrhRKg4qcS7g17btdw107+oyxhv5i+ezei4M=
X-Google-Smtp-Source: AGHT+IHyHpezRZY5eWaKAaIIbkBzn2lu6J1en0SYcXmUYSD7CHfULW1BofFRoLCiU7AJ46MDyKpblK+mhixchYIQg0Y=
X-Received: by 2002:a05:6602:2b91:b0:79f:d4e6:5175 with SMTP id
r17-20020a0566022b9100b0079fd4e65175mr26460892iov.16.1698989135241; Thu, 02
Nov 2023 22:25:35 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
<ZTMWrJ6DjxtslJBn@petertodd.org>
<CALZpt+GQ9g-uwAGYogdaJcinVHRxs4=67hML78KbramJg=davA@mail.gmail.com>
<ZUNBHsw2BldPLvPc@petertodd.org>
In-Reply-To: <ZUNBHsw2BldPLvPc@petertodd.org>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Fri, 3 Nov 2023 05:25:24 +0000
Message-ID: <CALZpt+GBcqquPtf0YB07Rcy2OS0kUhv86s6g=69VrfSE72cYJQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="000000000000e2260b060938bbad"
X-Mailman-Approved-At: Fri, 03 Nov 2023 09:41:01 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
security@ariard.me, "lightning-dev\\\\@lists.linuxfoundation.org"
<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-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: Fri, 03 Nov 2023 05:25:41 -0000
--000000000000e2260b060938bbad
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> To be clear, are you talking about anchor channels or non-anchor channels=
?
> Because in anchor channels, all outputs other than the anchor outputs
provided
> for fee bumping can't be spent until the commitment transaction is mined,
which
> means RBF/CPFP isn't relevant.
I think the distinction is irrelevant here as pre-anchor channel if I have
one spendable HTLC output spend and I gain knowledge of my counterparty
commitment transaction from networks mempools, the spend is malleable and
can be used as a CPFP. If you assume anchor channels, you have 2 anchor
outputs as long both parties have balance outputs or pending HTLCs.
Though pre-anchor, legacy channels the counterparty commitment transaction
will have to be attached with a fee under min mempool fee for the
replacement cycling to happen, and let network congestion happen.
I think the more interesting case is a future world with package relay
deployed at the p2p level and anchor output on the lightning-side. Here the
most advanced replacement as illustrated in the test can happen (where
commitment has an anchor output - see L125).
Best,
Antoine
Le jeu. 2 nov. 2023 =C3=A0 06:26, Peter Todd <pete@petertodd.org> a =C3=A9c=
rit :
> On Thu, Nov 02, 2023 at 05:24:36AM +0000, Antoine Riard wrote:
> > Hi Peter,
> >
> > > So, why can't we make the HTLC-preimage path expire? Traditionally,
> we've
> > tried
> > > to ensure that transactions - once valid - remain valid forever. We d=
o
> > this
> > > because we don't want transactions to become impossible to mine in th=
e
> > event of
> > > a large reorganization.
> >
> > I don't know if reverse time-lock where a lightning spending path becom=
es
> > invalid after a block height or epoch point solves the more advanced
> > replacement cycling attacks, where a malicious commitment transaction
> > itself replaces out a honest commitment transaction, and the
> > child-pay-for-parent of this malicious transaction is itself replaced o=
ut
> > by the attacker, leading to the automatic trimming of the malicious
> > commitment transaction.
>
> To be clear, are you talking about anchor channels or non-anchor channels=
?
> Because in anchor channels, all outputs other than the anchor outputs
> provided
> for fee bumping can't be spent until the commitment transaction is mined,
> which
> means RBF/CPFP isn't relevant.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--000000000000e2260b060938bbad
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> To be clear, are you talking about anchor channels or=
non-anchor channels?<br>> Because in anchor channels, all outputs other=
than the anchor outputs provided<br>> for fee bumping can't be spen=
t until the commitment transaction is mined, which<br>> means RBF/CPFP i=
sn't relevant.<br><div><br></div><div>I think the distinction is irrele=
vant here as pre-anchor channel if I have one spendable HTLC output spend a=
nd I gain knowledge of my counterparty commitment transaction from networks=
mempools, the spend is malleable and can be used as a CPFP. If you assume =
anchor channels, you have 2 anchor outputs as long both parties have balanc=
e outputs or pending HTLCs.</div><div><br></div><div>Though pre-anchor, leg=
acy channels the counterparty commitment transaction will have to be attach=
ed with a fee under min mempool fee for the replacement cycling to happen, =
and let network congestion happen.</div><div><br></div><div>I think the mor=
e interesting case is a future world=C2=A0with package relay deployed at th=
e p2p level and anchor output on the lightning-side. Here the most advanced=
replacement as illustrated in the test can happen (where commitment has an=
anchor output - see L125).</div><div><br></div><div>Best,</div><div>Antoin=
e</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">Le=C2=A0jeu. 2 nov. 2023 =C3=A0=C2=A006:26, Peter Todd <<a href=
=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>> a =C3=A9crit=C2=
=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(=
204,204,204);padding-left:1ex">On Thu, Nov 02, 2023 at 05:24:36AM +0000, An=
toine Riard wrote:<br>
> Hi Peter,<br>
> <br>
> > So, why can't we make the HTLC-preimage path expire? Traditio=
nally, we've<br>
> tried<br>
> > to ensure that transactions - once valid - remain valid forever. =
We do<br>
> this<br>
> > because we don't want transactions to become impossible to mi=
ne in the<br>
> event of<br>
> > a large reorganization.<br>
> <br>
> I don't know if reverse time-lock where a lightning spending path =
becomes<br>
> invalid after a block height or epoch point solves the more advanced<b=
r>
> replacement cycling attacks, where a malicious commitment transaction<=
br>
> itself replaces out a honest commitment transaction, and the<br>
> child-pay-for-parent of this malicious transaction is itself replaced =
out<br>
> by the attacker, leading to the automatic trimming of the malicious<br=
>
> commitment transaction.<br>
<br>
To be clear, are you talking about anchor channels or non-anchor channels?<=
br>
Because in anchor channels, all outputs other than the anchor outputs provi=
ded<br>
for fee bumping can't be spent until the commitment transaction is mine=
d, which<br>
means RBF/CPFP isn't relevant.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org"=
rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</blockquote></div>
--000000000000e2260b060938bbad--
|