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
192
193
194
195
196
197
198
199
200
201
202
|
Return-Path: <dave@dtrt.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id D5B79C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 21 Oct 2023 09:08:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id B1C5B60B16
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 21 Oct 2023 09:08:21 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org B1C5B60B16
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 6RTnm7otBPLg
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 21 Oct 2023 09:08:17 +0000 (UTC)
Received: from smtpauth.rollernet.us (smtpauth.rollernet.us
[IPv6:2607:fe70:0:3::d])
by smtp3.osuosl.org (Postfix) with ESMTPS id AC7A661360
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 21 Oct 2023 09:08:17 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org AC7A661360
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
by smtpauth.rollernet.us (Postfix) with ESMTP id D6CA32801D10;
Sat, 21 Oct 2023 01:58:32 -0700 (PDT)
Received: from webmail.rollernet.us (webmail.rollernet.us
[IPv6:2607:fe70:0:14::a])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client did not present a certificate)
by smtpauth.rollernet.us (Postfix) with ESMTPSA;
Sat, 21 Oct 2023 01:58:32 -0700 (PDT)
MIME-Version: 1.0
Date: Fri, 20 Oct 2023 22:58:32 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Peter Todd <pete@petertodd.org>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <ZTMWrJ6DjxtslJBn@petertodd.org>
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
<ZTMWrJ6DjxtslJBn@petertodd.org>
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <d8227003b4a6065414d32a31a7020a93@dtrt.org>
X-Sender: dave@dtrt.org
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy:
http://www.rollernet.us/policy
X-Rollernet-Submit: Submit ID 7e27.653392b8.45ba1.0
Cc: "lightning-dev@lists.linuxfoundation.org"
<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making
HTLCs Safer by Letting Transactions Expire Safely
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: Sat, 21 Oct 2023 09:08:21 -0000
On 2023-10-20 14:09, Peter Todd via bitcoin-dev wrote:
> The basic problem here is after the HTLC-timeout path becomes
> spendable, the
> HTLC-preimage path remains spendable. That's bad, because in this case
> we want
> spending the HTLC-preimage - if possible - to have an urgency attached
> to it to
> ensure that it happens before the previous HTLC-timeout is mined.
>
> So, why can't we make the HTLC-preimage path expire?
If the goal is to ensure the HTLC-preimage should be mined before an
upstream HTLC-timeout becomes mineable, then I don't think a consensus
change is required. We can just make the HTLC-preimage claimable by
anyone some time after the HTLC-timeout becomes mineable.
For example, imagine that Alice offers Bob an HTLC with a timeout at
block t+200. Bob offers Carol an HTLC with a timeout at block t+100.
The Bob-Carol HTLC script looks like this:
If
# Does someone have the preimage?
Hash <digest> EqualVerify
If
# Carol has the preimage at any time
<Carol key> CheckSig
Else
# Anyone else has the preimage after t+150
<t+150> CLTV
EndIf
Else
# Bob is allowed a refund after t+100
<Bob key> CheckSigVerify
<t+100> CLTV
EndIf
In English:
- At any time, Carol can spend the output by releasing the preimage
- After t+100, Bob can spend the output
- After t+150, anyone with the preimage can spend the output
Let's consider this in the wider context of the forwarded payment
Alice->Bob->Carol:
- If Carol attempts to spend the output by releasing the preimage but
pays too low of a feerate to get it confirmed by block t+100, Bob can
spend the output in block t+101. He then has 99 blocks to settle
(revoke) the Alice-Bob HTLC offchain.
- If Carol releases the preimage to the network in general but prevents
Bob from using it (e.g. using a replacement cycling attack), anyone who
saw the preimage can take Carol's output at t+150 and, by doing so, will
put the preimage in the block chain where Bob will learn about it.
He'll then have 49 blocks to settle (revoke) the Alice-Bob HTLC
offchain.
- (All the normal cases when the HTLC is settled offchain, or where
onchain operations occur in a timely manner)
I think that adequately satisfies the concern about the effect on LN
from replacement cycling. Looking at potential complications:
- If all miners acted together[1], they are incentivized to not mine
Carol's preimage transaction before t+150 because its fees are less than
the HTLC value they can receive at t+150. I think this level of miner
centralization would result in a general failure for LN given that
miners could be any LN user's counterparty (or bribed by a user's
counterparty). E.g., stuff like this:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017997.html
- To allow anyone with the preimage to spend the output after t+150,
they need to know the script. For taproot, that means the t+150 tapleaf
script needs to follow a standard (e.g. a BOLT) and that any internal
merkle nodes needed to connect it to the taproot commitment need to be
shown in Carol's preimage transaction (or inferable from it or other
data).
- Classic RBF pinning of the t+150 transaction to prevent it from
confirming by block t+200 might be an issue. E.g., including it in a
400,000 weight low-feerate transaction.
- Full RBF might be required to ensure the t+150 transaction isn't sent
with a low feerate and no opt-in signal.
Deployment considerations:
- No changes are required to full nodes (no consensus change required)
- No changes are required to mining Bitcoin nodes[2]
- At least one well-connected Bitcoin relay node will need to be updated
to store preimages and related data, and to send the preimage claim
transactions. Data only needs to be kept for a rolling window of a few
thousand blocks for the LN case, bounding storage requirements. No
changes are required to other relaying Bitcoin nodes
- LN nodes will need to update to new HTLC scripts, but this should be
doable without closing/re-opening channels. Both anchor and non-anchor
channels can continue to be used
Compared to OP_EXPIRE:
- OP_EXPIRE requires consensus and policy changes; this does not
- OP_EXPIRE does not depend on special software; this depends on at
least one person running special software
Although this proposal is an alternative to Peter's proposal and is
primarily inspired by his idea, it's also a variation on a previous
suggestion of mine:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html
-Dave
[1] Perhaps under block censorship threat from a mining majority or a
sub-majority performing selfish mining.
[2] Although miners may want to consider running code that allows them
to rewrite any malleable transactions to pay themselve
|
