Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add opdatasigverify.md specification #10

Closed
wants to merge 1 commit into from
Closed

Conversation

schancel
Copy link
Contributor

Add opdatasigverify spec for November.

@fyookball @Mengerian @gandrewstone


## Reference Implementation

Please refer to [this github branch](https://github.com/gandrewstone/BitcoinUnlimited/tree/op_datasigverify) for a complete implementation. Implementation is in src/test/interpreter.cpp/h and unit tests are located at src/test/script_tests.cpp.
Copy link
Collaborator

@sickpig sickpig May 15, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about:

Please refer to [this github commit](https://github.com/BitcoinUnlimited/BitcoinUnlimited/commit/1bf53307cab5d96076721ef5a238a63b03aca07d) for a complete implementation.

@fyookball
Copy link
Contributor

The reasoning not to have a separate OP_CHECKDATASIG seems to make sense because there's no practical use case to check the data and then not do anything with the evaluation. In practice, OP_CHECKSIG is always combined with a verification op_code afaik.

Copy link
Contributor

@deadalnix deadalnix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This spec is quite not in shape it needs to. In addition to the inline comments, The spec is lacking impact of this on sigops count - clearly these ops should count as sigops.


## Introduction

OP_DATASIGVERIFY allows signed data to be imported into a script. This data can then have many uses, depending on the rest of the script, such as deciding spendability of several possible addresses. This opcode therefore enables the powerful blockchain concept of an "oracle" -- an entity that publishes authoritative statements about extra-blockchain events -- to be used in the Bitcoin Cash blockchain. For an example use of how this opcode can be used to enable binary contracts on any security or betting on any quantitatively decidable event (such as a sports match) please [click here](https://medium.com/@g.andrew.stone/bitcoin-scripting-applications-decision-based-spending-8e7b93d7bdb9). But this is just one example; as the Bitcoin Cash Script language grows in expressiveness, it is anticipated that this opcode will be used in many other applications.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This text is very hard to understand. It should describe what the opcode does and why.


## Requirements on miners, full nodes, and clients

Miners, full nodes, and clients will implement the OP_DATASIGVERIFY opcode and activate it during the May 2018 hard fork.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't forget your time machine.

*OP_DATASIGVERIFY uses a new opcode number*

Opcode (decimal): 187
Opcode (hex): 0xbb
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there is a good argument to be made to have OP_DATACHECKSIG and OP_DATACHECKSIGVERIFY , based ont he same pattern as other checksig ops.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there at least one use-case for OP_DATACHECKSIG standalone?

spec/opdatasigverify.md Show resolved Hide resolved

#### value 1: DATASIG_COMPACT_ECDSA

This algorithm is the same operation as the Bitcoin Cash message verification RPC call (e.g signmessage/verifymessage). The signature must therefore be a pubkey-recoverable signature encoded in bitcoin's "compact" format. The authoritative specification of this signature is beyond the scope of this document, but in essence it is comprised of a 1 byte recovery ID, 32 bytes "r", 32 bytes "s".
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does the signature must use a pubkey recoverable algorithm ? It doesn't seems like it's bringing anything to the table to bake in that constraint.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So that the input script does not have to include the pubkey...

Copy link
Collaborator

@cpacia cpacia Jun 4, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've seen other discussion on recoverable public keys in general which have suggested that the space savings from not having to include the public key is not worth the speed hit from recovering the public key.

Has this tradeoff been considered? If so a few lines about why it's believed the tradeoff is worth it is probably needed.

If not we might want to consider just including the public key like normal.


This algorithm is the same operation as the Bitcoin Cash message verification RPC call (e.g signmessage/verifymessage). The signature must therefore be a pubkey-recoverable signature encoded in bitcoin's "compact" format. The authoritative specification of this signature is beyond the scope of this document, but in essence it is comprised of a 1 byte recovery ID, 32 bytes "r", 32 bytes "s".

The algorithm first computes the double-sha256 hash of the byte string "Bitcoin Signed Message:\n" prepended to the supplied *data* (stack top - 2). It then computes a pubkey from this hash and the provided signature (stack top - 1, without the first byte). If the pubkey cannot be recovered, the script fails. It then compares the hash160 (same as OP_HASH160) of the recovered pubkey to the provided *pubkeyhash* (stack top). If the comparison fails, the script fails.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part is inconsistent with other parts of the spec.

## Examples

* Simplest DATASIGVERIFY:
* output script: `pubkeyhash OP_DATASIGVERIFY`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does't make sense to bake the pubkey hash algorithm into that opcode.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

verses using the unhashed pubkey? The reason I did it this way is that pubkey hash is shorter, it hides the pubkey until use, and it is aligned with how signmessage/verifymessage works meaning that these RPCs can be used to create the spend and redeem scripts.

*top of stack*
* *pubkeyhash*
* *type and signature*
* *data*
Copy link
Contributor

@Mengerian Mengerian May 30, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it make sense to have data be above type and signature in the stack?

top of stack

  • pubkeyhash
  • data
  • type and signature

It seems this would work more naturally with data supplied in the output script, and not have to be repeated in the spend script.

  • output script: data pubkeyhash OP_DATASIGVERIFY
  • spend script: sig

It would also be easy to create scripts where the hash of the data is supplied

  • output script: OP_DUP OP_HASH160 <hash_of_data> OP_EQUALVERIFY pubkeyhash OP_DATASIGVERIFY
  • spend script: <sig> <data>

And it would allow a simpler version of the example you gave:

  • output script: data dpubkeyhash OP_DATASIGVERIFY OP_DUP OP_HASH160 pubkeyhash OP_EQUALVERIFY OP_CHECKSIGVERIFY
  • spend script: txSig pubkey daddrsig

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another, maybe better, option would be to have above the pubkey also:

top of stack

  • data
  • pubkeyhash
  • type and signature

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The data is unknown when the output script is created. It is provided by the input script and the signature verifies that the oracle produced this data rather than it being invented by the input script author. The hash_of_data proposal is not applicable here -- the purpose of this opcode is not to make a commitment to known but unrevealed data. Think stock price or sporting match scores...


#### value 1: DATASIG_COMPACT_ECDSA

This algorithm is the same operation as the Bitcoin Cash message verification RPC call (e.g signmessage/verifymessage). The signature must therefore be a pubkey-recoverable signature encoded in bitcoin's "compact" format. The authoritative specification of this signature is beyond the scope of this document, but in essence it is comprised of a 1 byte recovery ID, 32 bytes "r", 32 bytes "s".
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Has there been any discussion on the pros and cons of following the signmessage/verifymessage format?

In many ways, it feels like it would be more elegant to keep the implementation closer to OP_CHECKSIG. Just have the inputs be a Public key, data, and bare DER signature (maybe it would also make sense for the signature to include a "sighash type" similar to OP_CHECKSIG). If scripts don't want to reveal the Public Key in the output script, it can supply a hash in a similar manner as P2PKH.

Since it's consensus critical, it's unclear to me whether the signmessage/verifymessage format has completely well-defined behavior, whereas something closer to unmodified OP_CHECKSIG is battle tested.

@maplesyrupsucker maplesyrupsucker added this to To do in [WG] Website May 30, 2018
@gandrewstone
Copy link
Contributor

@schancel I am happy to make some of the requested changes based on the above discussion, but since you are the PR author I'm not sure whether I should or you want to. Let me know and if so, how do you want me to make them?

@sickpig
Copy link
Collaborator

sickpig commented Jun 5, 2018

paging @schancel

what do you think about @gandrewstone's proposal made here

#10 (comment)


* Simplest DATASIGVERIFY:
* output script: `pubkeyhash OP_DATASIGVERIFY`
* spend script: `data sig`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since OP_DATASIGVERIFY leaves the data on the Stack on completion, if the data is a value of zero, and is signed properly, then OP_DATASIGVERIFY would complete successfully, but the script in this example would fail since it ends with a zero value left on the stack.

Not sure if this is a practical problem, but it seems like a strange edge case.

@ClemensLey
Copy link

My two cents: Like @Mengerian I think that the inputs to OP_CHECKDATASIG should work as similar as possible to OP_CHECKSIG. This would mean that the parameters should be a public key, the message to be signed, and a signature. Like other op codes I think that it should pop the parameters from the stack and push the result (a boolean) onto the stack.

I think the op code would be easier to use if there is only a signature on the stack, not signature + sig_type. If we find strong use cases for other signature checking algorithm we could consider adding a signature type as a 4th parameter, but my feeling is that we should be fine with just a standard signature checking procedure.

Also I think it would be better if we could drop the requirement that the signature must be pubkey-recoverable.

All in all, I think that OP_CHECKDATASIG could be a valuable addition to the Bitcoin scripting language. We just need to do a little work to ensure that it is as easy to use as possible.

Mengerian added a commit that referenced this pull request Aug 6, 2018
This should supersede #10

It is a modified version of Andrew Stone's original proposal based on review feedback.

Thanks to Andrew Stone for the original proposal, and thanks to the reviewers:
 - Clemens Ley
 - Chris Pacia
 - Amaury Sechet
 - Andrea Suisani
 - Tom Harding
@Mengerian
Copy link
Contributor

This proposal has been superseded by #93

@Mengerian Mengerian closed this Aug 15, 2018
Mengerian added a commit that referenced this pull request Sep 13, 2018
* Specification for OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY

This should supersede #10

It is a modified version of Andrew Stone's original "OP_DATASIGVERIFY" proposal based on review feedback.

Thanks to Andrew Stone for the original proposal, and thanks to the reviewers:
 - Clemens Ley
 - Chris Pacia
 - Amaury Sechet
 - Andrew Stone
 - Andrea Suisani
 - Tom Harding
 - awemany
 - Mark B Lundeberg
maplesyrupsucker pushed a commit that referenced this pull request Sep 14, 2018
* Fix translation menu links

The previous commit fixing the base_url caused the translation
menu to have a double root address.

* Bandaid for localization redirects

* webmaster tools / search console meta tag verification

* Disable broken language redirects

* Add Youtube explainer Video to about section (#52)

* revise about to include video

* Revise video to subtitle version

* Removed absolute path for listing buttons (#65)

* height override on submission form - fixes ipad 1px height bug (#64)

* height override on typeform - fixes ipad 1px height bug

* removed breaks

* small phone fix

* Content of 404 translatable (#59)

The error 404 page now fetches its content from the yaml files.

* Merged jonalds english in, resolved conflicts (#67)

* Updated copy in English

* moved headings into headings

* Conditional templates - show new sections / content if translations are complete.

* Broken translations fixed (#69)

* German translation updated

* Greek language temporarily removed until updated

* Swiss German temporarily disabled until updated

* Changenow.io removed (#76)

* added whitepaper button, revised section heading in about to fix spacing issue on mobile. (#75)

* removed retired listing (#79)

* July 13 listings (#81)

* globe to nav

* Listing additions:

BCH Football
Bitvavo
Blockchain poker
Memo.cash
Store.bitcoin
Cashpay
Cryptonize.it
Txhighway.com

* FAQ section displayed after 'nodes' (#83)

* Video subtitles automatically enabled (#85)

* ChangeNOW.io added to the list of exchanges (#86)

* Add Blockchain Poker to 'Services'. (#77)

* Logos formatting fixed (#91)

* Nov 15 2018 network upgrade message (#98)

* Nov 15 2018 network upgrade

* Beautified

* Fixed some outdated links in spec/ (#97)

* Removed gdax (#99)

* Changelly logo updated (#101)

* Fixed broken link (#102)

* 0.18.0 link to abc (#103)

* 0.18.0 link to abc

* revised hardfork notification content and added subheaders

* Added spaces to match with coding style

* Link revision to 0.18.0 (#104)

* 0.18.0 link to abc

* revised hardfork notification content and added subheaders

* link revision

* Novhf hotfix - added bcash (#106)

* 0.18.0 link to abc

* revised hardfork notification content and added subheaders

* link revision

* bcash added to notice

* BCH spec for Block and Transaction (#92)

* BCH spec for Block and Transaction

* Fixed headers, spellchecked

* Title

* added testnet, 0.18.1 (#108)

* added testnet, 0.18.1

* removed edit from url to test

* Revise 0.18.1 link (#109)

* added testnet, 0.18.1

* removed edit from url to test

* revise link to 0.18.1

* Godex to the list of Exchanges  (#110)

* Godex logo

* Godex link

* Delete godex.png

* Godex logo

* Godex logo

Abucoins Exchange is closing

* Error 403 page design (#112)

* Specification for OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY (#93)

* Specification for OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY

This should supersede #10

It is a modified version of Andrew Stone's original "OP_DATASIGVERIFY" proposal based on review feedback.

Thanks to Andrew Stone for the original proposal, and thanks to the reviewers:
 - Clemens Ley
 - Chris Pacia
 - Amaury Sechet
 - Andrew Stone
 - Andrea Suisani
 - Tom Harding
 - awemany
 - Mark B Lundeberg
@maplesyrupsucker maplesyrupsucker moved this from Website To do to Done in [WG] Website Dec 10, 2018
@merc1er merc1er deleted the op_datasigverify branch August 20, 2019 15:47
Copy link

@baby636 baby636 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


## Introduction

OP_DATASIGVERIFY allows signed data to be imported into a script. This data can then have many uses, depending on the rest of the script, such as deciding spendability of several possible addresses. This opcode therefore enables the powerful blockchain concept of an "oracle" -- an entity that publishes authoritative statements about extra-blockchain events -- to be used in the Bitcoin Cash blockchain. For an example use of how this opcode can be used to enable binary contracts on any security or betting on any quantitatively decidable event (such as a sports match) please [click here](https://medium.com/@g.andrew.stone/bitcoin-scripting-applications-decision-based-spending-8e7b93d7bdb9). But this is just one example; as the Bitcoin Cash Script language grows in expressiveness, it is anticipated that this opcode will be used in many other applications.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
[WG] Website
  
Done
Development

Successfully merging this pull request may close these issues.

None yet

10 participants