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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 309EBC0037
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jan 2024 05:07:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id F2E3960EDE
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jan 2024 05:07:39 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org F2E3960EDE
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=KXW3Vyyd
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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 5HkIwyRhCppC
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jan 2024 05:07:39 +0000 (UTC)
Received: from mail-0301.mail-europe.com (mail-0301.mail-europe.com
[188.165.51.139])
by smtp3.osuosl.org (Postfix) with ESMTPS id E531A60B2D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jan 2024 05:07:38 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E531A60B2D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1706591251; x=1706850451;
bh=jARzVZWqtZFjXAF01jXakri9oZQu1ktyI2rBW3x+izo=;
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=KXW3VyydG6U3iFevA8nfHBbbp3LW+cabJKSBne+HEoUGvuhjAmSqBe6e1wmhBNtYy
IikZ/yUr5KSyIn3wTCv1k5+LepNWDFWpFiTe7em5xgYVq+vmhmbdFe8BeLjC6Efnsm
QeLr1P9Ozq5K86TeJDBH6unBC+luVQSJ6CrRwcMrPxA2MiH1xsYj6CcMtz0XupvW6P
BCfqHBI7eEqhIWAGU1XWIH6qZN7u5eND6MeFWtyiOtznEfqYjnVWY8Yc1FcwRM6mJw
YGJmJggZB+DuIOPOr/fduDC7iUWa7qM4VFUohpzKWqMr0TWOOZUrHzPjKPb5Uurci8
U6E83o26DN5aQ==
Date: Tue, 30 Jan 2024 05:07:16 +0000
To: Peter Todd <pete@petertodd.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <FPf9XHCyxV96ABG154D8WapYmEE8XVFWqpQXBXz7p21xjdOk1Ho_lC4IpUznFbhleS7g_kKhUqsU0gtMT06_zo6B9heKyHfp1P1zfMWkjmA=@protonmail.com>
In-Reply-To: <Zbh9Qqk2jK0tqKgp@petertodd.org>
References: <ZbFle6n0Zu3yUV8o@petertodd.org>
<4619vs2aZBsW1lr3ihqjM6TdRgx8CuA_wRwXetu7jZZcL8r3oWUy7xOPkT-qJ0xxT79_Ss6it2chOWAAWPJuU8YSCzjaNOd6JvnMvWTBc-c=@protonmail.com>
<9tVZA3A4x-GZB5wQ1kMUoyyYXqvGS4MP4iDrLx1FCFHly-MU--II8evpgdcf2Xb9JZWDsY0kEB8r9dClzPrOk_V8EiWtHms8fvlunZQNGrA=@protonmail.com>
<Zbh9Qqk2jK0tqKgp@petertodd.org>
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 05:07:40 -0000
Sent with Proton Mail secure email.
On Tuesday, January 30th, 2024 at 4:38 AM, Peter Todd <pete@petertodd.org> =
wrote:
> On Tue, Jan 30, 2024 at 04:12:07AM +0000, ZmnSCPxj wrote:
>=20
> > 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 counterpar=
ty paying for onchain fees (e.g. the original acceptor of the channel, as p=
er "initiator pays" principle), then you have no disincentive to just use t=
he highest-feerate version always, and have a tiny incentive to only store =
the signature for the highest-feerate version to reduce your own storage co=
sts slightly.
>=20
>=20
> You are incorrect. Lightning commitments actually come in two different
> versions, for the local and remote sides. Obviously, I'm proposing that f=
ees 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 ge=
t the
> transaction mined pays the fee (though with anchors, it is easy for both =
sides
> to choose to contribute, but in practice this almost never seems to happe=
n in
> my experience running LN nodes).
There is a reason why I mention "initiator pays", and it is because the cha=
nnel opener really ought to pay for onchain fees in general.
For example, I could mount the following attack:
1. I already have an existing LN node on the network.
2. I wait for a low-feerate time.
3. I spin up a new node and initiate a channel funding to a victim node.
4. I empty my channel with the victim node, sending out my funds to my exi=
sting LN node.
5. I retire my new node forever.
This forces the victim node to use its commitment tx.
If the onchain fee for the commitment tx is paid for by who holds the commi=
tment tx (as in your proposal) then I have forced the victim node to pay an=
onchain fee.
This is why the initial design for openv1 is "initiator pays".
In the above attack scenario, the commitment tx held by the victim node, un=
der "initiator pays", has its onchain fee paid by me, thus the victim is no=
t forced to pay the unilateral close fee, I am the one forced to pay it.
They do still need to pay fees to get their now-onchain funds back into Lig=
htning, but at least more of the onchain fees (the fees to unilaterally clo=
se the channel with the now-dead node) is paid by the attacker.
On the other hand, it may be possible that "initiator pays" can be dropped.
In this attack scenario, the victim node should really require a non-zero r=
eserve anyway that is proportional to the channel size, so that the attacke=
r needs to commit some funds to the victim until the victim capitulates and=
unilaterally closes.
In addition, to repeat this attack, I need to keep opening channels to the =
victim and thus pay onchain fees for the channel open.
So it may be that your proposal is sound; possibly the "initiator pays" adv=
antage in this attack scenario is small enough that we can sacrifice it for=
multi-fee-version.
I should note that under Decker-Russell-Osuntokun the expectation is that b=
oth counterparties hold the same offchain transactions (hence why it is som=
etimes called "LN-symmetry").
However, there are two ways to get around this:
1. Split the fee between them in some "fair" way.
Definition of "fair" wen?
2. Create an artificial asymmetry: flip a bit of `nSequence` for the updat=
e+state txes of one counterparty, and have each side provide signatures for=
the tx held by its counterparty (as in Poon-Dryja).
This lets you force that the party that holds a particular update+state=
tx is the one that pays fees.
> > In addition, it is also incentive-incompatible for the party that pays =
onchain 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 =
signatures for the lowest-fee version (because the counterparty does not wa=
nt to trust you with signatures for higher-fee versions because you will ju=
st abuse it), then you will need anchor outputs again to bump up the fee.
>=20
>=20
> That is also incorrect. If the protocol demands multiple fee variants exi=
st,
> the state of the lightning channel simply doesn't advance until all requi=
red
> fee-variants are provided. Withholding can't happen any more than someone=
could
> "withhold" a state by failing to provide the last byte of a commitment
> transaction: until the protocol state requirements have been fufilled in =
full,
> the previous state remains in effect.
No, I am referring to a variation of your proposal where the side paying th=
e fees in "initiator pays" gets full signatures for all feerate-versions bu=
t the other side gets only the full signatures for the lowest-fee version.
If you can build the multi-version proposal with both sides contributing fe=
es or with the one exiting the channel paying the fee, then this variation =
is unnecessary and you can ignore this paragraph.
Regards,
ZmnSCPxj
|
