summaryrefslogtreecommitdiff
path: root/9f/7260bf4e8d7f4adc15dca23fd673d6279a2347
blob: 30e7c7ad74a74281bfe405bc09ebde9e71babfa9 (plain)
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
Return-Path: <jlrubin@mit.edu>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D8C40C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  4 Sep 2021 03:32:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id BD6D7426BD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  4 Sep 2021 03:32:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level: 
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5
 tests=[BAYES_05=-0.5, 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 smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id dPkf_Bf9JNOx
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  4 Sep 2021 03:32:33 +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 smtp4.osuosl.org (Postfix) with ESMTPS id 6FCB7426AF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  4 Sep 2021 03:32:33 +0000 (UTC)
Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com
 [209.85.167.46]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1843WUGx014969
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 3 Sep 2021 23:32:31 -0400
Received: by mail-lf1-f46.google.com with SMTP id f18so2068842lfk.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 03 Sep 2021 20:32:31 -0700 (PDT)
X-Gm-Message-State: AOAM530MH+MiDVklZmdiAptzfpeCgb79SM+7STRA0e5Cltv56XS9zZXu
 NA8EFsvw6fFQfukhBhEDDfn9Y6xJt5jI7Ocdy6Y=
X-Google-Smtp-Source: ABdhPJwI3wRaauUHFJf9PLKPf8+B7pkLGhtmV4+40hhN/9JXOzUDu352QE6Bble4bddXJ9MfZv0BcjSyiZkCDci/584=
X-Received: by 2002:a19:c7c3:: with SMTP id x186mr1492448lff.175.1630726350298; 
 Fri, 03 Sep 2021 20:32:30 -0700 (PDT)
MIME-Version: 1.0
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 3 Sep 2021 20:32:19 -0700
X-Gmail-Original-Message-ID: <CAD5xwhiKU1fuhqmKsx28f1nuw9CmvbyrS=BtM4X-L+WPgWY3Wg@mail.gmail.com>
Message-ID: <CAD5xwhiKU1fuhqmKsx28f1nuw9CmvbyrS=BtM4X-L+WPgWY3Wg@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000d5e2f205cb23109b"
Subject: [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: Sat, 04 Sep 2021 03:32:35 -0000

--000000000000d5e2f205cb23109b
Content-Type: text/plain; charset="UTF-8"

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/

I've proposed patching it here https://github.com/bitcoin/bitcoin/pull/22871,
it is proper to widely survey the community before patching to ensure no
one is depending on the current semantics in any live application lest this
tightening of standardness rules engender a confiscatory effect.

Best,

Jeremy

--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

--000000000000d5e2f205cb23109b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Hi Bitcoin Devs,</div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">I=
 recently noticed a flaw in the Sequence lock implementation with respect t=
o upgradability. It might be the case that this is protected against by som=
e transaction level policy (didn&#39;t see any in policy.cpp, but if not, I=
&#39;ve put up a blogpost=C2=A0explaining the defect and patching it=C2=A0<=
a href=3D"https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/">https:=
//rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/</a></div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:#000000">I&#39;ve prop=
osed patching it here=C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pu=
ll/22871">https://github.com/bitcoin/bitcoin/pull/22871</a>, it is proper t=
o widely survey the community before patching to ensure no one is depending=
 on the current semantics in any live application lest this tightening of s=
tandardness rules engender a confiscatory effect.</div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:#000000">Best,</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Jeremy<=
/div><br clear=3D"all"><div><div dir=3D"ltr" class=3D"gmail_signature" data=
-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://tw=
itter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https:/=
/twitter.com/JeremyRubin" target=3D"_blank"></a></div></div></div></div>

--000000000000d5e2f205cb23109b--