From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id D4770C000E for ; Tue, 6 Jul 2021 17:55:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id B5DD783906 for ; Tue, 6 Jul 2021 17:55:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZgl2TwOlHNn for ; Tue, 6 Jul 2021 17:55:12 +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 smtp1.osuosl.org (Postfix) with ESMTPS id DEA07838FB for ; Tue, 6 Jul 2021 17:55:11 +0000 (UTC) Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 166Ht9Pn011995 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 6 Jul 2021 13:55:10 -0400 Received: by mail-io1-f42.google.com with SMTP id k16so26083979ios.10 for ; Tue, 06 Jul 2021 10:55:10 -0700 (PDT) X-Gm-Message-State: AOAM533ZN8GWnon5yUkWCvCisHF8GMynGvK8dnZMWWbAnC98GfLsM4Ro 7F2y8X9u5VhWT82DvCXI3hZxJFtHOMt+YV0lLRU= X-Google-Smtp-Source: ABdhPJyF4ECZw1glBhoa/5PBhOJvkgihy8+SGpqI3LfjmhEGk2diu9IYU4mbVOnTyzK07mrLsoC6VWhvKiArUal+Tns= X-Received: by 2002:a05:6638:1ba:: with SMTP id b26mr3816551jaq.20.1625594109515; Tue, 06 Jul 2021 10:55:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Tue, 6 Jul 2021 10:54:57 -0700 X-Gmail-Original-Message-ID: Message-ID: Cc: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000725b9c05c6781f5a" 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 17:55:12 -0000 --000000000000725b9c05c6781f5a Content-Type: text/plain; charset="UTF-8" Re-threading Sanket's comment on split R value: I also am in general support of the `OP_CHECKSIGFROMSTACK` opcode. We would > need to update the suggestion to BIP340, and add it to sigops budget. I > have no strong preference for splitting R and s values or variable-length > messages. > Back to my comment: I see a few options: 1) Making a new 64 byte PK standard which is (R, PK) 2) Splitting (R,S) 3) Different opcodes 4) CAT The drawback of option 1 is that it's designed to support only very specific use cases. The main drawback of splitting via option 2 is that you entail an extra push byte for every use. Option 3 wastes opcodes. CAT has the general drawbacks of CAT, but worth noting that CAT will likely eventually land making the splitting feature redundant. Before getting too in the weeds, it might be worth listing out interesting script fragments that people are aware of with split R/S so we can see how useful it might be? Use a specific R Value - || SWAP CSFS Reuse arbitrary R for a specific M (pay to leak key) - || DUP2 EQUAL NOT VERIFY 2 PICK SWAP DUP TOALTSTACK CSFSV FROMALTSTACK CSFS Verify 2 different messages reuse the same R. - || 2 PICK EQUAL NOT VERIFY 3 PICK DUP TOALTSTACK CSFSV FROMALTSTACK CSFS Use a R Value signed by an oracle: - || DUP TOALTSTACK CSFSV FROMALTSTACK SWAP CSFS --000000000000725b9c05c6781f5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Re-threa= ding Sanket's comment on split R value:

I also am in general support of=C2=A0the `OP_CHECK= SIGFROMSTACK` opcode. We=20 would need to update the suggestion to BIP340, and add it to sigops=20 budget. I have no strong preference for splitting R and s values or=20 variable-length messages.=C2=A0

Back to my comment:

=C2= =A0
I see a few options:=

1) Making a new 64 byte PK standard which is (R, PK)
2) Splitting (R,S)
3) Different opcodes
4) CAT

The drawback of option 1 is that it's desi= gned to support only very specific use cases. The main drawback of splittin= g via option 2 is that you entail an extra push byte for every use. Option = 3 wastes opcodes. CAT has the general drawbacks of CAT, but worth noting th= at CAT will likely eventually land making the splitting feature redundant.<= /div>


Before getting to= o in the weeds, it might be worth listing out interesting script fragments = that people are aware of with split R/S so we can see how useful it might b= e?

Use a specific R Value
- <S> <M> || <R> SWAP <PK> CSFS

Reuse arbitrary R for a specific M (pay to leak key)
-=C2=A0 <R> <S1> <S2>=C2=A0 ||= =C2=A0 DUP2 EQUAL NOT VERIFY 2 PICK SWAP <M> DUP TOALTSTACK CSFSV FRO= MALTSTACK CSFS

Verify 2 different messages reuse the same R= .
- <S1> <R> <M= 1> <S2> <M2> ||=C2=A0 2 PICK EQUAL NOT VERIFY 3 PICK <PK&= gt; DUP TOALTSTACK CSFSV FROMALTSTACK CSFS

Use a R Value signed= by an oracle:
- <S> <M&g= t; <S_oracle> <R_oracle> <R> || DUP TOALTSTACK <PK_ora= cle> CSFSV FROMALTSTACK SWAP <PK> CSFS

--000000000000725b9c05c6781f5a--