From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 07795C000E for ; 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 ; 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 ; 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 ; 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 ; Tue, 6 Jul 2021 14:53:44 -0400 Received: by mail-il1-f172.google.com with SMTP id e13so5392849ilc.1 for ; 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: In-Reply-To: From: Jeremy Date: Tue, 6 Jul 2021 11:53:32 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "Russell O'Connor" Content-Type: multipart/alternative; boundary="000000000000ee032b05c678f087" Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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 :)

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.
--000000000000ee032b05c678f087--