[bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

[Jeremy]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210706/b480247e/attachment.html>