From: Jeremy <jlrubin@mit•edu>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin
Date: Tue, 6 Jul 2021 10:54:57 -0700 [thread overview]
Message-ID: <CAD5xwhhft7sKUS++LnS7-Fw37ovCioQWX3pV57JtTdDZ1MfzHg@mail.gmail.com> (raw)
In-Reply-To: <CAMZUoKmWqSnWhTUmTXRuAsrgd0KsQ+XjPw1s+XsZWARhsDcGsA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]
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
- <S> <M> || <R> SWAP <PK> CSFS
Reuse arbitrary R for a specific M (pay to leak key)
- <R> <S1> <S2> || DUP2 EQUAL NOT VERIFY 2 PICK SWAP <M> DUP TOALTSTACK
CSFSV FROMALTSTACK CSFS
Verify 2 different messages reuse the same R.
- <S1> <R> <M1> <S2> <M2> || 2 PICK EQUAL NOT VERIFY 3 PICK <PK> DUP
TOALTSTACK CSFSV FROMALTSTACK CSFS
Use a R Value signed by an oracle:
- <S> <M> <S_oracle> <R_oracle> <R> || DUP TOALTSTACK <PK_oracle> CSFSV
FROMALTSTACK SWAP <PK> CSFS
[-- Attachment #2: Type: text/html, Size: 4887 bytes --]
next prev parent reply other threads:[~2021-07-06 17:55 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-03 16:31 Jeremy
2021-07-03 17:50 ` Russell O'Connor
2021-07-03 18:30 ` Jeremy
2021-07-03 20:12 ` Russell O'Connor
2021-07-04 17:30 ` Jeremy
2021-07-04 19:03 ` Russell O'Connor
2021-07-06 17:54 ` Jeremy [this message]
2021-07-06 18:21 ` Russell O'Connor
2021-07-06 18:53 ` Jeremy
2021-07-04 1:13 ` David A. Harding
2021-07-04 18:39 ` Jeremy
2021-07-04 20:32 ` [bitcoin-dev] Unlimited covenants, was " David A. Harding
2021-07-04 20:50 ` Billy Tetrud
2021-07-05 0:50 ` ZmnSCPxj
2021-07-05 1:02 ` Russell O'Connor
2021-07-05 2:10 ` Russell O'Connor
2021-07-05 2:39 ` ZmnSCPxj
2021-07-05 5:04 ` Anthony Towns
2021-07-05 13:46 ` Matt Corallo
2021-07-05 13:51 ` Greg Sanders
2022-02-03 6:17 ` Anthony Towns
2021-07-05 17:20 ` Russell O'Connor
2021-07-06 6:25 ` Billy Tetrud
2021-07-06 10:20 ` Sanket Kanjalkar
2021-07-06 11:26 ` Russell O'Connor
2021-07-06 18:36 ` Jeremy
2021-07-07 4:26 ` ZmnSCPxj
2021-07-07 6:12 ` Billy Tetrud
2021-07-07 13:12 ` Russell O'Connor
2021-07-07 14:24 ` Russell O'Connor
2021-07-07 17:26 ` Jeremy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAD5xwhhft7sKUS++LnS7-Fw37ovCioQWX3pV57JtTdDZ1MfzHg@mail.gmail.com \
--to=jlrubin@mit$(echo .)edu \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox