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
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
Precedence: list

--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&#39;t think Elem=
ents engineering decisions or management timelines should have any bearing =
on what Bitcoin adopts, beyond learning what works/doesn&#39;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&#39;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&#39;s a smaller change than the # of stack elements =
popped? It makes sense having CAT that adding a split CSFS wouldn&#39;t be =
a priority. However, I&#39;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--