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
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
|
Return-Path: <jlrubin@mit.edu>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id E8B4FC000E;
Mon, 12 Jul 2021 22:07:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id C99354052E;
Mon, 12 Jul 2021 22:07:44 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
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 TxSqJZUomE59; Mon, 12 Jul 2021 22:07:43 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by smtp4.osuosl.org (Postfix) with ESMTPS id 6971740528;
Mon, 12 Jul 2021 22:07:43 +0000 (UTC)
Received: from mail-io1-f44.google.com (mail-io1-f44.google.com
[209.85.166.44]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16CM7eUd001564
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT);
Mon, 12 Jul 2021 18:07:41 -0400
Received: by mail-io1-f44.google.com with SMTP id y8so24620152iop.13;
Mon, 12 Jul 2021 15:07:41 -0700 (PDT)
X-Gm-Message-State: AOAM533dGf+1O9TUgyPtOvqAwondHcXTfaP1QR4GliNIyvVJKS/s9kMc
j0OwI4Bqf/B3SU/PaRPDiJNRyceupSa09OxoZ8Q=
X-Google-Smtp-Source: ABdhPJw5P2vpfjQ1uPtMoHix6M4sink9zZYUCeaweydSMIZYytLWDn0OYq8Szd3uHiPbsh/OA82IDLd2+39soHok0Pc=
X-Received: by 2002:a02:11c6:: with SMTP id 189mr1040151jaf.20.1626127660362;
Mon, 12 Jul 2021 15:07:40 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhgO5p2Ldy1P1rUuqDHcJ0opSe7Tg_mX_rb+ZpLOxa47cA@mail.gmail.com>
<20210708084416.GB1339@erisian.com.au>
<CAD5xwhjVod-Lu-gjU89znmVZnmL4UrL7xVuy=gZuuG6JG9X5yg@mail.gmail.com>
<20210712050115.GA6250@erisian.com.au>
In-Reply-To: <20210712050115.GA6250@erisian.com.au>
From: Jeremy <jlrubin@mit.edu>
Date: Mon, 12 Jul 2021 15:07:29 -0700
X-Gmail-Original-Message-ID: <CAD5xwhitb0g3-JPsn2tQF-KqgSp+goLnVbSmRX0LUh-818tSVw@mail.gmail.com>
Message-ID: <CAD5xwhitb0g3-JPsn2tQF-KqgSp+goLnVbSmRX0LUh-818tSVw@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="0000000000008e2f9405c6f459a4"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Eltoo / Anyprevout & Baked in
Sequences
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: Mon, 12 Jul 2021 22:07:45 -0000
--0000000000008e2f9405c6f459a4
Content-Type: text/plain; charset="UTF-8"
On Sun, Jul 11, 2021 at 10:01 PM Anthony Towns <aj@erisian.com.au> wrote:
> On Thu, Jul 08, 2021 at 08:48:14AM -0700, Jeremy wrote:
> > This would disallow using a relative locktime and an absolute
> locktime
> > for the same input. I don't think I've seen a use case for that so
> far,
> > but ruling it out seems suboptimal.
> > I think you meant disallowing a relative locktime and a sequence
> locktime? I
> > agree it is suboptimal.
>
> No? If you overload the nSequence for a per-input absolute locktime
> (well in the past for eltoo), then you can't reuse the same input's
> nSequence for a per-input relative locktime (ie CSV).
>
> Apparently I have thought of a use for it now -- cut-through of PTLC
> refunds when the timeout expires well after the channel settlement delay
> has passed. (You want a signature that's valid after a relative locktime
> of the delay and after the absolute timeout)
>
Ah -- I didn't mean a per input abs locktime, I mean the tx global
locktime.
I agree that at some point we should just separate all locktime types per
input so we get rid of all weirdness/overlap.
>
> > What do you make of sequence tagged keys?
>
> I think we want sequencing restrictions to be obvious from some (simple)
> combination of nlocktime/nsequence/annex so that you don't have to
> evaluate scripts/signatures in order to determine if a transaction
> is final.
>
> Perhaps there's a more general principle -- evaluating a script should
> only return one bit of info: "bool tx_is_invalid_script_failed"; every
> other bit of information -- how much is paid in fees (cf ethereum gas
> calculations), when the tx is final, if the tx is only valid in some
> chain fork, if other txs have to have already been mined / can't have
> been mined, who loses funds and who gets funds, etc... -- should already
> be obvious from a "simple" parsing of the tx.
>
> Cheers,
> aj
>
>
I don't think we have this property as is.
E.g. consider the transaction:
TX:
locktime: None
sequence: 100
scriptpubkey: 101 CSV
How will you tell it is able to be included without running the script?
I agree this is a useful property, but I don't think we can do it
practically.
What's nice is the transaction in this form cannot go from invalid to valid
-- once invalid it is always invalid for a given UTXO.
sequence tagged keys have this property -- a txn is either valid or invalid
and that never changes w/o any external information needing to be passed up.
--0000000000008e2f9405c6f459a4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><span st=
yle=3D"font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)">On Sun, =
Jul 11, 2021 at 10:01 PM Anthony Towns <<a href=3D"mailto:aj@erisian.com=
.au">aj@erisian.com.au</a>> wrote:</span><br></div></div><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(20=
4,204,204);padding-left:1ex">On Thu, Jul 08, 2021 at 08:48:14AM -0700, Jere=
my wrote:<br>
>=C2=A0 =C2=A0 =C2=A0This would disallow using a relative locktime and a=
n absolute locktime<br>
>=C2=A0 =C2=A0 =C2=A0for the same input. I don't think I've seen=
a use case for that so far,<br>
>=C2=A0 =C2=A0 =C2=A0but ruling it out seems suboptimal.<br>
> I think you meant disallowing a relative locktime and a sequence lockt=
ime? I<br>
> agree it is suboptimal.<br>
<br>
No? If you overload the nSequence for a per-input absolute locktime<br>
(well in the past for eltoo), then you can't reuse the same input's=
<br>
nSequence for a per-input relative locktime (ie CSV).<br>
<br>
Apparently I have thought of a use for it now -- cut-through of PTLC<br>
refunds when the timeout expires well after the channel settlement delay<br=
>
has passed. (You want a signature that's valid after a relative locktim=
e<br>
of the delay and after the absolute timeout)<br></blockquote><div><br></div=
><div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0)">Ah -- I didn't mean a per inp=
ut abs locktime, I mean the =C2=A0tx global locktime.</div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I agree t=
hat at some point we should just separate all locktime types per input so w=
e get rid of all weirdness/overlap.</div><br></div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-=
left:1ex">
<br>
> What do you make of sequence tagged keys?<br>
<br>
I think we want sequencing restrictions to be obvious from some (simple)<br=
>
combination of nlocktime/nsequence/annex so that you don't have to<br>
evaluate scripts/signatures in order to determine if a transaction<br>
is final.<br>
<br>
Perhaps there's a more general principle -- evaluating a script should<=
br>
only return one bit of info: "bool tx_is_invalid_script_failed"; =
every<br>
other bit of information -- how much is paid in fees (cf ethereum gas<br>
calculations), when the tx is final, if the tx is only valid in some<br>
chain fork, if other txs have to have already been mined / can't have<b=
r>
been mined, who loses funds and who gets funds, etc... -- should already<br=
>
be obvious from a "simple" parsing of the tx.<br>
<br>
Cheers,<br>
aj<br><br></blockquote><div><br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I=
don't think we have this property as is.</div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">E.g. consider the=
transaction:</div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)">TX:</div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">=C2=
=A0 =C2=A0locktime: None</div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">=C2=A0 =
=C2=A0sequence: 100</div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">=C2=A0 =C2=A0s=
criptpubkey: 101 CSV</div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)">How will you tell it is able to be include=
d without running the script?</div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br>=
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0)">I agree this is a useful property=
, but I don't think we can do it practically.</div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">What's ni=
ce is the transaction in this form cannot go from invalid to valid -- once =
invalid it is always invalid for a given UTXO.</div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">sequence tagged =
keys have this property -- a txn is either valid or invalid and that never =
changes w/o any external information needing to be passed up.</div></div></=
div>
--0000000000008e2f9405c6f459a4--
|
