Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9FA7AC000E for ; Sun, 4 Jul 2021 17:30:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 80ED14014F for ; Sun, 4 Jul 2021 17:30:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LadhqgIEgx-7 for ; Sun, 4 Jul 2021 17:30:32 +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 smtp2.osuosl.org (Postfix) with ESMTPS id 6488C400C4 for ; Sun, 4 Jul 2021 17:30:32 +0000 (UTC) Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 164HUU4F007586 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sun, 4 Jul 2021 13:30:30 -0400 Received: by mail-il1-f181.google.com with SMTP id g3so15106436ilj.7 for ; Sun, 04 Jul 2021 10:30:30 -0700 (PDT) X-Gm-Message-State: AOAM5314Th6ZiaxCzoNazysorjMM3lF2idLPdqflf4TDCtVktWVb79fY Xu+Z6uOy5zjakLlwjORr4OzqhFjZW2js2oTLU6Y= X-Google-Smtp-Source: ABdhPJxhNRD80l8LDPR7NkiiyR9tQP8+Ah4jrG7Xdgpp/+wqYq40cFnkfOgcHJlsUeXQGHsz7HGwzPGS9glIOowML1M= X-Received: by 2002:a92:3009:: with SMTP id x9mr7387976ile.49.1625419830173; Sun, 04 Jul 2021 10:30:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Sun, 4 Jul 2021 10:30:18 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "Russell O'Connor" Content-Type: multipart/alternative; boundary="00000000000096a79605c64f8b10" 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: Sun, 04 Jul 2021 17:30:33 -0000 --00000000000096a79605c64f8b10 Content-Type: text/plain; charset="UTF-8" I don't really see the point of CHECKSIGFROMSTACKADD since it's not bound to the txdata? When might you use this? And yes -- "Add OP_CHECKSIGFROMSTACK and OP_CHECKSIGFROMSTACKVERIFY to follow the semantics from bip340-342 when witness program is v1." is a bit light on detail for what the BIP would end up looking like. If you're able to open up the design process a bit more on that it would be good as I think there are some topics worth discussing at large before things proceed with Elements (assuming feature compatibility remains a goal). The non-prehashed argument seems OK (at the cost of an extra byte...) but are there specific applications for !=32 arguments? I can't think of a particular one beyond perhaps efficiency. Can we safely use 0-520 byte arguments? Also do you have thoughts on the other questions i posed above? E.g. splitting R/S could be helpful w/o CAT. -- @JeremyRubin On Sat, Jul 3, 2021 at 1:13 PM Russell O'Connor wrote: > There is one line written at > https://github.com/ElementsProject/elements/pull/949/files#r660130155. > --00000000000096a79605c64f8b10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't really see = the point of CHECKSIGFROMSTACKADD since it's not bound to the txdata? W= hen might you use this?

And yes -- "Add OP_CHECKSIGFROMSTACK an= d OP_CHECKSIGFROMSTACKVERIFY to follow the semantics from bip340-342 when w= itness program is v1." is a bit light on detail for what the BIP would= end up looking like. If you're able to open up the design process a bit more on that it would be good as= I think there are some topics worth discussing at large before things proc= eed with Elements (assuming feature compatibility remains a goal).

The non-prehashed=C2=A0argument seems OK (at the cost of an ex= tra byte...) but are there specific applications for !=3D32 arguments? I ca= n't think of a particular one beyond perhaps efficiency. Can we safely = use 0-520 byte arguments?

=
Also do you have thoughts on = the other questions i posed above? E.g. splitting R/S could be helpful w/o = CAT.

--
@JeremyRubin<= /div>


On Sat, Jul 3, 2021 at 1:13 PM Russell O'Connor &l= t;roconnor@blockstream.com> wrote:
=
--00000000000096a79605c64f8b10--