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
|
Return-Path: <pete@petertodd.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7ADEFC0037
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Dec 2023 21:11:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 2AE3461099
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Dec 2023 21:11:39 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 2AE3461099
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=fm2 header.b=Bxz3HDwz
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=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 dgr-zgbN0UYv
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Dec 2023 21:11:38 +0000 (UTC)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com
[66.111.4.28])
by smtp3.osuosl.org (Postfix) with ESMTPS id C12A361063
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Dec 2023 21:11:37 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org C12A361063
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
by mailout.nyi.internal (Postfix) with ESMTP id C3D6C5C07BB;
Wed, 20 Dec 2023 16:11:31 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
by compute4.internal (MEProxy); Wed, 20 Dec 2023 16:11:31 -0500
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:subject:subject:to
:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
fm2; t=1703106691; x=1703193091; bh=tmErTbPXai6GqyGx9rBJtWCQjqZ9
lXnY4OFrhf8ZpD0=; b=Bxz3HDwz0I/nRnMl1feNTWr484oWTSiYuP+u7qGo/9VR
ovo31O8y2mBpcHoAu0TAojr9+K+KBA7RQfeqxm467apyqQkid2prWyBlghI/Nejb
YuftvnxsC3fgl8WefbwzUu0ph74nwyiaSGWCnFTlf6kJKhKVnfkL59fQO+VrYPTZ
/0GRmgRTrBzhKMe8q6yZDrEPkt13v/tS2Vqic/qZ0Dx+TtScUussVdmCUjiifNqz
z4dxS+kEjQqC4VXs/01yCSrkm7vHRhvCua4a1E14IYDN6IaHXXNlwJWg5oUM9Z6q
NCrvKuBz8/0jQm15WEh/fx2QtcGWHbwzkMQpbL8Naw==
X-ME-Sender: <xms:g1iDZYcnz806nkaE-hLF9T7kU4h0M1Wu8dOjCNA4n5a2GP5dM6RjhQ>
<xme:g1iDZaM6IYmAjuNBpI_HOr5KGveLTNAD8jdZ1qDL0qEe4g5S0pf9E-BYFLVgb6o2o
7TL8aSDGb_bR3QABGI>
X-ME-Received: <xmr:g1iDZZjBeJ14T_b2m1Jr4jk7IRgijSVE2_V7eQ6p3_gqetv_BFI0AGN_5g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdduvddgudeghecutefuodetggdotefrod
ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
enucfjughrpeffhffvvefukfhfgggtuggjsehgtdorredttddvnecuhfhrohhmpefrvght
vghrucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrth
htvghrnhepfefgieegffeugfffgfefffdtieegkeehtdefgfdtieejgfevteettddukedv
gffgnecuffhomhgrihhnpehlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdhpvghtvg
hrthhouggurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi
lhhfrhhomhepphgvthgvsehpvghtvghrthhouggurdhorhhg
X-ME-Proxy: <xmx:g1iDZd9pXBcR49RNkIokqinU7bVWbTl8BlNCFbcPAAENj181dHir3g>
<xmx:g1iDZUsyTzHDBDTpW7yhRXWk9hJVMMK2N3prQWCcKq13ADoeKMTUyA>
<xmx:g1iDZUFo8g34VUw3PeISbLsa7NQJfSS2laaIgVMdvlH_YHIIHo490w>
<xmx:g1iDZWL9qrKzh2OEpi2y7G23t99E0LkrkPNxfyLvEeTXs6sBcgWB6g>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
20 Dec 2023 16:11:31 -0500 (EST)
Received: by localhost (Postfix, from userid 1000)
id 68A8A5F84E; Wed, 20 Dec 2023 21:11:28 +0000 (UTC)
Date: Wed, 20 Dec 2023 21:11:28 +0000
From: Peter Todd <pete@petertodd.org>
To: Greg Sanders <gsanders87@gmail.com>
Message-ID: <ZYNYgBovvwodqSuZ@petertodd.org>
References: <ZYMhEJ3y11tnDOAx@petertodd.org>
<CAFXO6=KS05So_5FizLJxCLEPwBxNPV9Wrgi=9sjzmrZ+PLpLOQ@mail.gmail.com>
<ZYNFK5V5e9PnT9eL@petertodd.org>
<CAB3F3DuKxw_osQcW++GeasGVEedcZ16inqrQPoAWQiF4HsGbdw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="q0iLX+HWYyGFjg7I"
Content-Disposition: inline
In-Reply-To: <CAB3F3DuKxw_osQcW++GeasGVEedcZ16inqrQPoAWQiF4HsGbdw@mail.gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] V3 Transactions are still vulnerable to
significant tx pinning griefing attacks
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: Wed, 20 Dec 2023 21:11:39 -0000
--q0iLX+HWYyGFjg7I
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Dec 20, 2023 at 03:16:25PM -0500, Greg Sanders wrote:
> Hi Peter,
>=20
> Thanks for taking the time to understand the proposal and give thoughtful
> feedback.
>=20
> With this kind of "static" approach I think there are fundamental
> limitations because
> the user has to commit "up front" how large the CPFP later will have to b=
e.
> 1kvB
> is an arbitrary value that is two orders of magnitude less than the
> possible package
> size, and allows fairly flexible amounts of inputs(~14 taproot inputs
> IIRC?) to effectuate a CPFP.
Why would you need so many inputs to do a CPFP if they all have to be
confirmed? The purpose of doing a CPFP is to pay fees to get another
transaction mined. Unless you're in some degenerate, unusual, situation whe=
re
you've somehow ended up with just some dust left in your wallet, dust that =
is
barely worth its own fees to spend, one or maybe two UTXOs are going to be
sufficient for a fee payment.
I had incorrectly thought that V3 transctions allowed for a single up-to 10=
00vB
transaction to pay for multiple parents at once. But if you can't do that, =
due
to the restriction on unconfirmed inputs, I can't see any reason to have su=
ch a
large limit.
> I'd like something much more flexible, but we're barely at whiteboard sta=
ge
> for alternatives and
> they probably require more fundamental work. So within these limits, we
> have to pick some number,
> and it'll have tradeoffs.
>=20
> When I think of "pinning potential", I consider not only the parent size,
> and not
> only the maximum child size, but also the "honest" child size. If the hon=
est
> user does relatively poor utxo management, or the commitment transaction
> is of very high value(e.g., lots of high value HTLCs), the pin is
> essentially zero.
> If the honest user ever only have one utxo, then the "max pin" is effecti=
ve
> indeed.
Which is the situation you would expect in the vast majority of cases.
> > Alice would have had to pay a 2.6x higher fee than
> expected.
>=20
> I think that's an acceptable worst case starting point, versus the status
> quo which is ~500-1000x+.
No, the status quo is signed anchors, like Lightning already has with anchor
channels. Those anchors could still be zero-valued. But as long as there is=
a
signature associated with them, pinning isn't a problem as only the intended
party can spend them.
Note BTW that existing Lightning anchor channels inefficiently use two anch=
or
outputs when just one is sufficient:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December=
/004246.html
[Lightning-dev] The remote anchor of anchor channels is redundant
Peter Todd, Dec 13th, 2023
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--q0iLX+HWYyGFjg7I
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmWDWH4ACgkQLly11TVR
Lzec0g/6AxYkVbsqn4ggDFJaf9cjNDMK0CSImUbZGis+enzrLEOSOzXQanW4Z3xG
A5oMLhXiDdZEiBDLbppbRwhahLMZ2OFkZ4ZQtsSIO0hgzYeljz4vbuKC3i5jtu84
OBz3m+TqvuIiPUwVmB7pKd77okPsDMdy8EN5f10rr+YT7RZgiYiOr8IRQiKL+EVg
O8Po0ms7WrLz6W0C8s0zNDGgOEeKVUjPhSEWracaHCASioptvTeH8UWnMsxwqlin
2YNKSp5DFvokLPNWpCU9uOCmuQPk6pc8Hn/CpPOuz18qPouoIUjkpyF3Erx+kFaD
ryIl4rjzSIWJuTxPGrXlMoxEG88SZboLKDmHTBOBwYh1OykpXzgjJG+hLsSkH9gG
mgjMdal4eFOQiqQQObEnu0mhQQl44hkqOtsD5JFHT53ruY/4bbV/kL9CEyghVwGC
mx+Gn4D55k8zgvF1ACwtTZLI63McAI9IT8Tn3F6IkvTsCLIFOhVMA+HwEx4WMpy4
/+f5Oi+xAzpCfUltTyZhEyHp+G5+g/5xffrrgD4mBpgaML6i7lZkIYVfmipCNO8z
4ljZnCCme/xXF0GZUV2l3wdbXVXL/ioCUunlj+SAciT9KRzsWpvhKCJHUkng418R
OJaiDG3+IwYSSvYgNRGJbZjtwuNf48h6bzkGuH4SQcImZZ6hcEc=
=Yt7F
-----END PGP SIGNATURE-----
--q0iLX+HWYyGFjg7I--
|
