If the main outstanding issue is whether to split R or S, I think as far as Elements goes, I am inclined to go with the CAT option regardless of whether Bitcoin chooses to split R/S or not (not that I'm necessarily a decision maker here).

The issue here is that (a) Elements already has CAT, and (b) updating CHECKSIGFROMSTACK is effectively a blocking issue for deploying Taproot on Elements.  I don't think we will be holding up CHECKSIGFROMSTACK for this issue even if it risks being incompatible with an eventual Bitcoin CHECKSIGFROMSTACK.

To be clear, I don't mean to prejudice this discussion by this statement.  This just happens to be what makes sense for the Elements project at this time, and what makes sense for Elements may not necessarily make sense for Bitcoin.

Of course, I think we should just go for CAT compatibility.  Otherwise we are just going to have a proliferation of trusted CAT oracles paid for with lightning by people wanting to perform CAT operations.

On Tue, Jul 6, 2021 at 1:55 PM Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
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

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev