📅 Original date posted:2021-07-06
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210706/d047ffd2/attachment.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 22:56:19
in reply to nevent1q…xwhn
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwPublished at
2023-06-07 22:56:19Event JSON
{
"id": "3123e5c8ce1b3d2ae707ddb07e598b9a0769134ffbe8924a535c73bcaf9ca147",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686178579,
"kind": 1,
"tags": [
[
"e",
"e305e1323b30b871a30d4051fe1bdd51042801c383eb2b02a7d24b80f15d4a24",
"",
"root"
],
[
"e",
"d0fcccca2947ad8dc9ffef477ea81b203bb2d5cff3b5dc9e3dd7770f5025ee0c",
"",
"reply"
],
[
"p",
"01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4"
]
],
"content": "📅 Original date posted:2021-07-06\n📝 Original message:If the main outstanding issue is whether to split R or S, I think as far as\nElements goes, I am inclined to go with the CAT option regardless of\nwhether Bitcoin chooses to split R/S or not (not that I'm necessarily a\ndecision maker here).\n\nThe issue here is that (a) Elements already has CAT, and (b) updating\nCHECKSIGFROMSTACK is effectively a blocking issue for deploying Taproot on\nElements. I don't think we will be holding up CHECKSIGFROMSTACK for this\nissue even if it risks being incompatible with an eventual Bitcoin\nCHECKSIGFROMSTACK.\n\nTo be clear, I don't mean to prejudice this discussion by this statement.\nThis just happens to be what makes sense for the Elements project at this\ntime, and what makes sense for Elements may not necessarily make sense for\nBitcoin.\n\nOf course, I think we should just go for CAT compatibility. Otherwise we\nare just going to have a proliferation of trusted CAT oracles paid for with\nlightning by people wanting to perform CAT operations.\n\nOn Tue, Jul 6, 2021 at 1:55 PM Jeremy via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Re-threading Sanket's comment on split R value:\n\u003e\n\u003e I also am in general support of the `OP_CHECKSIGFROMSTACK` opcode. We\n\u003e\u003e would need to update the suggestion to BIP340, and add it to sigops budget.\n\u003e\u003e I have no strong preference for splitting R and s values or variable-length\n\u003e\u003e messages.\n\u003e\u003e\n\u003e\n\u003e Back to my comment:\n\u003e\n\u003e\n\u003e I see a few options:\n\u003e\n\u003e 1) Making a new 64 byte PK standard which is (R, PK)\n\u003e 2) Splitting (R,S)\n\u003e 3) Different opcodes\n\u003e 4) CAT\n\u003e\n\u003e The drawback of option 1 is that it's designed to support only very\n\u003e specific use cases. The main drawback of splitting via option 2 is that you\n\u003e entail an extra push byte for every use. Option 3 wastes opcodes. CAT has\n\u003e the general drawbacks of CAT, but worth noting that CAT will likely\n\u003e eventually land making the splitting feature redundant.\n\u003e\n\u003e\n\u003e Before getting too in the weeds, it might be worth listing out interesting\n\u003e script fragments that people are aware of with split R/S so we can see how\n\u003e useful it might be?\n\u003e\n\u003e Use a specific R Value\n\u003e - \u003cS\u003e \u003cM\u003e || \u003cR\u003e SWAP \u003cPK\u003e CSFS\n\u003e\n\u003e Reuse arbitrary R for a specific M (pay to leak key)\n\u003e - \u003cR\u003e \u003cS1\u003e \u003cS2\u003e || DUP2 EQUAL NOT VERIFY 2 PICK SWAP \u003cM\u003e DUP TOALTSTACK\n\u003e CSFSV FROMALTSTACK CSFS\n\u003e\n\u003e Verify 2 different messages reuse the same R.\n\u003e - \u003cS1\u003e \u003cR\u003e \u003cM1\u003e \u003cS2\u003e \u003cM2\u003e || 2 PICK EQUAL NOT VERIFY 3 PICK \u003cPK\u003e DUP\n\u003e TOALTSTACK CSFSV FROMALTSTACK CSFS\n\u003e\n\u003e Use a R Value signed by an oracle:\n\u003e - \u003cS\u003e \u003cM\u003e \u003cS_oracle\u003e \u003cR_oracle\u003e \u003cR\u003e || DUP TOALTSTACK \u003cPK_oracle\u003e CSFSV\n\u003e FROMALTSTACK SWAP \u003cPK\u003e CSFS\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210706/d047ffd2/attachment.html\u003e",
"sig": "9f9c3d1148cc935a47e4e73e29c457c706beae30b855f2a44b482668e885f29913a51f0c1927d66517fb5ed614576166a8ff291a22b0dbb6321d615b688f78b3"
}