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
|
Return-Path: <pete@petertodd.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 8C223C0037;
Tue, 30 Jan 2024 04:38:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 5861D402BC;
Tue, 30 Jan 2024 04:38:32 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 5861D402BC
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=Q2HV+9Hg
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 smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id B5cz7g7sM_g7; Tue, 30 Jan 2024 04:38:30 +0000 (UTC)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com
[66.111.4.28])
by smtp2.osuosl.org (Postfix) with ESMTPS id C489E400F1;
Tue, 30 Jan 2024 04:38:29 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org C489E400F1
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
by mailout.nyi.internal (Postfix) with ESMTP id AE29F5C0103;
Mon, 29 Jan 2024 23:38:28 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
by compute2.internal (MEProxy); Mon, 29 Jan 2024 23:38:28 -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=
fm3; t=1706589508; x=1706675908; bh=lJxt2D5PCnXulmndhQNmq+ui6zT9
2CVKLZIG2L22L1M=; b=Q2HV+9HgJ6ADc1Evr7CGememSJ4QKbJgxqGEhJrj0QvP
7eG6phjfGfqnmzgMkDrNMGfnyaCx7B8XlR3oLc3n+trmPfQgR3LokgLTEnMH7Sr9
ijxt7hzTy3Nlim3LL1CZNyRp6X1mmTsMt6ASXEXsxn1l1t3ByGqRcm8po1y1lsrt
W/abFO6wfik295kaCoIjSoKhlm8/9D9qJ/78pmQ2uoJ7VVetZTIlwFqByfIFXNZw
aPnTOwekQGAWBNdzINEgQb6/DEnjXudEtvkWZpY2BkjmxYwUH/HrYQ+2VEjlpRy0
lhKfqlYMeGxk88zCs/YUg8uXPjPO0ES7hfp7iZflKQ==
X-ME-Sender: <xms:RH24Zczhk_-UL374nPW8S2FTCd7neX253tXHsWdP5U5f9CCFaT1juA>
<xme:RH24ZQSI2ga8GFouaTP-7JiAHMnqo8yDb2SCm3OzdhNIa_lidG3eiDdaDYou0TLPy
jzEYW6nr-HzRjsk86s>
X-ME-Received: <xmr:RH24ZeXZTxSAyhxKZ0uNVPtu9pCxG4TuE5Pac-MJ9twYgLB7mc2uiVaRbFZO>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfedthedgjedvucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtvdenucfhrhhomheprfgvthgv
rhcuvfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtth
gvrhhnpeelvdellefftddukeduffejgfefjeeuheeileeftdfgteduteeggeevueethfej
tdenucffohhmrghinhepphgvthgvrhhtohguugdrohhrghenucevlhhushhtvghrufhiii
gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvgesphgvthgvrhhtohguugdr
ohhrgh
X-ME-Proxy: <xmx:RH24Zajwwh1lOfOlR7ZCRbrlAY6vFt6hmFGCsDYx6puxDiLH5QaYwQ>
<xmx:RH24ZeArW5cCpzStultSl98nVhkot7Nq6sNjALSyHkGa76wC6LFhvQ>
<xmx:RH24ZbKKo47oEVG7mHD2Qc3E53KdJPRT5UIOuajT6NUtSZ6Zv9ioDg>
<xmx:RH24ZQ1SLYgCmEIi1ZcTXUtFcpDnr5R3YGHSvPyLYxjw6qFwlJYYOw>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
29 Jan 2024 23:38:27 -0500 (EST)
Received: by localhost (Postfix, from userid 1000)
id 288B05F849; Tue, 30 Jan 2024 04:38:26 +0000 (UTC)
Date: Tue, 30 Jan 2024 04:38:26 +0000
From: Peter Todd <pete@petertodd.org>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Zbh9Qqk2jK0tqKgp@petertodd.org>
References: <ZbFle6n0Zu3yUV8o@petertodd.org>
<4619vs2aZBsW1lr3ihqjM6TdRgx8CuA_wRwXetu7jZZcL8r3oWUy7xOPkT-qJ0xxT79_Ss6it2chOWAAWPJuU8YSCzjaNOd6JvnMvWTBc-c=@protonmail.com>
<9tVZA3A4x-GZB5wQ1kMUoyyYXqvGS4MP4iDrLx1FCFHly-MU--II8evpgdcf2Xb9JZWDsY0kEB8r9dClzPrOk_V8EiWtHms8fvlunZQNGrA=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="bmdDGprMOYGQ9Ewu"
Content-Disposition: inline
In-Reply-To: <9tVZA3A4x-GZB5wQ1kMUoyyYXqvGS4MP4iDrLx1FCFHly-MU--II8evpgdcf2Xb9JZWDsY0kEB8r9dClzPrOk_V8EiWtHms8fvlunZQNGrA=@protonmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org,
Lightning Dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-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:38:32 -0000
--bmdDGprMOYGQ9Ewu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jan 30, 2024 at 04:12:07AM +0000, ZmnSCPxj wrote:
> Peter Todd proposes to sign multiple versions of offchain transactions at=
varying feerates.
> However, this proposal has the issue that if you are not the counterparty=
paying for onchain fees (e.g. the original acceptor of the channel, as per=
"initiator pays" principle), then you have no disincentive to just use the=
highest-feerate version always, and have a tiny incentive to only store th=
e signature for the highest-feerate version to reduce your own storage cost=
s slightly.
You are incorrect. Lightning commitments actually come in two different
versions, for the local and remote sides. Obviously, I'm proposing that fee=
s be
taken from the side choosing to sign and broadcast the transaction. Which is
essentially no different from CPFP anchors, where the side choosing to get =
the
transaction mined pays the fee (though with anchors, it is easy for both si=
des
to choose to contribute, but in practice this almost never seems to happen =
in
my experience running LN nodes).
> In addition, it is also incentive-incompatible for the party that pays on=
chain fees to withhold signatures for the higher-fee versions, because if y=
ou are the party who does not pay fees and all you hold are the complete si=
gnatures for the lowest-fee version (because the counterparty does not want=
to trust you with signatures for higher-fee versions because you will just=
abuse it), then you will need anchor outputs again to bump up the fee.
That is also incorrect. If the protocol demands multiple fee variants exist,
the state of the lightning channel simply doesn't advance until all required
fee-variants are provided. Withholding can't happen any more than someone c=
ould
"withhold" a state by failing to provide the last byte of a commitment
transaction: until the protocol state requirements have been fufilled in fu=
ll,
the previous state remains in effect.
> However, there may be issues with hosting HTLCs; technically HTLCs are ne=
sted inside a larger contract (the channel) and if so, do you need a separa=
te transaction to resolve them (Poon-Dryja does!) and do you also have to m=
ulti-feerate *in addition to* multi-feerate the outer transaction (e.g. com=
mitment transaction in Poon-Dryja) resulting in a O(N * N) transactions for=
N feerates?
I covered HTLCs in my blog post on the subject; I would suggest you read it=
in
full. There are multiple potential options to deal with HTLC feerates to av=
oid
the obvious N^2 problem:
https://petertodd.org/2023/v3-transactions-review#htlcs-and-replace-by-fee
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--bmdDGprMOYGQ9Ewu
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmW4fUAACgkQLly11TVR
LzeTtg//WcISs4FshLbBh9dv2ypHpVqRUtPbkxdJHX/xfEZ8vdhaZSt13KS9rYoN
E359/g0xDiQVOGg/ZxXUIgHPU+hE7Zd/iRtAGoQ6O9VDkpHeSlT3UhLYcXMsUOuj
AqzfstvJj7MWtMLxlqgPG790Mh+/bO6HN+pxsNIFHBKjpxpHnDtmylJk+kpymkFR
hIJG1cnyBs7E6kTJDPipOEH8Br30dFoOe8/r26Oat6EcWyI9KFzCpolGUzNy06Re
n6VxqzlAeAxqhxQkIOxNFkBelYo9zrlQaQTpX154gFlaC5rvZNHCaxpNQfShRK9C
MqF5m3zmdbsrLRndyspYGgVsUpwCxU2+mQ+3uaVJrop8xOflmh3jX8LG0Ew0Euye
9HQbLvPHX9nk4ciEJM8OmOB5m7OZ7zb8LezVOa1EQEv9I/2N5bB8DS0Hvds1xtHW
YL2Lvft5oz2Tb3SqciSv/wQjHK77fPsJT3pzFeAt+X2T8ojTe0dTz30xMiYXaDDy
jvV76QzD+2ZwvMaujaEG+GEmEzU1Fr4FovULxRYq0eLOf+cl1pJYqHyTRZltO0Ia
UvwUheRTGlXwToeaJftzEboHB6jy2+A8Y0LtxDg6Y8ECr40aDQAETUIJ9/eLXDgY
W2aKAjbf9udoHI9Oi/fl7cUe4QOWfKsBgWGbGU0uuBMTPdAvN/E=
=lNr0
-----END PGP SIGNATURE-----
--bmdDGprMOYGQ9Ewu--
|
