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

[Jeremy via bitcoin-dev]

I don't think Elements engineering decisions or management timelines should
have any bearing on what Bitcoin adopts, beyond learning what
works/doesn't. Same as litecoin, dogecoin, or bitcoin cash :)

With my understanding of elements it makes sense that you wouldn't want to
break compatibility script version to script version, although that seems
inevitable that you will need to either hard fork or break compatibility if
you want to fix the CHECKSIGFROMSTACK has verify semantics bug. But perhaps
that's a smaller change than the # of stack elements popped? It makes sense
having CAT that adding a split CSFS wouldn't be a priority. However, I'd
suggest that as far as elements is concerned, if the bitcoin community
decides on something that is incompatible, elements can use up some
addition opcodes or a keytype to add CSFS_BITCOIN_COMPAT ops.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Russell O'Connor via bitcoin-dev]

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
> -   ||  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
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jeremy via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Russell O'Connor via bitcoin-dev]

On Sun, Jul 4, 2021 at 1:30 PM Jeremy  wrote:

> I don't really see the point of CHECKSIGFROMSTACKADD since it's not bound
> to the txdata? When might you use this?
>

I don't feel strongly about *ADD.  I just figured it might be useful to do
a 2-of-3 between Alice, Bob and an Oracle signed value.  But I don't have
any particular use case in mind.  Either way the *ADD functionality can be
replicated by various SWAPs and ADDs etc, so we could just leave it out
until it is wanted.


> And yes -- "Add OP_CHECKSIGFROMSTACK and OP_CHECKSIGFROMSTACKVERIFY to
> follow the semantics from bip340-342 when witness program is v1." is a bit
> light on detail for what the BIP would end up looking like. If you're able
> to open up the design process a bit more on that it would be good as I
> think there are some topics worth discussing at large before things proceed
> with Elements (assuming feature compatibility remains a goal).
>

I'm certainly open to a wider design process.  We can open a specific issue
on the Elements repo.  That said, I don't see a particularly wide design
space on this front.


> The non-prehashed argument seems OK (at the cost of an extra byte...) but
> are there specific applications for !=32 arguments? I can't think of a
> particular one beyond perhaps efficiency. Can we safely use 0-520 byte
> arguments?
>

One of the reasons given in the issue (yes, the thread there is very long)
was that hashing the message requires the hash to be collision resistant
while if you give the message directly it only requires the hash to be
"random-prefix" collision / preimage resistant.  For example SHA-1 is
clearly not collision resistant but it appears to still be random-prefix
collision resistant AFAIU.  Another reason is that it allows for extremely
fast signing oracles because and R value and the midstate of the hash can
be precomputed all the way upto the application prefix, and if the message
being signed is less than 55 bytes or so, the signing cost can be as low as
one compression function and a little bit of non-EC modular arithmetic to
compute S.  If the message were required to be prehashed, then it would
take a minimum of 2 compression function calls to sign, nearly doubling the
signing time needed for the fast oracle.

Even if BIP-0340 kept its requirements that the message be exactly 32
bytes, I would still be inclined to design CHECKSIGFROMSTACK for tapscript
to take the 32-byte message from the stack instead of hashing a message
itself (BIP-0340 does it's own hashing, so prehashing the message isn't a
security concern in the same way it is for ECDSA.)  This would keep the
message off the blockchain, saving space and adding some amount of privacy
and making the operation compatible with rolling SHA256 opcodes.  But given
that BIP-0340 is going to be extended to support non-32 byte messages, then
there is no reason to impose a message length restriction on
CHECKSIGFROMSTACK.  Yes the operation will still be subject to stack item
length restrictions.  This is something script writers will have to be
aware of, but I see little reason to support messages split across multiple
stack items when we expect, by far, most messages to be 32-bytes, and I
expect those rare non-32 byte messages are expected to be reasonably short.


> Also do you have thoughts on the other questions i posed above? E.g.
> splitting R/S could be helpful w/o CAT.
>

Regarding  internal pubkeys and invalid pubkeys, I see no reason to deviate
from whatever tapscript CHECKSIG* do.

Regarding splitting R/S, This is harder because Elements does have CAT and
I think we should add CAT to Bitcoin too.  This game of trying to prevent
covenants by restricting script to the point where we are not even allowed
to have a CAT operation is a losing game.  It's just a matter of time
before we accidently introduce some way to enable covenants anyways, and it
is not worth cutting off vast amounts of functionality in pursuit of this
questionable goal.  And I say this as someone who was originally of the
opinion that we should be very very cautious before enabling new
expressivity such as covenants.  All the scary scenarios of covenants that
I am aware of can be more easily, cheaply, and flexibility implemented by
just having a counterparty in a multi-party signature that enforces their
own policy that they only sign transactions that pay to outputs that they
remain a party to.  And even if scary covenants were scarier than what can
already be done by multisig and policy, I still don't think they are scary
enough to warrant keeping CAT disabled.

So I don't think we should get fancy with CHECKSIGFROMSTACK.  Just take a
normal 64-byte signature value as a stack item.  But I don't feel strongly
about this, and I wouldn't oppose splitting R and S in Bitcoin if that is
where consensus lies.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org

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

[Jeremy via bitcoin-dev]

>
> Do you have concerns about sophisticated covenants, and if so, would you
> mind describing them?


Personally, not in particular worried about arbitrary covenants as I think
that: 1 validation costs can be kept in check; 2 you're free to burn your
coins it you want to.

I *do* care that when we enable covenants we don't make people jump through
too many hoops, but I also respect Russel's points that we can enable
functionality and then later figure out how to make it more efficient or
useful guided by use cases.


However, I think the broader community is unconvinced by the cost benefit
of arbitrary covenants. See
https://medium.com/block-digest-mempool/my-worries-about-too-generalized-covenants-5eff33affbb6
as a recent example. Therefore as a critical part of building consensus on
various techniques I've worked to emphasize that specific additions do not
entail risk of accidentally introducing more than was bargained for to
respect the concerns of others.


>
> I'm a fan of CSFS, even mentioning it on zndtoshi's recent survey[2],
> but it seems artificially limited without OP_CAT.  (I also stand by my
> answer on that survey of believing there's a deep lack of developer
> interest in CSFS at the moment.  But, if you'd like to tilt at that
> windmill, I won't stop you.)


Well if you're a fan of it, I'm a fan of it, Russel's a fan of it, and
Sanket's a fan of it that sounds like a good amount of dev interest :) I
know Olaoluwa is also a fan of it too and has some cool L2 protocols using
it.

I think it might not be *hype* because it's been around a while and has
always been bundled with cat so been a non starter for the reasons above. I
think as an independent non-bundle it's exciting and acceptable to a number
of devs. I also believe upgrades can be developed and tracked in parallel
so I'm taking on the windmill tilting personally to spearhead that -- on
the shoulders of Giants who have been creating specs for this already of
course.

Best,

Jeremy

P.s. icymi https://rubin.io/blog/2021/07/02/covenants/ covers my current
thinking about how to proceed w.r.t. deploying and developing covenant
systems for bitcoin
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jeremy via bitcoin-dev]

I don't really see the point of CHECKSIGFROMSTACKADD since it's not bound
to the txdata? When might you use this?

And yes -- "Add OP_CHECKSIGFROMSTACK and OP_CHECKSIGFROMSTACKVERIFY to
follow the semantics from bip340-342 when witness program is v1." is a bit
light on detail for what the BIP would end up looking like. If you're able
to open up the design process a bit more on that it would be good as I
think there are some topics worth discussing at large before things proceed
with Elements (assuming feature compatibility remains a goal).

The non-prehashed argument seems OK (at the cost of an extra byte...) but
are there specific applications for !=32 arguments? I can't think of a
particular one beyond perhaps efficiency. Can we safely use 0-520 byte
arguments?

Also do you have thoughts on the other questions i posed above? E.g.
splitting R/S could be helpful w/o CAT.

--
@JeremyRubin 



On Sat, Jul 3, 2021 at 1:13 PM Russell O'Connor 
wrote:

> There is one line written at
> https://github.com/ElementsProject/elements/pull/949/files#r660130155.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David A. Harding via bitcoin-dev]

On Sat, Jul 03, 2021 at 09:31:57AM -0700, Jeremy via bitcoin-dev wrote:
> Note that with *just* CheckSigFromStack, while you can do some very
> valuable use cases, but without OP_CAT it does not enable sophisticated
> covenants

Do you have concerns about sophisticated covenants, and if so, would you
mind describing them?  Your BIP119 CTV also mentions[1] being designed
to avoid sophisticated covenants.  If this is some sort of design
principle, I'd like to understand the logic behind it.

I'm a fan of CSFS, even mentioning it on zndtoshi's recent survey[2],
but it seems artificially limited without OP_CAT.  (I also stand by my
answer on that survey of believing there's a deep lack of developer
interest in CSFS at the moment.  But, if you'd like to tilt at that
windmill, I won't stop you.)

-Dave

[1] 
https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#design-tradeoffs-and-risks

[2] https://twitter.com/zndtoshi/status/1405235814712422402



signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Russell O'Connor via bitcoin-dev]

There is one line written at
https://github.com/ElementsProject/elements/pull/949/files#r660130155. I
suppose we need to decide on which variants of *VERIFY and *ADD we want to
include (presumably all of them) and choose which opcodes they will be
assigned to.  And I guess for CHECKSIGFROMSTACKADD will want to place the n
value between the signature and the message on the stack.  ... So I suppose
we will need more than one sentence.

The semantics would be basically to call secp256k1_schnorrsig_verify <
https://github.com/bitcoin-core/secp256k1/blob/0440945fb5ce69d335fed32827b5166e84b02e05/include/secp256k1_schnorrsig.h#L158>,
treating pubkeys and signatures the same way the other CHECKSIG operations
do, and in passing the (variable length) message from the stack.
CHECKSIGFROMSTACK would also be subject to the same sigops budget that
CHECKSIG has in tapscript.

On Sat, Jul 3, 2021 at 2:30 PM Jeremy  wrote:

> Awesome to hear that!
>
> Actually I don't think I did know (or I forgot/didn't catch it) that there
> was an updated spec for elements, I searched around for what I could find
> and came up empty handed. Do you have any links for that? That sounds
> perfect to me.
>
>
> On Sat, Jul 3, 2021, 10:50 AM Russell O'Connor 
> wrote:
>
>> Hi Jermy,
>>
>> As you are aware, we, and by we I mean mostly Sanket, are developing an
>> updated OP_CHECKSIGFROMSTACK implementation for tapscript on elements.  The
>> plan here would be to effectively support the an interface to the
>> variable-length extension of BIP-0340 schnorr signatures.
>>
>> BIP-0340 would dispense with DER encoding (good riddance).
>> BIP-0340 signatures are batch verifiable along with other BIP-0340
>> transaction signatures and taproot tweak verification.
>> Support for variable length messages in BIP-0340 has been discussed in <
>> https://github.com/sipa/bips/issues/207> and an implementation has
>> recently been merged in <
>> https://github.com/bitcoin-core/secp256k1/pull/844>.  The BIP has not
>> yet been updated but the difference is that the message m does not have to
>> be 32-bytes (it is recommended that the message be a 32-bit tagged hash or
>> a message with a 64-bit application specific prefix). The CHECKSIGFROMSTACK
>> operation (in tapscript) would use a stack item for this m value to
>> BIP-0340 signature verification and would not necessarily have to be 32
>> bytes.
>>
>> I think this design we are aiming for would be perfectly suited for
>> Bitcoin as well.
>>
>> On Sat, Jul 3, 2021 at 12:32 PM Jeremy via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Reproduced below is the BIP text from Bitcoin Cash's (MIT-Licensed)
>>> specification for "CheckDataSig", more or less the same thing as
>>> CHECKSIGFROMSTACK
>>> https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_checkdatasig.md.
>>> In contrast to Element's implementation, it does not have Element's bugs
>>> around verify semantics and uses the nullfail rule, and there is a
>>> specification document so it seemed like the easiest starting point for
>>> discussion v.s. drafting something from scratch.
>>>
>>> Does anyone have any issue with adapting this exact text and
>>> implementation to a BIP for Bitcoin using 2 OP_SUCCESSX opcodes?
>>>
>>> Note that with *just* CheckSigFromStack, while you can do some very
>>> valuable use cases, but without OP_CAT it does not enable sophisticated
>>> covenants (and as per
>>> https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html
>>> just CAT alone enables such uses).
>>>
>>> Design questions worth considering as modifications:
>>>
>>> 1. Should CSFS require some sort of tagged hash? Very likely answer is
>>> no – tags interfere with certain use cases
>>> 2. Should CSFS split the signature’s R & S value stack items for some
>>> applications that otherwise may require OP_CAT? E.g. using a pinned R value
>>> allows you to extract a private key if ever double signed, using 2 R values
>>> allows pay-to-reveal-key contracts. Most likely answer is no, if that is
>>> desired then OP_CAT can be introduced
>>> 3. Should CSFS support a cheap way to reference the taproot internal or
>>> external key? Perhaps, can be handled with undefined upgradeable keytypes.
>>> One might want to use the internal key, if the signed data should be valid
>>> independent of the tapscript tree. One might want to use the external key,
>>> if the data should only be valid for a single tapscript key + tree.
>>> 4. Should invalid public keys types be a NOP to support future extended
>>> pubkey types?
>>>
>>>
>>>
>>> Best,
>>>
>>>
>>> Jeremy
>>>
>>>
>>> ---
>>> layout: specification
>>> title: OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY Specification
>>> category: spec
>>> date: 2018-08-20
>>> activation: 154230
>>> version: 0.6
>>> ---
>>>
>>> OP_CHECKDATASIG
>>> ===
>>>
>>> OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY check whether a signature is 
>>> valid with respect to a message and a public key.
>>>

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

[Jeremy via bitcoin-dev]

Awesome to hear that!

Actually I don't think I did know (or I forgot/didn't catch it) that there
was an updated spec for elements, I searched around for what I could find
and came up empty handed. Do you have any links for that? That sounds
perfect to me.


On Sat, Jul 3, 2021, 10:50 AM Russell O'Connor 
wrote:

> Hi Jermy,
>
> As you are aware, we, and by we I mean mostly Sanket, are developing an
> updated OP_CHECKSIGFROMSTACK implementation for tapscript on elements.  The
> plan here would be to effectively support the an interface to the
> variable-length extension of BIP-0340 schnorr signatures.
>
> BIP-0340 would dispense with DER encoding (good riddance).
> BIP-0340 signatures are batch verifiable along with other BIP-0340
> transaction signatures and taproot tweak verification.
> Support for variable length messages in BIP-0340 has been discussed in <
> https://github.com/sipa/bips/issues/207> and an implementation has
> recently been merged in <
> https://github.com/bitcoin-core/secp256k1/pull/844>.  The BIP has not yet
> been updated but the difference is that the message m does not have to be
> 32-bytes (it is recommended that the message be a 32-bit tagged hash or a
> message with a 64-bit application specific prefix). The CHECKSIGFROMSTACK
> operation (in tapscript) would use a stack item for this m value to
> BIP-0340 signature verification and would not necessarily have to be 32
> bytes.
>
> I think this design we are aiming for would be perfectly suited for
> Bitcoin as well.
>
> On Sat, Jul 3, 2021 at 12:32 PM Jeremy via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Reproduced below is the BIP text from Bitcoin Cash's (MIT-Licensed)
>> specification for "CheckDataSig", more or less the same thing as
>> CHECKSIGFROMSTACK
>> https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_checkdatasig.md.
>> In contrast to Element's implementation, it does not have Element's bugs
>> around verify semantics and uses the nullfail rule, and there is a
>> specification document so it seemed like the easiest starting point for
>> discussion v.s. drafting something from scratch.
>>
>> Does anyone have any issue with adapting this exact text and
>> implementation to a BIP for Bitcoin using 2 OP_SUCCESSX opcodes?
>>
>> Note that with *just* CheckSigFromStack, while you can do some very
>> valuable use cases, but without OP_CAT it does not enable sophisticated
>> covenants (and as per
>> https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html
>> just CAT alone enables such uses).
>>
>> Design questions worth considering as modifications:
>>
>> 1. Should CSFS require some sort of tagged hash? Very likely answer is no
>> – tags interfere with certain use cases
>> 2. Should CSFS split the signature’s R & S value stack items for some
>> applications that otherwise may require OP_CAT? E.g. using a pinned R value
>> allows you to extract a private key if ever double signed, using 2 R values
>> allows pay-to-reveal-key contracts. Most likely answer is no, if that is
>> desired then OP_CAT can be introduced
>> 3. Should CSFS support a cheap way to reference the taproot internal or
>> external key? Perhaps, can be handled with undefined upgradeable keytypes.
>> One might want to use the internal key, if the signed data should be valid
>> independent of the tapscript tree. One might want to use the external key,
>> if the data should only be valid for a single tapscript key + tree.
>> 4. Should invalid public keys types be a NOP to support future extended
>> pubkey types?
>>
>>
>>
>> Best,
>>
>>
>> Jeremy
>>
>>
>> ---
>> layout: specification
>> title: OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY Specification
>> category: spec
>> date: 2018-08-20
>> activation: 154230
>> version: 0.6
>> ---
>>
>> OP_CHECKDATASIG
>> ===
>>
>> OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY check whether a signature is valid 
>> with respect to a message and a public key.
>>
>> OP_CHECKDATASIG permits data to be imported into a script, and have its 
>> validity checked against some signing authority such as an "Oracle".
>>
>> OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY are designed to be implemented 
>> similarly to OP_CHECKSIG [1]. Conceptually, one could imagine OP_CHECKSIG 
>> functionality being replaced by OP_CHECKDATASIG, along with a separate Op 
>> Code to create a hash from the transaction based on the SigHash algorithm.
>>
>> OP_CHECKDATASIG Specification
>> -
>>
>> ### Semantics
>>
>> OP_CHECKDATASIG fails immediately if the stack is not well formed. To be 
>> well formed, the stack must contain at least three elements [``, 
>> ``, ``] in this order where `` is the top element and
>>   * `` must be a validly encoded public key
>>   * `` can be any string
>>   * `` must follow the strict DER encoding as described in [2] and the 
>> S-value of `` must be at most the curve order divided by 2 as described 
>> in [3]
>>
>> If the stack is well 

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

[Russell O'Connor via bitcoin-dev]

Hi Jermy,

As you are aware, we, and by we I mean mostly Sanket, are developing an
updated OP_CHECKSIGFROMSTACK implementation for tapscript on elements.  The
plan here would be to effectively support the an interface to the
variable-length extension of BIP-0340 schnorr signatures.

BIP-0340 would dispense with DER encoding (good riddance).
BIP-0340 signatures are batch verifiable along with other BIP-0340
transaction signatures and taproot tweak verification.
Support for variable length messages in BIP-0340 has been discussed in <
https://github.com/sipa/bips/issues/207> and an implementation has recently
been merged in .  The
BIP has not yet been updated but the difference is that the message m does
not have to be 32-bytes (it is recommended that the message be a 32-bit
tagged hash or a message with a 64-bit application specific prefix). The
CHECKSIGFROMSTACK operation (in tapscript) would use a stack item for this
m value to BIP-0340 signature verification and would not necessarily have
to be 32 bytes.

I think this design we are aiming for would be perfectly suited for Bitcoin
as well.

On Sat, Jul 3, 2021 at 12:32 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Reproduced below is the BIP text from Bitcoin Cash's (MIT-Licensed)
> specification for "CheckDataSig", more or less the same thing as
> CHECKSIGFROMSTACK
> https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_checkdatasig.md.
> In contrast to Element's implementation, it does not have Element's bugs
> around verify semantics and uses the nullfail rule, and there is a
> specification document so it seemed like the easiest starting point for
> discussion v.s. drafting something from scratch.
>
> Does anyone have any issue with adapting this exact text and
> implementation to a BIP for Bitcoin using 2 OP_SUCCESSX opcodes?
>
> Note that with *just* CheckSigFromStack, while you can do some very
> valuable use cases, but without OP_CAT it does not enable sophisticated
> covenants (and as per
> https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html just
> CAT alone enables such uses).
>
> Design questions worth considering as modifications:
>
> 1. Should CSFS require some sort of tagged hash? Very likely answer is no
> – tags interfere with certain use cases
> 2. Should CSFS split the signature’s R & S value stack items for some
> applications that otherwise may require OP_CAT? E.g. using a pinned R value
> allows you to extract a private key if ever double signed, using 2 R values
> allows pay-to-reveal-key contracts. Most likely answer is no, if that is
> desired then OP_CAT can be introduced
> 3. Should CSFS support a cheap way to reference the taproot internal or
> external key? Perhaps, can be handled with undefined upgradeable keytypes.
> One might want to use the internal key, if the signed data should be valid
> independent of the tapscript tree. One might want to use the external key,
> if the data should only be valid for a single tapscript key + tree.
> 4. Should invalid public keys types be a NOP to support future extended
> pubkey types?
>
>
>
> Best,
>
>
> Jeremy
>
>
> ---
> layout: specification
> title: OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY Specification
> category: spec
> date: 2018-08-20
> activation: 154230
> version: 0.6
> ---
>
> OP_CHECKDATASIG
> ===
>
> OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY check whether a signature is valid 
> with respect to a message and a public key.
>
> OP_CHECKDATASIG permits data to be imported into a script, and have its 
> validity checked against some signing authority such as an "Oracle".
>
> OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY are designed to be implemented 
> similarly to OP_CHECKSIG [1]. Conceptually, one could imagine OP_CHECKSIG 
> functionality being replaced by OP_CHECKDATASIG, along with a separate Op 
> Code to create a hash from the transaction based on the SigHash algorithm.
>
> OP_CHECKDATASIG Specification
> -
>
> ### Semantics
>
> OP_CHECKDATASIG fails immediately if the stack is not well formed. To be well 
> formed, the stack must contain at least three elements [``, ``, 
> ``] in this order where `` is the top element and
>   * `` must be a validly encoded public key
>   * `` can be any string
>   * `` must follow the strict DER encoding as described in [2] and the 
> S-value of `` must be at most the curve order divided by 2 as described 
> in [3]
>
> If the stack is well formed, then OP_CHECKDATASIG pops the top three elements 
> [``, ``, ``] from the stack and pushes true onto the stack 
> if `` is valid with respect to the raw single-SHA256 hash of `` and 
> `` using the secp256k1 elliptic curve. Otherwise, it pops three 
> elements and pushes false onto the stack in the case that `` is the 
> empty string and fails in all other cases.
>
> Nullfail is enforced the same as for OP_CHECKSIG [3]. If the signature 

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

[Jeremy via bitcoin-dev]

Reproduced below is the BIP text from Bitcoin Cash's (MIT-Licensed)
specification for "CheckDataSig", more or less the same thing as
CHECKSIGFROMSTACK
https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_checkdatasig.md.
In contrast to Element's implementation, it does not have Element's bugs
around verify semantics and uses the nullfail rule, and there is a
specification document so it seemed like the easiest starting point for
discussion v.s. drafting something from scratch.

Does anyone have any issue with adapting this exact text and implementation
to a BIP for Bitcoin using 2 OP_SUCCESSX opcodes?

Note that with *just* CheckSigFromStack, while you can do some very
valuable use cases, but without OP_CAT it does not enable sophisticated
covenants (and as per
https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html just
CAT alone enables such uses).

Design questions worth considering as modifications:

1. Should CSFS require some sort of tagged hash? Very likely answer is no –
tags interfere with certain use cases
2. Should CSFS split the signature’s R & S value stack items for some
applications that otherwise may require OP_CAT? E.g. using a pinned R value
allows you to extract a private key if ever double signed, using 2 R values
allows pay-to-reveal-key contracts. Most likely answer is no, if that is
desired then OP_CAT can be introduced
3. Should CSFS support a cheap way to reference the taproot internal or
external key? Perhaps, can be handled with undefined upgradeable keytypes.
One might want to use the internal key, if the signed data should be valid
independent of the tapscript tree. One might want to use the external key,
if the data should only be valid for a single tapscript key + tree.
4. Should invalid public keys types be a NOP to support future extended
pubkey types?



Best,


Jeremy


---
layout: specification
title: OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY Specification
category: spec
date: 2018-08-20
activation: 154230
version: 0.6
---

OP_CHECKDATASIG
===

OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY check whether a signature is
valid with respect to a message and a public key.

OP_CHECKDATASIG permits data to be imported into a script, and have
its validity checked against some signing authority such as an
"Oracle".

OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY are designed to be
implemented similarly to OP_CHECKSIG [1]. Conceptually, one could
imagine OP_CHECKSIG functionality being replaced by OP_CHECKDATASIG,
along with a separate Op Code to create a hash from the transaction
based on the SigHash algorithm.

OP_CHECKDATASIG Specification
-

### Semantics

OP_CHECKDATASIG fails immediately if the stack is not well formed. To
be well formed, the stack must contain at least three elements
[``, ``, ``] in this order where `` is the
top element and
  * `` must be a validly encoded public key
  * `` can be any string
  * `` must follow the strict DER encoding as described in [2]
and the S-value of `` must be at most the curve order divided by
2 as described in [3]

If the stack is well formed, then OP_CHECKDATASIG pops the top three
elements [``, ``, ``] from the stack and pushes true
onto the stack if `` is valid with respect to the raw
single-SHA256 hash of `` and `` using the secp256k1
elliptic curve. Otherwise, it pops three elements and pushes false
onto the stack in the case that `` is the empty string and fails
in all other cases.

Nullfail is enforced the same as for OP_CHECKSIG [3]. If the signature
does not match the supplied public key and message hash, and the
signature is not an empty byte array, the entire script fails.

### Opcode Number

OP_CHECKDATASIG uses the previously unused opcode number 186 (0xba in
hex encoding)

### SigOps

Signature operations accounting for OP_CHECKDATASIG shall be
calculated the same as OP_CHECKSIG. This means that each
OP_CHECKDATASIG shall be counted as one (1) SigOp.

### Activation

Use of OP_CHECKDATASIG, unless occuring in an unexecuted OP_IF branch,
will make the transaction invalid if it is included in a block where
the median timestamp of the prior 11 blocks is less than 154230.

### Unit Tests

 - `   OP_CHECKDATASIG` fails if 15 November 2018
protocol upgrade is not yet activated.
 - `  OP_CHECKDATASIG` fails if there are fewer than 3 items on stack.
 - `   OP_CHECKDATASIG` fails if `` is not a
validly encoded public key.
 - `   OP_CHECKDATASIG` fails if `` is not a
validly encoded signature with strict DER encoding.
 - `   OP_CHECKDATASIG` fails if signature ``
is not empty and does not pass the Low S check.
 - `   OP_CHECKDATASIG` fails if signature ``
is not empty and does not pass signature validation of `` and
``.
 - `   OP_CHECKDATASIG` pops three elements and
pushes false onto the stack if `` is an empty byte array.
 - `   OP_CHECKDATASIG` pops three elements and
pushes true onto the stack if `` is a valid signature of ``
with respect to ``.