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
|
Return-Path: <michaelfolkson@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 75594C0037;
Thu, 25 Jan 2024 12:58:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 5D0C240883;
Thu, 25 Jan 2024 12:58:07 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 5D0C240883
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=BpTnZLZL
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 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,
RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ogr5Tkhoelb9; Thu, 25 Jan 2024 12:58:06 +0000 (UTC)
Received: from mail-0301.mail-europe.com (mail-0301.mail-europe.com
[188.165.51.139])
by smtp4.osuosl.org (Postfix) with ESMTPS id 338A5402D2;
Thu, 25 Jan 2024 12:58:06 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 338A5402D2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1706187478; x=1706446678;
bh=H2dYql4M8Nc0tk4FxcDs69dBvrpnwGSy/60IBfmBv24=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=BpTnZLZLRJaSdTy+YkyKqNuOSJJoqOqriOMhJCds4+x1I7THw9SndTgnyifE9FJiw
Z1F34nDMu+sCy+lT/GrkixuqktZn8n2uLKFbB0XAHn2li8X5cjwJxWcDUm5iAH4RCg
X+A4/Lpa7a6X4D3+A1rR6XEMO69BWmN2ezcxhRF6Phj2VNXhvfIdmJ+edr97pcqqBK
UCubhFsevX1urTYY6Mu4ZlZAeI7mL1M2tA1qLyJDbTxnx0g2yXYmh7rRqu7FxGmigg
eamoGPa+mTnjWnPzruzbDBGhKpsBt0RfDFaXLokhsobCkx0WB4Z5csEcOF4bTtwJtu
q/DTFC3SaEFsQ==
Date: Thu, 25 Jan 2024 12:57:52 +0000
To: Peter Todd <pete@petertodd.org>
From: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <4619vs2aZBsW1lr3ihqjM6TdRgx8CuA_wRwXetu7jZZcL8r3oWUy7xOPkT-qJ0xxT79_Ss6it2chOWAAWPJuU8YSCzjaNOd6JvnMvWTBc-c=@protonmail.com>
In-Reply-To: <ZbFle6n0Zu3yUV8o@petertodd.org>
References: <ZbFle6n0Zu3yUV8o@petertodd.org>
Feedback-ID: 27732268:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 25 Jan 2024 16:15:04 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org,
Lightning Dev <lightning-dev@lists.linuxfoundation.org>
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: Thu, 25 Jan 2024 12:58:07 -0000
Hi Peter
Interesting post. By implicitly committing in advance to the fee paid by th=
e spending transaction CTV is certainly nailing its colors to the CPFP mast=
rather than operating in a RBF world. And in a future high fee environment=
(ignoring whatever is driving those high fees, monetary or non-monetary us=
e cases) as you state paying for an additional CPFP transaction is suboptim=
al rather than just replacing an existing unconfirmed transaction.=20
I did a cursory search to look for an in depth technical comparison of CPFP=
and RBF and I found this from Antoine (Poinsot) on Bitcoin StackExchange [=
0]. In that he states his view that:
"If most nodes didn't enforce mandatory BIP125 signalling, RBF would be sup=
erior in all aspects to CPFP from the perspective of the emitter of transac=
tion. CPFP is much less efficient, and not always possible: you need the tr=
ansaction to have a change output and (at least at the time of writing [0])=
the parent to pass policy checks on its own, for instance if it's below th=
e minimum feerate of most mempools on the network you won't be able to CPFP=
it at the moment."
I assume that a CTV based LN-Symmetry also has this drawback when compared =
to an APO based LN-Symmetry? In theory at least an APO based LN-Symmetry co=
uld change the fees in every channel update based on what the current marke=
t fee rate was at the time of the update. In today's pre LN-Symmetry world =
you are always going to have justice transactions for revoked states that w=
ere constructed when the market fee rate was very different from the presen=
t day's market fee rate.
Thanks
Michael
[0]: https://bitcoin.stackexchange.com/questions/117703/comparison-between-=
cpfp-and-bip125-for-fee-bumping
--
Michael Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
On Wednesday, 24 January 2024 at 19:31, Peter Todd via bitcoin-dev <bitcoin=
-dev@lists.linuxfoundation.org> wrote:
> CheckTemplateVerify(1) is a proposed covenant opcode that commits to the
> transaction that can spend an output. Namely, # of inputs, # of outputs,
> outputs hash, etc. In practice, in many if not most CTV use-cases intende=
d to
> allow multiple parties to share a single UTXO, it is difficult to impossi=
ble to
> allow for sufficient CTV variants to cover all possible fee-rates. 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 inclu=
ding
> it in the CTV-committed transaction; or possibly, via a transaction spons=
or
> soft-fork.
>=20
> This poses a scalability problem: to be genuinely self-sovereign in a pro=
tocol
> with reactive security, such as Lightning, you must be able to get transa=
ctions
> mined within certain deadlines. To do that, you must pay fees. All of the
> intended exogenous fee-payment mechanisms for CTV require users to have a=
t
> least one UTXO of suitable size to pay for those fees.
>=20
> This requirement for all users to have a UTXO to pay fees negates the
> efficiency of CTV-using UTXO sharing schemes, as in an effort to share a =
UTXO,
> CTV requires each user to have an extra UTXO. The only realistic alternat=
ive is
> to use a third party to pay for the UTXO, eg via a LN payment, but at tha=
t
> point it would be more efficient to pay an out-of-band mining fee. That o=
f
> course is highly undesirable from a mining centralization perspective.(2)
>=20
> Recommendations: CTV in its current form be abandoned as design foot-gun.=
Other
> convenant schemes should be designed to work well with replace-by-fee, to=
avoid
> requirements for extra UTXOs, and to maximize on-chain efficiency.
>=20
> 1) https://github.com/bitcoin/bips/blob/deae64bfd31f6938253c05392aa355bf6=
d7e7605/bip-0119.mediawiki
> 2) https://petertodd.org/2023/v3-transactions-review#anchor-outputs-are-a=
-danger-to-mining-decentralization
>=20
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
