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
|
Return-Path: <pete@petertodd.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id BBC82C0037
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jan 2024 04:46:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 8E68240445
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jan 2024 04:46:32 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 8E68240445
Authentication-Results: smtp2.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=Dbyak8X/
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, 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 0mOb06g6E53Q
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jan 2024 04:46:31 +0000 (UTC)
Received: from fhigh1-smtp.messagingengine.com
(fhigh1-smtp.messagingengine.com [103.168.172.152])
by smtp2.osuosl.org (Postfix) with ESMTPS id 20B7B400F1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jan 2024 04:46:31 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 20B7B400F1
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47])
by mailfhigh.nyi.internal (Postfix) with ESMTP id 297531140097
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Jan 2024 23:46:30 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
by compute6.internal (MEProxy); Mon, 29 Jan 2024 23:46:30 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=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=
fm3; t=1706589990; x=1706676390; bh=tm5sfPyhDXJ8qP8Act27W2cOiPRk
A/TQMSWx7FiAEh0=; b=Dbyak8X/26SotSUtYgBGiawIBX8Qf9mTDsnTLNwY+zui
QRpMfB4qtvrReVU525Ft4n7OqzIBhi5frSDMDcHdjdm/92mMCb0a8ta3aQwUOoaz
crg7yhXxVqp8t7Xis/qCbcLBIc4ijcSfw7h7EPDgxvGpLwC9ICnXMwD64WfynPG5
PpUGW+2Bid6t0Wn/vslf66ApkLAb7LDtfjpvEZaRog6cPmI+SMw2PFT7zX+mxyHD
5Ew9nAGe/feNf5JhZxaQ7QRjA/mwWAEqddr6GhKhP6iWwWbQZypOxUiIA5tQ05Lz
YAuxiqhIBiPhcFcu/Ey2JvSIiDX86Qu1SOaN5DyPtA==
X-ME-Sender: <xms:JX-4ZW_-07UZIi91vbpiprW6YDzPX7Ru4KGGnz9s397BwDfIbFVHWw>
<xme:JX-4ZWsrJfrdc2VhWx1mUcIRF6DJctnoTps47Es7rwtAelNEObLgOXp9lYZ02Dky1
VUnHqYH-Ndk5peM3bA>
X-ME-Received: <xmr:JX-4ZcD22a4SkTwenCBBxFdIoYHKW0UgzL__Doe7VhDIZTaU5RSTEFLeqexS>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfedthedgjeegucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre
ertddtvdenucfhrhhomheprfgvthgvrhcuvfhougguuceophgvthgvsehpvghtvghrthho
uggurdhorhhgqeenucggtffrrghtthgvrhhnpeeivddvleeikeejueekgfdtleefgeehhe
elffeuheetgefhleevjeefleegvefffeenucffohhmrghinhepphgvthgvrhhtohguugdr
ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe
hpvghtvgesphgvthgvrhhtohguugdrohhrgh
X-ME-Proxy: <xmx:JX-4Zef7YYQEMtWv_i9JAkUHZ2kyOz4Dihx-5lQf8uijxtJWLZjLbw>
<xmx:JX-4ZbOPQS19VAsEdRS7XHJe3l6mgOnEbJQ8vjmxefbOA9-X8DMymg>
<xmx:JX-4ZYmd7192N8mW3bIIWJhvj5q-8YYxnk5prtcGzK8vR5XRTAekrQ>
<xmx:Jn-4ZQqqNmL-IyAzViUSMIS_CxQWGI__MaQU_Z1smOFeUOrbz8Wzhg>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
<bitcoin-dev@lists.linuxfoundation.org>; Mon,
29 Jan 2024 23:46:29 -0500 (EST)
Received: by localhost (Postfix, from userid 1000)
id 6F5AB5F849; Tue, 30 Jan 2024 04:46:27 +0000 (UTC)
Date: Tue, 30 Jan 2024 04:46:27 +0000
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Zbh/I+7NIoAmlEt8@petertodd.org>
References: <ZbFle6n0Zu3yUV8o@petertodd.org>
<ZbSipq2QQx904Ofo@console>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="EnEimIduxQH1a9K8"
Content-Disposition: inline
In-Reply-To: <ZbSipq2QQx904Ofo@console>
Subject: Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's
Required For Fee Payment
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, 30 Jan 2024 04:46:32 -0000
--EnEimIduxQH1a9K8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jan 26, 2024 at 10:28:54PM -0800, Brandon Black wrote:
> Hi Peter,
>=20
> On 2024-01-24 (Wed) at 19:31:07 +0000, Peter Todd via bitcoin-dev wrote:
> > It is
> > expected that CTV would be usually used with anchor outputs to pay fees=
; by
> > creating an input of the correct size in a separate transaction and inc=
luding
> > it in the CTV-committed transaction; or possibly, via a transaction spo=
nsor
> > soft-fork.
> >=20
> > This poses a scalability problem: to be genuinely self-sovereign in a p=
rotocol
> > with reactive security, such as Lightning, you must be able to get tran=
sactions
> > mined within certain deadlines. To do that, you must pay fees. All of t=
he
> > intended exogenous fee-payment mechanisms for CTV require users to have=
at
> > least one UTXO of suitable size to pay for those fees.
>=20
> I understand your reservations with regard to CTV-based protocols for
> scaling bitcoin and lightning. Fortunately, the "user gotta have a UTXO"
> concern is readily answered (and you actually gave one answer to
> approximately the same concern from me when we discussed lightning
> fees): If the user's balance inside the protocol is not sufficient to
> pay exit fees then they aren't going to try to exit; so their
> in-protocol balance can be used to pay fees. With ephemeral anchors
> throughout the tree, an exiting user would spend their leaf UTXO, and
> the ephemeral anchors along the path to their leaf to create a package
> of the necessary fee rate to facilitate their timely exit.
>=20
> Alternatively, users entering into a channel tree protocol (e.g. Timeout
> Trees) can have their leaf include a second UTXO commitment which would
> create a fee-paying output exactly when they need it; without causing a
> scaling problem.
You are assuming a specific type of CTV use-case. Not all CTV use-cases have
this property, which is why I called this a footgun: attractive, but likely=
to
lead to protocol designs with unexpected flaws.
Secondly, anchor outputs/CPFP is significantly less efficient than RBF, due=
to
the extra bytes required for the CPFP transaction. As I explained in the em=
ail
you are replying to, this is a danger to mining decentralization because it
requires less bytes to pay fees with out-of-band fee payments.
It is much better to deal with fees now, before CTV is standardized as-is, =
in a
way that allows for efficient fee payment via RBF rather than locking in
inefficient CPFP designs that invite out-of-band fees.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--EnEimIduxQH1a9K8
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmW4fyEACgkQLly11TVR
LzehBg//eJ/iBuFMJEqhe1KAwN6s8Lzn6qKJNujbZijVpFg9rCdWzNSJYRjuCfQH
zVGeuQiD7j+9Kz74GulpTLcsonAn0yLUvF3DWRrBkzbT2ElNfzjY5QIisDlfEsLm
YicY/fEy/9shwuLGcqmCo7g67jJmfQ7QYTH6kgf8wi01vmMSjexujtis8Buf3ngi
QYlqExG498KX1xygS1epnd3eTnhGpcrDV+X8yiy/ld82Qac5UdLmEeh3X5toic+H
ctum0l9q1F2QV1igiFMhJqC8UEzbs8+3rWJg0T/GjQkuH+qbguzs7AgdlAb+x3SV
DXZBLBFPxcA8FoUJB3GjoeOyFRXucw/8bswJGfVH8yN7ptp0gMGMCY/Go+HTbAoc
P6+SAqRMKiCHUX0R707voh4uIwt9IPNUljY/fDvWCTC4u7lo23vs95J7brU9ypRd
FZo/CJWiGn9amdzQjICVUcJqudO2XcBVO6Y84aXVusACbuGpFdZydESydAlOB9+k
1EKWHVZtdt1R4991j+F0lhEh14luaPwpAnQfA6LACDW2Mw0RQhuTrZS7ogJkh0eF
8HYTeqtiZcUUH9z9iQgrZYfaqY5VENDzqMJ9Ud9P2OaH0OoZipbcPn3kE/s2v76J
PT7byu1PP1wA7CiIzV7YFyrK4U/ygAAX+ILUsdCm7o8eFd39BgY=
=imfH
-----END PGP SIGNATURE-----
--EnEimIduxQH1a9K8--
|
