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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id CA0F9C0037
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jan 2024 04:12:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 8C12D417F8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jan 2024 04:12:33 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8C12D417F8
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=bvhBiDN8
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 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,
FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=unavailable 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 TQQnuEDpaQbQ
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jan 2024 04:12:32 +0000 (UTC)
Received: from mail-0201.mail-europe.com (mail-0201.mail-europe.com
[51.77.79.158])
by smtp4.osuosl.org (Postfix) with ESMTPS id AB34A41795
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jan 2024 04:12:32 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org AB34A41795
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1706587944; x=1706847144;
bh=CvE06e12BjIkt/XKkr5ICljPz1z2Sp+yHmGa/WofCsA=;
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=bvhBiDN8YgI37T1eKhoGjTiXaXLtbFB90B4x4aj360XspLgww3+of7RDMZx+wKXAV
6J/OEos6zH4Hfnm9xsdNAI+ehrEOYtABG+6XsgsqmjWhzIlL1TVZDkMhxXUNFhsHfc
tp2sVURvwfoO96LYngpYG3TrqTBaZuJdIa6npGSmfUhpZb/+2ESV8AzPS65zgwpBYo
4hjkKZVu6gTUS4istJ78IGDkEj1ippBKOJsQ0uwcmNLfXi8ayJbuFYuzcNLBIdK4K7
+zeAks4HZL1DXlFET71kiaO4O4Z2moeJLyglqKVo6c2gThCiq+3PedFlvBpr3QbLM2
YNluxvDL4PFCQ==
Date: Tue, 30 Jan 2024 04:12:07 +0000
To: Michael Folkson <michaelfolkson@protonmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <9tVZA3A4x-GZB5wQ1kMUoyyYXqvGS4MP4iDrLx1FCFHly-MU--II8evpgdcf2Xb9JZWDsY0kEB8r9dClzPrOk_V8EiWtHms8fvlunZQNGrA=@protonmail.com>
In-Reply-To: <4619vs2aZBsW1lr3ihqjM6TdRgx8CuA_wRwXetu7jZZcL8r3oWUy7xOPkT-qJ0xxT79_Ss6it2chOWAAWPJuU8YSCzjaNOd6JvnMvWTBc-c=@protonmail.com>
References: <ZbFle6n0Zu3yUV8o@petertodd.org>
<4619vs2aZBsW1lr3ihqjM6TdRgx8CuA_wRwXetu7jZZcL8r3oWUy7xOPkT-qJ0xxT79_Ss6it2chOWAAWPJuU8YSCzjaNOd6JvnMvWTBc-c=@protonmail.com>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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:12:34 -0000
Good morning Michael et al,
>=20
> I assume that a CTV based LN-Symmetry also has this drawback when compare=
d to an APO based LN-Symmetry? In theory at least an APO based LN-Symmetry =
could change the fees in every channel update based on what the current mar=
ket fee rate was at the time of the update. In today's pre LN-Symmetry worl=
d you are always going to have justice transactions for revoked states that=
were constructed when the market fee rate was very different from the pres=
ent day's market fee rate.
This is the same in the future Decker-Russell-Osuntokun ("eltoo" / "LN-Symm=
etry") world as in the current Poon-Dryja ("LN-punishment").
Every *commitment* transaction in Poon-Dryja commits to a specific fee rate=
, which is why it it problematic today.
The *justice* transaction is single-signed and can (and SHOULD!) be RBF-ed =
(e.g. CLN implements an aggressive *justice* transaction RBF-ing written by=
me).
However, the issue is that every *commitment* transaction commits to a spec=
ific feerate today, and if the counterparty is offline for some time, the m=
arket feerate may diverge tremendously from the last signed feerate.
The same issue will still exist in Decker-Russell-Osuntokun --- the latest =
pair of update and state transactions will commit to a specific feerate.
If the counterparty is offline for some time, the market feerate may diverg=
e tremendously from the last signed feerate.
Anchor commitments Fixes This by adding an otherwise-unnecessary change out=
put (called "anchor output") for both parties to be able to attach a CPFP t=
ransaction.
However, this comes at the expense of increased blockspace usage for the an=
chor outputs.
Peter Todd proposes to sign multiple versions of offchain transactions at v=
arying feerates.
However, this proposal has the issue that if you are not the counterparty p=
aying 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 h=
ighest-feerate version always, and have a tiny incentive to only store the =
signature for the highest-feerate version to reduce your own storage costs =
slightly.
In addition, it is also incentive-incompatible for the party that pays onch=
ain fees to withhold signatures for the higher-fee versions, because if you=
are the party who does not pay fees and all you hold are the complete sign=
atures for the lowest-fee version (because the counterparty does not want t=
o trust you with signatures for higher-fee versions because you will just a=
buse it), then you will need anchor outputs again to bump up the fee.
The proposal from Peter Todd might work if both parties share the burden fo=
r paying the fees.
However, this may require that both parties always bring in funds on all ch=
annel opens, i.e. no single-sided funding.
I have also not considered how this game would play out, though naively, it=
seems to me that if both parties pay onchain fees "fairly" for some defini=
tion of "fair" (how to define "fair" may be problematic --- do they pay equ=
al fees or proportional to their total funds held in the channel?) then it =
seems to me okay to have multi-feerate-version offchain txes (regardless of=
using Poon-Dryja or Decker-Russell-Osuntokun).
However, there may be issues with hosting HTLCs; technically HTLCs are nest=
ed inside a larger contract (the channel) and if so, do you need a separate=
transaction to resolve them (Poon-Dryja does!) and do you also have to mul=
ti-feerate *in addition to* multi-feerate the outer transaction (e.g. commi=
tment transaction in Poon-Dryja) resulting in a O(N * N) transactions for N=
feerates?
Regards,
ZmnSCPxj
|
