path: root/e0/39d55e63ba5f8956329b6c2c6ea8ab3d208fb4

Return-Path: <jlrubin@mit.edu>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2A542C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jul 2021 16:32:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 02F356064A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jul 2021 16:32:13 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id WjU6zTKU5GZN
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jul 2021 16:32:10 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 829CB60639
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jul 2021 16:32:10 +0000 (UTC)
Received: from mail-io1-f43.google.com (mail-io1-f43.google.com
 [209.85.166.43]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 163GW8tY019548
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 3 Jul 2021 12:32:09 -0400
Received: by mail-io1-f43.google.com with SMTP id a6so15704175ioe.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 03 Jul 2021 09:32:08 -0700 (PDT)
X-Gm-Message-State: AOAM5339mtV+TX/tigpsTNju2ZJY4lYtJPbIfwSlaFGvtJ+Egyumu7L8
 y3Q0K2XjEfwYP/c3eOoi86qXuodGLPgWy1VW/xs=
X-Google-Smtp-Source: ABdhPJxWMlQYYbcShGmH2Sp3XexLne5HKOskFTF9uOADjNjH+iwl+HtwRDH+3EoQQtSzgcU2at+AMPsf5usWw7f6gcQ=
X-Received: by 2002:a5e:dd03:: with SMTP id t3mr4658679iop.97.1625329928159;
 Sat, 03 Jul 2021 09:32:08 -0700 (PDT)
MIME-Version: 1.0
From: Jeremy <jlrubin@mit.edu>
Date: Sat, 3 Jul 2021 09:31:57 -0700
X-Gmail-Original-Message-ID: <CAD5xwhjmu-Eee47Ho5eA6E6+aAdnchLU0OVZo=RTHaXnN17x8A@mail.gmail.com>
Message-ID: <CAD5xwhjmu-Eee47Ho5eA6E6+aAdnchLU0OVZo=RTHaXnN17x8A@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000002c48205c63a9daa"
Subject: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Jul 2021 16:32:13 -0000

--00000000000002c48205c63a9daa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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_check=
datasig.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 =
=E2=80=93
tags interfere with certain use cases
2. Should CSFS split the signature=E2=80=99s R & S value stack items for so=
me
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: 1542300000
version: 0.6
---

OP_CHECKDATASIG
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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
[`<sig>`, `<msg>`, `<pubKey>`] in this order where `<pubKey>` is the
top element and
  * `<pubKey>` must be a validly encoded public key
  * `<msg>` can be any string
  * `<sig>` must follow the strict DER encoding as described in [2]
and the S-value of `<sig>` 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 [`<sig>`, `<msg>`, `<pubKey>`] from the stack and pushes true
onto the stack if `<sig>` is valid with respect to the raw
single-SHA256 hash of `<msg>` and `<pubKey>` using the secp256k1
elliptic curve. Otherwise, it pops three elements and pushes false
onto the stack in the case that `<sig>` 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 1542300000.

### Unit Tests

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

OP_CHECKDATASIGVERIFY Specification
-----------------------------------

### Semantics

OP_CHECKDATASIGVERIFY is equivalent to OP_CHECKDATASIG followed by
OP_VERIFY. It leaves nothing on the stack, and will cause the script
to fail immediately if the signature check does not pass.

### Opcode Number

OP_CHECKDATASIGVERIFY uses the previously unused opcode number 187
(0xbb in hex encoding)

### SigOps

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

### Activation

Use of OP_CHECKDATASIGVERIFY, 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
1542300000.

### Unit Tests

 - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if 15 November
2018 protocol upgrade is not yet activated.
 - `<sig> <msg> OP_CHECKDATASIGVERIFY` fails if there are fewer than 3
item on stack.
 - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY`fails if `<pubKey>` is
not a validly encoded public key.
 - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if `<sig>` is
not a validly encoded signature with strict DER encoding.
 - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if signature
`<sig>` is not empty and does not pass the Low S check.
 - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if `<sig>` is
not a valid signature of `<msg>` with respect to `<pubKey>`.
 - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` pops the top three
stack elements if `<sig>` is a valid signature of `<msg>` with respect
to `<pubKey>`.

Sample Implementation [4, 5]
----------------------------

```c++
                    case OP_CHECKDATASIG:
                    case OP_CHECKDATASIGVERIFY: {
                        // Make sure this remains an error before activatio=
n.
                        if ((flags & SCRIPT_ENABLE_CHECKDATASIG) =3D=3D 0) =
{
                            return set_error(serror, SCRIPT_ERR_BAD_OPCODE)=
;
                        }

                        // (sig message pubkey -- bool)
                        if (stack.size() < 3) {
                            return set_error(
                                serror, SCRIPT_ERR_INVALID_STACK_OPERATION)=
;
                        }

                        valtype &vchSig =3D stacktop(-3);
                        valtype &vchMessage =3D stacktop(-2);
                        valtype &vchPubKey =3D stacktop(-1);

                        if (!CheckDataSignatureEncoding(vchSig, flags,
                                                        serror) ||
                            !CheckPubKeyEncoding(vchPubKey, flags, serror))=
 {
                            // serror is set
                            return false;
                        }

                        bool fSuccess =3D false;
                        if (vchSig.size()) {
                            valtype vchHash(32);
                            CSHA256()
                                .Write(vchMessage.data(), vchMessage.size()=
)
                                .Finalize(vchHash.data());
                            uint256 message(vchHash);
                            CPubKey pubkey(vchPubKey);
                            fSuccess =3D pubkey.Verify(message, vchSig);
                        }

                        if (!fSuccess && (flags & SCRIPT_VERIFY_NULLFAIL) &=
&
                            vchSig.size()) {
                            return set_error(serror, SCRIPT_ERR_SIG_NULLFAI=
L);
                        }

                        popstack(stack);
                        popstack(stack);
                        popstack(stack);
                        stack.push_back(fSuccess ? vchTrue : vchFalse);
                        if (opcode =3D=3D OP_CHECKDATASIGVERIFY) {
                            if (fSuccess) {
                                popstack(stack);
                            } else {
                                return set_error(serror,
                                                 SCRIPT_ERR_CHECKDATASIGVER=
IFY);
                            }
                        }
                    } break;
```

Sample Usage
------------

The following example shows a spend and redeem script for a basic use
of CHECKDATASIG.  This example validates the signature of some data,
provides a placeholder where you would then process that data, and
finally allows one of 2 signatures to spend based on the outcome of
the data processing.

### spend script:
```
push txsignature
push txpubkey
push msg
push sig
```
### redeem script:
```
                                (txsig, txpubkey msg, sig)
OP_OVER                         (txsig, txpubkey, msg, sig, msg)
push data pubkey                (txsig, txpubkey, msg, sig, msg, pubkey)
OP_CHECKDATASIGVERIFY           (txsig, txpubkey, msg)
```
Now that msg is on the stack top, the script can write predicates on it,
resulting in the message being consumed and a true/false condition
left on the stack: (txpubkey, txsig, boolean)
```
OP_IF                           (txsig, txpubkey)
  OP_DUP                        (txsig, txpubkey, txpubkey)
  OP_HASH160                    (txsig, txpubkey, address)
  push <p2pkh spend address>    (txsig, txpubkey, address, p2pkh spend addr=
ess)
  OP_EQUALVERIFY                (txsig, txpubkey)
  OP_CHECKSIG
OP_ELSE
  (same as if clause but a different <p2pkh spend address>)
OP_ENDIF
```

History
-------

This specification is based on Andrew Stone=E2=80=99s OP_DATASIGVERIFY
proposal [6, 7]. It is modified from Stone's original proposal based
on a synthesis of all the peer-review and feedback received [8].

References
----------

[1] [OP_CHECKSIG](https://en.bitcoin.it/wiki/OP_CHECKSIG)

[2] [Strict DER
Encoding](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki)

[3] [Low-S and Nullfail
Specification](https://github.com/bitcoin/bips/blob/master/bip-0146.mediawi=
ki)

[4] [Bitcoin ABC implementation](https://reviews.bitcoinabc.org/D1621)

[5] [Bitcoin ABC implementation update](https://reviews.bitcoinabc.org/D164=
6)

[6] [Andrew Stone=E2=80=99s
OP_DATASIGVERIFY](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob=
/bucash1.3.0.0/doc/opdatasigverify.md)

[7] [Andrew Stone's article on
Scripting](https://medium.com/@g.andrew.stone/bitcoin-scripting-application=
s-decision-based-spending-8e7b93d7bdb9)

[8] [Peer Review of Andrew Stone's
Proposal](https://github.com/bitcoincashorg/bitcoincash.org/pull/10)


--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

--00000000000002c48205c63a9daa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default">Reproduced below is the BIP t=
ext from Bitcoin Cash&#39;s (MIT-Licensed) specification for &quot;CheckDat=
aSig&quot;, more or less the same thing as CHECKSIGFROMSTACK <a href=3D"htt=
ps://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_checkdat=
asig.md">https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec=
/op_checkdatasig.md</a>. In contrast to Element&#39;s implementation, it do=
es not have Element&#39;s bugs around verify semantics and uses the nullfai=
l rule, and there is a specification document so it seemed like the easiest=
 starting point for discussion v.s. drafting something from scratch.</div><=
div class=3D"gmail_default"><br>Does anyone have any issue with adapting th=
is exact text and implementation to a BIP for Bitcoin using 2 OP_SUCCESSX o=
pcodes?</div><div class=3D"gmail_default"><br></div><div class=3D"gmail_def=
ault">Note that with *just* CheckSigFromStack, while you can do some very v=
aluable use cases, but without OP_CAT it does not enable sophisticated cove=
nants (and as per=C2=A0<a href=3D"https://www.wpsoftware.net/andrew/blog/ca=
t-and-schnorr-tricks-i.html">https://www.wpsoftware.net/andrew/blog/cat-and=
-schnorr-tricks-i.html</a> just CAT alone enables such uses).<br><br>Design=
 questions worth considering as modifications:</div><div class=3D"gmail_def=
ault"><br>1. Should CSFS require some sort of tagged hash? Very likely answ=
er is no =E2=80=93 tags interfere with certain use cases<br>2. Should CSFS =
split the signature=E2=80=99s R &amp; S value stack items for some applicat=
ions 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<br>3. Should CSFS support a cheap way to refe=
rence the taproot internal or external key? Perhaps, can be handled with un=
defined upgradeable keytypes. One might want to use the internal key, if th=
e 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.<br>4. Should invalid public keys types be a NOP to s=
upport future extended pubkey types?</div><div class=3D"gmail_default"><br>=
</div><div class=3D"gmail_default"><br><br></div><div class=3D"gmail_defaul=
t">Best,<br><br><br>Jeremy<pre style=3D"color:rgb(0,0,0);font-family:arial,=
helvetica,sans-serif;font-size:small;word-wrap:break-word;white-space:pre-w=
rap"><br></pre><pre style=3D"color:rgb(0,0,0);font-family:arial,helvetica,s=
ans-serif;font-size:small;word-wrap:break-word;white-space:pre-wrap">---
layout: specification
title: OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY Specification
category: spec
date: 2018-08-20
activation: 1542300000
version: 0.6
---

OP_CHECKDATASIG
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY check whether a signature is vali=
d with respect to a message and a public key.

OP_CHECKDATASIG permits data to be imported into a script, and have its val=
idity checked against some signing authority such as an &quot;Oracle&quot;.

OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY are designed to be implemented si=
milarly to OP_CHECKSIG [1]. Conceptually, one could imagine OP_CHECKSIG fun=
ctionality 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 we=
ll formed, the stack must contain at least three elements [`&lt;sig&gt;`, `=
&lt;msg&gt;`, `&lt;pubKey&gt;`] in this order where `&lt;pubKey&gt;` is the=
 top element and
  * `&lt;pubKey&gt;` must be a validly encoded public key
  * `&lt;msg&gt;` can be any string
  * `&lt;sig&gt;` must follow the strict DER encoding as described in [2] a=
nd the S-value of `&lt;sig&gt;` 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 elemen=
ts [`&lt;sig&gt;`, `&lt;msg&gt;`, `&lt;pubKey&gt;`] from the stack and push=
es true onto the stack if `&lt;sig&gt;` is valid with respect to the raw si=
ngle-SHA256 hash of `&lt;msg&gt;` and `&lt;pubKey&gt;` using the secp256k1 =
elliptic curve. Otherwise, it pops three elements and pushes false onto the=
 stack in the case that `&lt;sig&gt;` 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 n=
ot an empty byte array, the entire script fails.

### Opcode Number

OP_CHECKDATASIG uses the previously unused opcode number 186 (0xba in hex e=
ncoding)

### 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 1542300000.

### Unit Tests

 - `&lt;sig&gt; &lt;msg&gt; &lt;pubKey&gt; OP_CHECKDATASIG` fails if 15 Nov=
ember 2018 protocol upgrade is not yet activated.
 - `&lt;sig&gt; &lt;msg&gt; OP_CHECKDATASIG` fails if there are fewer than =
3 items on stack.
 - `&lt;sig&gt; &lt;msg&gt; &lt;pubKey&gt; OP_CHECKDATASIG` fails if `&lt;p=
ubKey&gt;` is not a validly encoded public key.
 - `&lt;sig&gt; &lt;msg&gt; &lt;pubKey&gt; OP_CHECKDATASIG` fails if `&lt;s=
ig&gt;` is not a validly encoded signature with strict DER encoding.
 - `&lt;sig&gt; &lt;msg&gt; &lt;pubKey&gt; OP_CHECKDATASIG` fails if signat=
ure `&lt;sig&gt;` is not empty and does not pass the Low S check.
 - `&lt;sig&gt; &lt;msg&gt; &lt;pubKey&gt; OP_CHECKDATASIG` fails if signat=
ure `&lt;sig&gt;` is not empty and does not pass signature validation of `&=
lt;msg&gt;` and `&lt;pubKey&gt;`.
 - `&lt;sig&gt; &lt;msg&gt; &lt;pubKey&gt; OP_CHECKDATASIG` pops three elem=
ents and pushes false onto the stack if `&lt;sig&gt;` is an empty byte arra=
y.
 - `&lt;sig&gt; &lt;msg&gt; &lt;pubKey&gt; OP_CHECKDATASIG` pops three elem=
ents and pushes true onto the stack if `&lt;sig&gt;` is a valid signature o=
f `&lt;msg&gt;` with respect to `&lt;pubKey&gt;`.

OP_CHECKDATASIGVERIFY Specification
-----------------------------------

### Semantics

OP_CHECKDATASIGVERIFY is equivalent to OP_CHECKDATASIG followed by OP_VERIF=
Y. It leaves nothing on the stack, and will cause the script to fail immedi=
ately if the signature check does not pass.

### Opcode Number

OP_CHECKDATASIGVERIFY uses the previously unused opcode number 187 (0xbb in=
 hex encoding)

### SigOps

Signature operations accounting for OP_CHECKDATASIGVERIFY shall be calculat=
ed the same as OP_CHECKSIGVERIFY. This means that each OP_CHECKDATASIGVERIF=
Y shall be counted as one (1) SigOp.

### Activation

Use of OP_CHECKDATASIGVERIFY, 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 1542300000.

### Unit Tests

 - `&lt;sig&gt; &lt;msg&gt; &lt;pubKey&gt; OP_CHECKDATASIGVERIFY` fails if =
15 November 2018 protocol upgrade is not yet activated.
 - `&lt;sig&gt; &lt;msg&gt; OP_CHECKDATASIGVERIFY` fails if there are fewer=
 than 3 item on stack.
 - `&lt;sig&gt; &lt;msg&gt; &lt;pubKey&gt; OP_CHECKDATASIGVERIFY`fails if `=
&lt;pubKey&gt;` is not a validly encoded public key.
 - `&lt;sig&gt; &lt;msg&gt; &lt;pubKey&gt; OP_CHECKDATASIGVERIFY` fails if =
`&lt;sig&gt;` is not a validly encoded signature with strict DER encoding.
 - `&lt;sig&gt; &lt;msg&gt; &lt;pubKey&gt; OP_CHECKDATASIGVERIFY` fails if =
signature `&lt;sig&gt;` is not empty and does not pass the Low S check.
 - `&lt;sig&gt; &lt;msg&gt; &lt;pubKey&gt; OP_CHECKDATASIGVERIFY` fails if =
`&lt;sig&gt;` is not a valid signature of `&lt;msg&gt;` with respect to `&l=
t;pubKey&gt;`.
 - `&lt;sig&gt; &lt;msg&gt; &lt;pubKey&gt; OP_CHECKDATASIGVERIFY` pops the =
top three stack elements if `&lt;sig&gt;` is a valid signature of `&lt;msg&=
gt;` with respect to `&lt;pubKey&gt;`.

Sample Implementation [4, 5]
----------------------------

```c++
                    case OP_CHECKDATASIG:
                    case OP_CHECKDATASIGVERIFY: {
                        // Make sure this remains an error before activatio=
n.
                        if ((flags &amp; SCRIPT_ENABLE_CHECKDATASIG) =3D=3D=
 0) {
                            return set_error(serror, SCRIPT_ERR_BAD_OPCODE)=
;
                        }

                        // (sig message pubkey -- bool)
                        if (stack.size() &lt; 3) {
                            return set_error(
                                serror, SCRIPT_ERR_INVALID_STACK_OPERATION)=
;
                        }

                        valtype &amp;vchSig =3D stacktop(-3);
                        valtype &amp;vchMessage =3D stacktop(-2);
                        valtype &amp;vchPubKey =3D stacktop(-1);

                        if (!CheckDataSignatureEncoding(vchSig, flags,
                                                        serror) ||
                            !CheckPubKeyEncoding(vchPubKey, flags, serror))=
 {
                            // serror is set
                            return false;
                        }

                        bool fSuccess =3D false;
                        if (vchSig.size()) {
                            valtype vchHash(32);
                            CSHA256()
                                .Write(vchMessage.data(), vchMessage.size()=
)
                                .Finalize(vchHash.data());
                            uint256 message(vchHash);
                            CPubKey pubkey(vchPubKey);
                            fSuccess =3D pubkey.Verify(message, vchSig);
                        }

                        if (!fSuccess &amp;&amp; (flags &amp; SCRIPT_VERIFY=
_NULLFAIL) &amp;&amp;
                            vchSig.size()) {
                            return set_error(serror, SCRIPT_ERR_SIG_NULLFAI=
L);
                        }

                        popstack(stack);
                        popstack(stack);
                        popstack(stack);
                        stack.push_back(fSuccess ? vchTrue : vchFalse);
                        if (opcode =3D=3D OP_CHECKDATASIGVERIFY) {
                            if (fSuccess) {
                                popstack(stack);
                            } else {
                                return set_error(serror,
                                                 SCRIPT_ERR_CHECKDATASIGVER=
IFY);
                            }
                        }
                    } break;
```

Sample Usage
------------

The following example shows a spend and redeem script for a basic use of CH=
ECKDATASIG.  This example validates the signature of some data, provides a =
placeholder where you would then process that data, and finally allows one =
of 2 signatures to spend based on the outcome of the data processing.

### spend script:
```
push txsignature
push txpubkey
push msg
push sig
```
### redeem script:
```
                                (txsig, txpubkey msg, sig)
OP_OVER                         (txsig, txpubkey, msg, sig, msg)
push data pubkey                (txsig, txpubkey, msg, sig, msg, pubkey)
OP_CHECKDATASIGVERIFY           (txsig, txpubkey, msg)
```
Now that msg is on the stack top, the script can write predicates on it,
resulting in the message being consumed and a true/false condition left on =
the stack: (txpubkey, txsig, boolean)
```
OP_IF                           (txsig, txpubkey)
  OP_DUP                        (txsig, txpubkey, txpubkey)
  OP_HASH160                    (txsig, txpubkey, address)
  push &lt;p2pkh spend address&gt;    (txsig, txpubkey, address, p2pkh spen=
d address)
  OP_EQUALVERIFY                (txsig, txpubkey)
  OP_CHECKSIG
OP_ELSE
  (same as if clause but a different &lt;p2pkh spend address&gt;)
OP_ENDIF
```

History
-------

This specification is based on Andrew Stone=E2=80=99s OP_DATASIGVERIFY prop=
osal [6, 7]. It is modified from Stone&#39;s original proposal based on a s=
ynthesis of all the peer-review and feedback received [8].

References
----------

[1] [OP_CHECKSIG](<a href=3D"https://en.bitcoin.it/wiki/OP_CHECKSIG">https:=
//en.bitcoin.it/wiki/OP_CHECKSIG</a>)

[2] [Strict DER Encoding](<a href=3D"https://github.com/bitcoin/bips/blob/m=
aster/bip-0066.mediawiki">https://github.com/bitcoin/bips/blob/master/bip-0=
066.mediawiki</a>)

[3] [Low-S and Nullfail Specification](<a href=3D"https://github.com/bitcoi=
n/bips/blob/master/bip-0146.mediawiki">https://github.com/bitcoin/bips/blob=
/master/bip-0146.mediawiki</a>)

[4] [Bitcoin ABC implementation](<a href=3D"https://reviews.bitcoinabc.org/=
D1621">https://reviews.bitcoinabc.org/D1621</a>)

[5] [Bitcoin ABC implementation update](<a href=3D"https://reviews.bitcoina=
bc.org/D1646">https://reviews.bitcoinabc.org/D1646</a>)

[6] [Andrew Stone=E2=80=99s OP_DATASIGVERIFY](<a href=3D"https://github.com=
/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.3.0.0/doc/opdatasigverify.m=
d">https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.3.0.0/=
doc/opdatasigverify.md</a>)

[7] [Andrew Stone&#39;s article on Scripting](<a href=3D"https://medium.com=
/@g.andrew.stone/bitcoin-scripting-applications-decision-based-spending-8e7=
b93d7bdb9">https://medium.com/@g.andrew.stone/bitcoin-scripting-application=
s-decision-based-spending-8e7b93d7bdb9</a>)

[8] [Peer Review of Andrew Stone&#39;s Proposal](<a href=3D"https://github.=
com/bitcoincashorg/bitcoincash.org/pull/10">https://github.com/bitcoincasho=
rg/bitcoincash.org/pull/10</a>)</pre></div><br clear=3D"all"><div><div dir=
=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div =
dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_bl=
ank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"=
_blank"></a></div></div></div></div>

--00000000000002c48205c63a9daa--