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
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
|
Delivery-date: Mon, 22 Jul 2024 05:06:52 -0700
Received: from mail-oo1-f59.google.com ([209.85.161.59])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBDRYHVHZTUGRBU4W7G2AMGQEFCERFWY@googlegroups.com>)
id 1sVroZ-0001Dm-M1
for bitcoindev@gnusha.org; Mon, 22 Jul 2024 05:06:52 -0700
Received: by mail-oo1-f59.google.com with SMTP id 006d021491bc7-5c654141680sf3398601eaf.0
for <bitcoindev@gnusha.org>; Mon, 22 Jul 2024 05:06:51 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1721650005; cv=pass;
d=google.com; s=arc-20160816;
b=FcjtWaMzLffezyPxBKoKyyF5WAfOnmIP2I0/dXkg29r76krpyj8ejwFMY+MvcpYjCt
+PCv5uxFsHirEtUwIQpvLjCUyKePzPjtJdPtvWqH36O9y6qGkjwOtm1wkOF0CoL/7NF5
/woju5vA+F+3RQ+43R4MU6q8yo6RG9VU8CihmNbEb7Gu7OpKvjBxhXOGFs8UxY4ljsGC
wGHQNNtpNUQfZPrfTHoeuPhfLcP3jORzc3SllFqasOEK55KGglJFmhtbb80vuZH/H6qb
IVdsiPYQfcpbHki2KzFnOKZDuyW/zG/q8spa1Qie9k4l+qnAupwh/R/nQFaE98Uh4LUO
oAKA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:in-reply-to:content-disposition
:mime-version:references:message-id:subject:cc:to:from:date
:feedback-id:sender:dkim-signature;
bh=tYXDsH5arjKv2W50PVtGlpnnwZhIfdC6U6w9XMTeAZ8=;
fh=mxtM/GxI3WIhY17fb5rwGAZk8FcYZWCDS2+8WgkBWgM=;
b=wyFezsIwLi3lHtHDbGlPLdX42oBVu3qPC2oKaHITIE9zVfixiKvKlT5eRZN/fctwpW
Iy+42Ebgx4M0SKTGaH/IInomRQ9qJhDudcj2vu+n+GwnqOoRgw1C/1TTAWEaa1uCBMbz
+zwN/8Xko2dFh/mevV5xmOwdHUUBnJB5WMvI8TrPstHH1PGioXoAFF7pkk+JjQKAIytS
qmuyHzasIedRS7TwYMCaxQyzAF2CwhkpREOKAGQLlbV8dZQlF97Nt9vF93FXAo11pEAg
Km8ZBc0NROrp7D99ajhRrO/1g0At9XgHkJLrKzvzsp27/uwLdc8EXFXbKPO1FYBbVEFN
PA5g==;
darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=fArmyUkT;
spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.151 as permitted sender) smtp.mailfrom=pete@petertodd.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1721650005; x=1722254805; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:in-reply-to:content-disposition:mime-version
:references:message-id:subject:cc:to:from:date:feedback-id:sender
:from:to:cc:subject:date:message-id:reply-to;
bh=tYXDsH5arjKv2W50PVtGlpnnwZhIfdC6U6w9XMTeAZ8=;
b=XVdcn0O4a1puWDP+ShtNZZy4Cdn3L1yqetThIjXKROkJJ/1pQp5/vVip/lmocIdcH9
MkVbJM3pSbQ8G5cy7U6qw982CG+lsHVUUfIBl85zmQmd9lUMBXqjQERT622zIiQgRsOp
BcTB1gd43toL8yVeiRJKLB/iQpTF1GUjG9yl6dqgKTw5VSdl+mywIUA18Af3bBfKFnnX
Df1ixciHIaxIxXD9eI6VGrKWCep2f3y8GUwZVDhJGebnOO60i7+0+jo8r3Y4QnoDFUuF
R+5FHSXqUXcYUQgPk+1cGALeejzOvZy3VqNV51Ugy3RTOivyGkmQaqtJ4mI4FARIbNSG
9vaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1721650005; x=1722254805;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:in-reply-to:content-disposition:mime-version
:references:message-id:subject:cc:to:from:date:feedback-id
:x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date
:message-id:reply-to;
bh=tYXDsH5arjKv2W50PVtGlpnnwZhIfdC6U6w9XMTeAZ8=;
b=V5CQ6MLzlHqcI06N53n5cxRIViZm2d40O3Dbonjr41/EJRvwyL2Xo+Xtu77bUQTAaA
Kt9DxzXK9c/wHG1Or6aikST9+7bnwn6CgAFLeF5c2DvYLg6NZK/R2sWGe0S6K8zwKEC9
rWxAYSVZtQq677JyUnrVATBUmmyJ2v7O4SBhhwd0u4U/ZHXL19+Q4SQ+WbNkOGh1KCXS
3bPcoK/QH2iBG2B0Jby3mPzn/YN3n13MpGTrYwUWudOHlU0rheEFH1kmkNYoT7PPeHJa
1vHGr5PzHOiRg/5OlNI82AHAmBVj3D6Dw0Sdnqt0KBXDnf8AuS6k24DelyzZoFvpvKI/
kGbA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVlGpO/mhXzmbT7bhBoVQEgITmiiGSpFUAX2XXW2f2/bejj21wmf+1cBuoJQ40P03lTIJmeAWCUJjUPiVvY/myqiR2sIN0=
X-Gm-Message-State: AOJu0YzaZRQFL4FxW10JYV9kkP2iNsxd1Pa1Wr9fcxI/O+5nV3P/CQfw
iyR1Uut4pUVsbmouxuV0kb96dbkNNqnudUVizFSQk+XXEcZp5Uyf
X-Google-Smtp-Source: AGHT+IF0SgJ3w9VXtmJ9PwbLsbwTV/BodwHHfGlcoub9OW/Dh4OsTrB2C7b7g+14tNOQXCS86ZhT+Q==
X-Received: by 2002:a05:6820:1e05:b0:5ce:3ccb:2118 with SMTP id 006d021491bc7-5d564fedb98mr3688157eaf.3.1721650005462;
Mon, 22 Jul 2024 05:06:45 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a4a:e8de:0:b0:5c4:69bc:810f with SMTP id 006d021491bc7-5d51eebf713ls4360523eaf.2.-pod-prod-07-us;
Mon, 22 Jul 2024 05:06:43 -0700 (PDT)
X-Received: by 2002:a05:6820:810:b0:5cd:4c18:93b2 with SMTP id 006d021491bc7-5d564cfc731mr384397eaf.0.1721650003480;
Mon, 22 Jul 2024 05:06:43 -0700 (PDT)
Received: by 2002:a05:6808:a09:b0:3d9:2ea5:e56e with SMTP id 5614622812f47-3dadf32f947msb6e;
Mon, 22 Jul 2024 04:45:59 -0700 (PDT)
X-Received: by 2002:a05:6808:1810:b0:3d9:33e9:e2b9 with SMTP id 5614622812f47-3dae657d6d2mr3744677b6e.24.1721648758484;
Mon, 22 Jul 2024 04:45:58 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1721648758; cv=none;
d=google.com; s=arc-20160816;
b=CAWGDc9dXZZADiUJRIm6/Z2F0HaJCuoETLA4Y/7yknXjerSATUjk4Je/SpTeqsmVqi
yo+0IhtjjfXJnT/jyhxul6iyZsUPnHw1kUbnIA7qYUFSlelHRyl758C1bof/47IRJ5dR
YrXhWR5gVzrc1j7Of4V2q1hqVW5IG3L9tBVmBxzd8hTN6ynp0kkWNvmdaHvt8sf9HV2R
r/XitqvAxQt3+pNmp2c9v5PRWofbdU5xQ6CE/Sh7mOQhEV2pGvuAR/ufqmbCCEA60Mbc
SAd3sgtRuUA1uJeMRcfZDUo+PGTkcJwKJaPhKsZv+XasYv6RxQJttFU8MQKV5QwqMWLX
6W2A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=in-reply-to:content-disposition:mime-version:references:message-id
:subject:cc:to:from:date:feedback-id:dkim-signature;
bh=/RN5O/THORAsaf0hvHIxJn2YW1sBZyKbQcJ/QmvFYTQ=;
fh=qAkUFgesXJOBZlEhHhc6qjOrC9x9vwcQK9K5cSmyNz0=;
b=hJOI4ELd54pt2irR0ofaGAr13hlA2llYhduqLNpX78Hr0mxPnqJnvw1ah+mcOOPG0o
ad1jM1RLPfPNp9LY3HSr6qD0YevIs02GXlynP7l757gwimRSE6IOW+4SC9kOpwn5Z9Dm
tnoxzxlAg0a1A57g0m52JvlVVz8Lt20q48A+VVWqevq4DRF8pN8GKj5nbL2CY2TvYkJX
S/pl+kqDZRF8loSzGTCm69lT3ugZVY2f/sTcxebhMTi8Bx1nSCM+fQ+/cnQ3SmVLXJzQ
5hMN31CO0T7BooFfPckMGxeWmRkfopG0o7ZRVaJ6b1uHDQ979jHzFiFc+WuMkn0pWKMb
/OnQ==;
dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=fArmyUkT;
spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.151 as permitted sender) smtp.mailfrom=pete@petertodd.org
Received: from fout8-smtp.messagingengine.com (fout8-smtp.messagingengine.com. [103.168.172.151])
by gmr-mx.google.com with ESMTPS id 5614622812f47-3dae08d3e89si264392b6e.0.2024.07.22.04.45.58
for <bitcoindev@googlegroups.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 22 Jul 2024 04:45:58 -0700 (PDT)
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.151 as permitted sender) client-ip=103.168.172.151;
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
by mailfout.nyi.internal (Postfix) with ESMTP id 7DE15138013E;
Mon, 22 Jul 2024 07:45:57 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
by compute4.internal (MEProxy); Mon, 22 Jul 2024 07:45:57 -0400
X-ME-Sender: <xms:dUaeZpfPe7HHWknFcLvhB1JzZLC4pxb4icALiYBPVh08RmBt7cRG0A>
<xme:dUaeZnMpY2divG2Sz1vAVmC__4uFyBgKgP_1OA5XlK2EnAtZn5guzEYxb8RddgyaJ
oLFed4xX5tdROdF8iM>
X-ME-Received: <xmr:dUaeZihQ2gOxFgY4vt2JX3HlY7Waqmr38R2TolRwdatbNHzxeC7UX2c8TpE>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrheejgdeggecutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenuc
fjughrpeffhffvvefukfhfgggtuggjsehgtderredttddunecuhfhrohhmpefrvghtvghr
ucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrthhtvg
hrnhepjeetvedvteelvdfgfeeftdekkeekjeffhefhfedugfegheeggeefgefgffehueff
necuffhomhgrihhnpegsihhttghoihhnohhpshdrohhrghdpghhoohhglhgvrdgtohhmpd
hpvghtvghrthhouggurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm
pehmrghilhhfrhhomhepphgvthgvsehpvghtvghrthhouggurdhorhhg
X-ME-Proxy: <xmx:dUaeZi99u6EBeSZ0TSNzw3a7tBgv3pzy0vEfrxxPA4urGfvZYRpdtA>
<xmx:dUaeZltL5LTa8EVC_UdOsOUgXd3JbVGmZbPu586gxsrrMG8o-tF4yQ>
<xmx:dUaeZhF0sgPbqkWE-Qcuiycnj03L0slxH7UMQ2yiTvR9tEOZ5CmAcQ>
<xmx:dUaeZsNCjBenYejrWpfXU2sS4mYBnWcEDNtNNavBxA1_pZlCDrfRgQ>
<xmx:dUaeZjWXeO6XEbxtbgfj4N3AZyO3y3a8d1IrHk1QaAjXZnYTDxwLB2F7>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
22 Jul 2024 07:45:52 -0400 (EDT)
Received: by localhost (Postfix, from userid 1000)
id 3CBE95F83F; Mon, 22 Jul 2024 11:45:31 +0000 (UTC)
Date: Mon, 22 Jul 2024 11:45:31 +0000
From: Peter Todd <pete@petertodd.org>
To: "David A. Harding" <dave@dtrt.org>
Cc: bitcoindev@googlegroups.com
Subject: [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster
mempool, without upgrading LN nodes; TRUC/V3 does not
Message-ID: <Zp5GW/yHzPB8wyjU@petertodd.org>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
<c6593662694f9d4a4fe999dd432f87ff@dtrt.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="CmiQh1B8k9DSHLU1"
Content-Disposition: inline
In-Reply-To: <c6593662694f9d4a4fe999dd432f87ff@dtrt.org>
X-Original-Sender: pete@petertodd.org
X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass
header.i=@messagingengine.com header.s=fm3 header.b=fArmyUkT; spf=pass
(google.com: domain of pete@petertodd.org designates 103.168.172.151 as
permitted sender) smtp.mailfrom=pete@petertodd.org
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.8 (/)
--CmiQh1B8k9DSHLU1
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jul 19, 2024 at 08:41:07PM -1000, David A. Harding wrote:
> 3. Limiting the worst-case free relay and excessive mempool eviction
> requires additional rules (e.g. one-shot RBFr) that are challenging
> to implement and analyze at present, as several devs have noted[3].
> Both implementation and analysis should become much easier if cluster
> mempool is deployed (also noted by devs), but the deployment of
> cluster mempool requires removal of CPFP carve-out, and removal of
> CPFP carve-out requires either the upgrade of thousands of LN nodes
> and channels or a drop-in solution (ideally one that can be analyzed
> independently from cluster mempool, like TRUC).
I'm going to answer this separately for the sake of easy citation in the
future. tl;dr: cluster RBFR makes the CPFP carve-out obsolete, fixing pinni=
ng
for existing implementations; TRUC meanwhile isn't even a drop-in solution,=
and
requires everyone to upgrade before cluster mempool is even possible.
To recap, the CPFP carve-out=C2=B9 is an exception to package size limits t=
hat
allows a single transaction to exceed those limits slighty, provided that t=
he
transaction has only one unconfirmed ancestor. This is relevant to protocol=
s
like Lightning, where your counterparty might try to pin a transaction by
spending one of the two anchor outputs with a large, low-fee, transaction s=
uch
that the total package size is just under the package limit. Notably, in th=
is
scenario, there is *no* way for you to broadcast a CPFP without the CPFP
carve-out because regardless of fee-rate, your transaction will simply be
rejected due to it causing the package limit to be exceeded.
I won't comment on whether or not the cluster mempool is genuinely incompat=
ible
with CPFP carveouts; I'm not convinced that's true. But that point is
irrelevant anyway. To understand why, let's look at package replacement.
Package replacement is the idea that we can do RBF with packages of
transactions. For situations where the CPFP carve-out is relevant, we can
instead evaluate the CPFP child transaction, and the parent transaction(s),=
as
a package and compare that package to the package consisting of the existin=
g
child transaction(s), and the parent transaction. With RBF alone, that woul=
d
allow you to defeat a package size pin by paying more in fees than the
conflicting child transaction(s), reducing this scenario to a straightforwa=
rd
BIP-125 Rule #3 total fees pin.
Actually implementing this type of package replacement is simple: if you
receive a single transaction with an unconfirmed parent, if the transaction=
is
rejected due to package limits, try again, treating it as a package
replacement.
Finally, with package (one-shot) RBFR, we defeat both the package size pin =
and
the Rule #3 pin: so long as your CPFP child transaction pays a higher fee-r=
ate
than the conflicting large, low-fee-rate, child transaction(s) made by the
attacker, you can replace the conflict and get the parent transaction(s) mi=
ned.
The only thing protocols need to do is ensure that the combination of paren=
t
transaction(s) and child CPFP doesn't itself exceed the package size limits=
,
which Lightning already does just fine.
This is a much better upgrade path than TRUC + cluster mempool. We don't ha=
ve
to wait for existing Lightning users to upgrade and open new channels. Inde=
ed,
we even fix existing pinning problems for existing Lightning implementation=
s,
which RBFR is already=C2=B2 doing!. And we actually fix pinning in general,=
for all
use-cases, not just the narrow subset that can make use of TRUC.
# References
1) https://bitcoinops.org/en/topics/cpfp-carve-out/
2) https://groups.google.com/g/bitcoindev/c/n2GNmnz0btw
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/Zp5GW/yHzPB8wyjU%40petertodd.org.
--CmiQh1B8k9DSHLU1
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmaeRlkACgkQLly11TVR
LzfJLg//Zyljmi4YmcyauyrFs3DYiC1ZCC+zXBOzDOxwiAeLTltdrU7fHX74k1LH
LYym7max1fXoRO2rRL7lilDxtg9nW4xUHnpmZ+pmCjjL0xruptw6OkQOgraYyXM2
SN7iCZp+j45pI39j9X0LNx5It6lCnP1TAJzU50sQUj6FC1F0NwPIrbdMc5QTLOE1
og5DfsgU86hDXeeYN+gBpZDEpnPyzNn7nDDM3tILPULTNlddvQ22ecxcYrCoYDdN
k9qhzdi3iRitua7nu2NoVzKAr8KWgVJDvo+CD+pY1OD0Q/DfAVxYXQbc9w08HrJN
w3iQHK6aW7Q4SI6YFkosTu/0UtjaaeLVFedr1zkn1EmQv542NXT8MpP0Ey6KFpKy
HNmmGkGDGWhleTCQm7xpVon2xv4g3UhQVC67bn+2eChtzgbAu4qm90zFUqpueu76
7vUe8kppF9ryf+YrC9Xtj9AgmrUrvK+aCmHkC3fw1hwsQwMCQ3g08/ed+qA4Osj2
5CqJJOycolpOdbH9E4FjLu0SXgw6apasBIG+NJHDrWg8jRYcnUs05+xhcMG7FUUr
+Ucdi1/CpKf8TyrH/0u8SWiCQl9a60VQ82kLPVIGQGsHL3FYQ0iL8IFgUc0IY9LC
l5srqLtPKRapRuwR9TuwVt7fZ3dOrZlYeasFhjsqS0gziG2BPsc=
=3HCN
-----END PGP SIGNATURE-----
--CmiQh1B8k9DSHLU1--
|
