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
|
Return-Path: <pete@petertodd.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 40FCEC0032;
Sat, 4 Nov 2023 07:26:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id EC2B660B29;
Sat, 4 Nov 2023 07:26:36 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org EC2B660B29
Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key,
unprotected) header.d=messagingengine.com header.i=@messagingengine.com
header.a=rsa-sha256 header.s=fm3 header.b=PVA3M1Vf
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Level:
X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5
tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id cXp1z_MztQRN; Sat, 4 Nov 2023 07:26:35 +0000 (UTC)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com
[64.147.123.24])
by smtp3.osuosl.org (Postfix) with ESMTPS id 14DB060F04;
Sat, 4 Nov 2023 07:26:34 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 14DB060F04
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
by mailout.west.internal (Postfix) with ESMTP id B50DF3200946;
Sat, 4 Nov 2023 03:26:28 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
by compute2.internal (MEProxy); Sat, 04 Nov 2023 03:26:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-type:content-type:date:date
:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
:message-id:mime-version:references:reply-to:sender:subject
:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
:x-sasl-enc; s=fm3; t=1699082788; x=1699169188; bh=FenXAVY8h2MHn
JG159MiSi3c5NPd8UHbaozERe+TvtM=; b=PVA3M1VffEs5H1v4O1/19mx3bcY+K
N5pogdM/Q8V9tr2DeY7WsVbDVd6XEBb3IL+uI/s6k5TmixBA2HMXy13UMaGNWRrz
tNhqCoeG04CHPORLs5cWIDaaLKj/GYfu3O9yiwb/I2nMcA1de1evwYR4Y89GNeod
ogzPlhEutQT8wFY6VfK2VnPV2JInWP6hZyPxBJN17vqT0C7ZZJjt8DKg5KGsg9fZ
WnjDHwFW5fOD/iu4Efl+iwmYQmJVum9DslCtUSzTuGPTfjGIK5kLhwN5SCvQ8wLZ
bJKXaO4HHoB4hiHtnrCpF6HmzTu3pPIrGAX3TIs0aXKDJzJznx7r0wPfQ==
X-ME-Sender: <xms:I_JFZUg9Y2iehrXPWbBaJSUhymHMWP2u4YIo3_p8HnQyl2XUW2heWw>
<xme:I_JFZdDjpdGH9VV5AHHsThZqh52Xvo6d39W7Aolajtw_N4kq4bWZwyB1nNbH3Zv2h
2vWvtPuCF8Nq_cXMRU>
X-ME-Received: <xmr:I_JFZcE3b6kHLdah4STXzgbV6RvKDGX5U1G7DuYYgpxhxQ5ZkjDy3GXFnJGNlw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddtledguddtiecutefuodetggdotefrod
ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
enucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefrvght
vghrucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrth
htvghrnhepledvleelffdtudekudffjefgfeejueehieelfedtgfetudetgeegveeutefh
jedtnecuffhomhgrihhnpehpvghtvghrthhouggurdhorhhgnecuvehluhhsthgvrhfuih
iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvsehpvghtvghrthhouggu
rdhorhhg
X-ME-Proxy: <xmx:I_JFZVSPQRkSkdAmIv5dkKIu5QT3x4YUYMokyoIYkIRTYfoYRh-MDg>
<xmx:I_JFZRxDY90rZxSHyTuWhqGLt9QDSaWDX_B-umc23py4lQSXQyemdA>
<xmx:I_JFZT5XRRjqz_XeAXbC_qxDLXVnXlydZ4qTtg1JfbsaKB2axmUPrg>
<xmx:JPJFZUog-M1o-u3ROkqGF9rtvpTvgC7VqhEzzhu6Sm6fYPYl5lFMEw>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat,
4 Nov 2023 03:26:27 -0400 (EDT)
Received: by localhost (Postfix, from userid 1000)
id 8EB505F83F; Sat, 4 Nov 2023 07:26:24 +0000 (UTC)
Date: Sat, 4 Nov 2023 07:26:24 +0000
From: Peter Todd <pete@petertodd.org>
To: Antoine Riard <antoine.riard@gmail.com>
Message-ID: <ZUXyICh45JP6OnDu@petertodd.org>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="IQY6NmMQ//1MIqD4"
Content-Disposition: inline
In-Reply-To: <CALZpt+GBcqquPtf0YB07Rcy2OS0kUhv86s6g=69VrfSE72cYJQ@mail.gmail.com>
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: Sat, 04 Nov 2023 07:26:37 -0000
--IQY6NmMQ//1MIqD4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Nov 03, 2023 at 05:25:24AM +0000, Antoine Riard wrote:
> > To be clear, are you talking about anchor channels or non-anchor channe=
ls?
> > Because in anchor channels, all outputs other than the anchor outputs
> provided
> > for fee bumping can't be spent until the commitment transaction is mine=
d,
> which
> > means RBF/CPFP isn't relevant.
>=20
> 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.
>=20
> 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 you are misunderstanding a key point to my OP_Expire proposal: beca=
use
the ability to spend the preimage branch of the HTLC goes away when the ref=
und
branch becomes available, replacing cycling or any similar technique becomes
entirely irrelevant.
The situation where Carol prevents Bob from learning about the preimage in =
time
simply can't happen: either Carol collects the HTLC with knowledge of the
preimage, by spending it in a transaction mined prior to the expiration time
and ensuring that Bob learns the preimage from the blockchain itself. Or the
HTLC expires and Bob can use the refund branch at his leisure.
> 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 t=
he
> most advanced replacement as illustrated in the test can happen (where
> commitment has an anchor output - see L125).
Again, with OP_Expire, whether or not package relay or anything similar exi=
sts
is irrelevant. Replacement cycling is totally useless because there is a
defined time window in which the HTLC can be spent with the preimage, after
which only the refund branch can be used.
Indeed, with OP_Expire Lightning nodes will no longer need to monitor mempo=
ols
for preimages at all. If the preimage is used, it is guaranteed to end up in
the chain, and the Lightning node is guaranteed to see it provided they have
access to up-to-date blockchain data.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--IQY6NmMQ//1MIqD4
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmVF8hQACgkQLly11TVR
LzfkvQ//Xg00TpXrtD8FJKnzZ4paHt5+QCmapNmH2GbJxQxZVfD8PJ82SZI26ici
gQZeAo5SPP+a+TEbNdazDqcEUwbCt0DvDHWOG9tL2vHHfoe1pEbjyYdjI/PNABlX
Wml2Nr6J4vMT3d9kZFHVY5QHe4jeg8PE3AAIg79WRn2aDJoZpintvqDXy3xOBIBM
Yh2eY+VIYCotdA8qbD7BFqQIX+Rns2Le9m/9AFOTynTr5cmsvRTHej2uZm30YQS5
GDyhfiKkD8IArkhJ6dq2D4FNbfTM/OOkttX4aJJqlAb2SRhv5Jtq8vaSJGiBm1VA
xCUB8Y9088nNfRlGCwxBd8/0zjBC4ynU5GZLDDRHfqMhXCNw4gOZu5HC+MQ2LUOd
+Q9vkdDn5O0m+SHPiJElpkmR5zMb8UNxnCnJOQmQS14/w6EloVjobcunlFOhEP/o
uQ3pd8QhIvDTeigKHr6bMJ84IUpuRctPXuY1Tso5+jAaRs48a0hNmDsY/epD5pMN
gFQYQ72CtJDQEiuy7klCaNbFSr+KeR9ihD83Og9/QDnMexy2cEZN6iISWFqnmVkt
rgIRfM2UlTXj/ak2HMMiYctFmefsBqTQAtOMCi83foldOFrzwiRLcSoH19kIo2QS
neI5Gcc6hj6uek/yZR+UIVM5RL3wOoj8L6Qcs/wtRTpIKjNCPQQ=
=2Mnp
-----END PGP SIGNATURE-----
--IQY6NmMQ//1MIqD4--
|
