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
|
Return-Path: <jlrubin@mit.edu>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 07795C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Jul 2021 18:53:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id EAB6A60869
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Jul 2021 18:53:46 +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 smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 93V3Zo1Wtk4O
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Jul 2021 18:53:46 +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 smtp3.osuosl.org (Postfix) with ESMTPS id 270ED60703
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Jul 2021 18:53:45 +0000 (UTC)
Received: from mail-il1-f172.google.com (mail-il1-f172.google.com
[209.85.166.172]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 166Irir4002232
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 6 Jul 2021 14:53:44 -0400
Received: by mail-il1-f172.google.com with SMTP id e13so5392849ilc.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 06 Jul 2021 11:53:44 -0700 (PDT)
X-Gm-Message-State: AOAM532/mNvGgAUu/3D60JXDfz5WAgJhMq6d8tqAJU0IcSY6vFNg/v/1
2ixyFNmwbVJBtPoZgrvgelkkhiRHoBee2GLJWFI=
X-Google-Smtp-Source: ABdhPJwzw8+76+GUk8gUIp72IgUv7czJOddUVt/ZoWQjlEHdaLJqLDAQ5dXbubdPZTE3QtlBhg68qpFNxdI33jWVzNI=
X-Received: by 2002:a92:6f0a:: with SMTP id k10mr15036641ilc.105.1625597624056;
Tue, 06 Jul 2021 11:53:44 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjmu-Eee47Ho5eA6E6+aAdnchLU0OVZo=RTHaXnN17x8A@mail.gmail.com>
<CAMZUoK=-jrH+fr=tUTHmLojm2-Ff99KYm9H97yhd=7bcOVG=fg@mail.gmail.com>
<CAD5xwhg0N1byx-G2tk=jjmZSHSBirpaX6OHTnh_x9iDEVF8PrQ@mail.gmail.com>
<CAMZUoKnYAKum63fRUNJD-zAZX_p3MoFULGWRE7J2QkO69nOe8g@mail.gmail.com>
<CAD5xwhgtsqAX99NJRU6t-s14aF7frGZxFCL3-c9iBOYrkN_A_w@mail.gmail.com>
<CAMZUoKmWqSnWhTUmTXRuAsrgd0KsQ+XjPw1s+XsZWARhsDcGsA@mail.gmail.com>
<CAD5xwhhft7sKUS++LnS7-Fw37ovCioQWX3pV57JtTdDZ1MfzHg@mail.gmail.com>
<CAMZUoKnhUoQGgpx_+keb_vpobKkaT2cbdZWib4oA+VytFwOsDA@mail.gmail.com>
In-Reply-To: <CAMZUoKnhUoQGgpx_+keb_vpobKkaT2cbdZWib4oA+VytFwOsDA@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Tue, 6 Jul 2021 11:53:32 -0700
X-Gmail-Original-Message-ID: <CAD5xwhgZwCgu-t2GK+s3VKSQrh9cywPqxoToSC8W9M7bkxZe0A@mail.gmail.com>
Message-ID: <CAD5xwhgZwCgu-t2GK+s3VKSQrh9cywPqxoToSC8W9M7bkxZe0A@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>
Content-Type: multipart/alternative; boundary="000000000000ee032b05c678f087"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin
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, 06 Jul 2021 18:53:47 -0000
--000000000000ee032b05c678f087
Content-Type: text/plain; charset="UTF-8"
I don't think Elements engineering decisions or management timelines should
have any bearing on what Bitcoin adopts, beyond learning what
works/doesn't. Same as litecoin, dogecoin, or bitcoin cash :)
With my understanding of elements it makes sense that you wouldn't want to
break compatibility script version to script version, although that seems
inevitable that you will need to either hard fork or break compatibility if
you want to fix the CHECKSIGFROMSTACK has verify semantics bug. But perhaps
that's a smaller change than the # of stack elements popped? It makes sense
having CAT that adding a split CSFS wouldn't be a priority. However, I'd
suggest that as far as elements is concerned, if the bitcoin community
decides on something that is incompatible, elements can use up some
addition opcodes or a keytype to add CSFS_BITCOIN_COMPAT ops.
--000000000000ee032b05c678f087
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)" class=3D"gmail_default">I don't think Elem=
ents engineering decisions or management timelines should have any bearing =
on what Bitcoin adopts, beyond learning what works/doesn't. Same as lit=
ecoin, dogecoin, or bitcoin cash :)<br></div><div style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_def=
ault"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)" class=3D"gmail_default"><div style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gm=
ail_default">With my understanding of elements it makes sense that you woul=
dn't want to break compatibility script version to script version, alth=
ough that seems inevitable that you will need to either hard fork or break =
compatibility if you want to fix the CHECKSIGFROMSTACK has verify semantics=
bug. But perhaps that's a smaller change than the # of stack elements =
popped? It makes sense having CAT that adding a split CSFS wouldn't be =
a priority. However, I'd suggest that as far as elements is concerned, =
if the bitcoin community decides on something that is incompatible, element=
s can use up some addition opcodes or a keytype to add CSFS_BITCOIN_COMPAT =
ops.<br></div></div></div>
--000000000000ee032b05c678f087--
|
