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
|
Return-Path: <jlrubin@mit.edu>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7E020C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Sep 2021 03:17:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 57E2180F68
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Sep 2021 03:17:32 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id xj0hQpnaSmkT
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Sep 2021 03:17:31 +0000 (UTC)
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 smtp1.osuosl.org (Postfix) with ESMTPS id 3367F80F61
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Sep 2021 03:17:30 +0000 (UTC)
Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com
[209.85.208.172]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1863HSYl018911
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 5 Sep 2021 23:17:29 -0400
Received: by mail-lj1-f172.google.com with SMTP id w4so8887956ljh.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 05 Sep 2021 20:17:29 -0700 (PDT)
X-Gm-Message-State: AOAM530cSvY9Pa1TcBvb/czNoA1IJvgtjyXDf+VYJOUiPk/HpXMIYkTI
QE4eXZ4jGHHL1N8FTTHBnmhLkBcSd7tPoKTHRy0=
X-Google-Smtp-Source: ABdhPJwgzBJcjmWJ6DGSukUM4M4e43tw8rkLgWHInD/p6lXLlrJIe5I53+olBfWoeWQ55Fx6N+1d1VRtQI+eQOOegE8=
X-Received: by 2002:a2e:a7cf:: with SMTP id x15mr8891298ljp.227.1630898247907;
Sun, 05 Sep 2021 20:17:27 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhiKU1fuhqmKsx28f1nuw9CmvbyrS=BtM4X-L+WPgWY3Wg@mail.gmail.com>
<20210906023525.nui6beegrzopwfq4@ganymede>
In-Reply-To: <20210906023525.nui6beegrzopwfq4@ganymede>
From: Jeremy <jlrubin@mit.edu>
Date: Sun, 5 Sep 2021 20:17:17 -0700
X-Gmail-Original-Message-ID: <CAD5xwhh=oWtjumxn5cLJ3gs69wrhHvOTAD3gtywS8_kb7MLLqA@mail.gmail.com>
Message-ID: <CAD5xwhh=oWtjumxn5cLJ3gs69wrhHvOTAD3gtywS8_kb7MLLqA@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="000000000000bb418705cb4b1686"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Note on Sequence Lock Upgrades Defect
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, 06 Sep 2021 03:17:32 -0000
--000000000000bb418705cb4b1686
Content-Type: text/plain; charset="UTF-8"
BIP 68 says >= 2:
*This specification defines the meaning of sequence numbers for
transactions with an nVersion greater than or equal to 2 for which the rest
of this specification relies on.*
BIP-112 says not < 2
// Fail if the transaction's version number is not set high
// enough to trigger BIP 68 rules.
if (static_cast<uint32_t>(txTo->nVersion) < 2) return false;
A further proof that this needs fix: the flawed upgradable semantic exists
in script as well as in the transaction nSeqeunce. we can't really control
the transaction version an output will be spent with in the future, so it
would be weird/bad to change the semantic in transaction version 3.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Sun, Sep 5, 2021 at 7:36 PM David A. Harding <dave@dtrt.org> wrote:
> On Fri, Sep 03, 2021 at 08:32:19PM -0700, Jeremy via bitcoin-dev wrote:
> > Hi Bitcoin Devs,
> >
> > I recently noticed a flaw in the Sequence lock implementation with
> respect
> > to upgradability. It might be the case that this is protected against by
> > some transaction level policy (didn't see any in policy.cpp, but if not,
> > I've put up a blogpost explaining the defect and patching it
> > https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/
>
> Isn't this why BIP68 requires using tx.version=2? Wouldn't we just
> deploy any new nSequence rules with tx.version>2?
>
> -Dave
>
--000000000000bb418705cb4b1686
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">BIP 68 says >=
=3D 2:</div></div><i>This specification defines the meaning of sequence num=
bers for transactions with an nVersion greater than or equal to 2 for which=
the rest of this specification relies on.</i><div class=3D"gmail_default" =
style=3D"font-size:small"><font color=3D"#000000" face=3D"arial, helvetica,=
sans-serif"><span style=3D"caret-color: rgb(0, 0, 0);">BIP-112 says not &l=
t; 2</span></font></div><table class=3D"gmail-highlight gmail-tab-size gmai=
l-js-file-line-container" style=3D"box-sizing:border-box;border-spacing:0px=
;border-collapse:collapse;color:rgb(201,209,217);font-family:-apple-system,=
BlinkMacSystemFont,"Segoe UI Variable","Segoe UI",syste=
m-ui,ui-sans-serif,Helvetica,Arial,sans-serif,"Apple Color Emoji"=
,"Segoe UI Emoji";font-size:14px"><tbody style=3D"box-sizing:bord=
er-box"><tr style=3D"box-sizing:border-box"><td id=3D"gmail-LC1766" class=
=3D"gmail-blob-code gmail-blob-code-inner gmail-js-file-line" style=3D"box-=
sizing:border-box;padding:0px 10px;line-height:20px;vertical-align:top;over=
flow:visible;word-wrap:normal"><font color=3D"#000000">// Fail if the trans=
action's version number is not set high<br>// enough to trigger BIP 68 =
rules.<br>if (static_cast<uint32_t>(txTo->nVersion) < 2) return=
false;</font></td></tr></tbody></table><div class=3D"gmail_default" style=
=3D"font-size:small"><font color=3D"#000000" face=3D"arial, helvetica, sans=
-serif"><span style=3D"caret-color: rgb(0, 0, 0);"><br></span></font></div>=
<div class=3D"gmail_default" style=3D"font-size:small"><font color=3D"#0000=
00" face=3D"arial, helvetica, sans-serif"><span style=3D"caret-color: rgb(0=
, 0, 0);">A further proof that this needs fix: the flawed upgradable semant=
ic exists in script as well as in the transaction nSeqeunce. we can't r=
eally control the transaction version an output will be spent with in the f=
uture, so it would be weird/bad to change the semantic in transaction versi=
on 3.</span></font></div><div class=3D"gmail_default" style=3D"font-size:sm=
all"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-se=
rif"><br></span></div><div class=3D"gmail_default" style=3D"font-size:small=
"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif=
">--</span><br></div><div><div dir=3D"ltr" class=3D"gmail_signature" data-s=
martmail=3D"gmail_signature"><div dir=3D"ltr"><a href=3D"https://twitter.co=
m/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter=
.com/JeremyRubin" target=3D"_blank"></a></div></div></div><br></div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Sep 5=
, 2021 at 7:36 PM David A. Harding <<a href=3D"mailto:dave@dtrt.org">dav=
e@dtrt.org</a>> wrote:<br></div><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(204,204,204);padding-left:1ex">On Fri, Sep 03, 2021 a=
t 08:32:19PM -0700, Jeremy via bitcoin-dev wrote:<br>
> Hi Bitcoin Devs,<br>
> <br>
> I recently noticed a flaw in the Sequence lock implementation with res=
pect<br>
> to upgradability. It might be the case that this is protected against =
by<br>
> some transaction level policy (didn't see any in policy.cpp, but i=
f not,<br>
> I've put up a blogpost explaining the defect and patching it<br>
> <a href=3D"https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/" =
rel=3D"noreferrer" target=3D"_blank">https://rubin.io/bitcoin/2021/09/03/up=
gradable-nops-flaw/</a><br>
<br>
Isn't this why BIP68 requires using tx.version=3D2?=C2=A0 Wouldn't =
we just<br>
deploy any new nSequence rules with tx.version>2?<br>
<br>
-Dave<br>
</blockquote></div>
--000000000000bb418705cb4b1686--
|
