I told you what a script is, but not exactly what it’s needed for. By the way, in the article about transaction processing I gave you an overview of how bitcoins move around by introducing transaction inputs and outputs. We’re about to connect the dots.
The validation script
So far, we learned that a script is a piece of code that executes and yields a result. When building a transaction from an unspent transaction output (UTXO), there are two scripts we’re particularly interested in:
- The unspent output script, call it OS.
- The spending input script, call it IS.
The problem is producing such an IS that the concatenated script VS = IS + OS (the validation script), after being executed, returns a non-zero value. With this in mind, the validation script decides if the transaction input has right to spend the previous unspent output. It may sound difficult to understand, but it’s not.
Consider the input script:
and the previous output script:
OP_ADD OP_12 OP_EQUAL
Now join them to have the following validation script:
OP_6 OP_DUP OP_ADD OP_12 OP_EQUAL
and see how the stack evolves:
  [6, 6]  [12, 12] 
Fine, the validation script ends with 1 (
OP_TRUE) on the stack, so the input script can spend the previous output script.
In fact, many other input scripts comply, like:
OP_1 OP_15 OP_ADD OP_7 OP_SUB OP_3
See how anybody with some basic math knowledge could easily steal the output coins. Conversely, look at this very simple output script:
No matter the input script, the validation script will never succeed. Any bitcoin sent to this output will be lost forever.
In fact, all the above scripts are dangerous and would be rejected by Mainnet for not being standard. Miners don’t accept transactions with non-standard scripts because in many situations they may result in money loss, directly or indirectly.
Virtually any kind of script can be included in a transaction. Still, only standard scripts will be accepted by Mainnet miners for security reasons. The “standard” term comes from the
IsStandard check, a piece of code from Bitcoin Core ensuring that a script matches one of several well-known categories.
As of Bitcoin Core 0.10, these are considered standard scripts:
- P2PKH (pay-to-public-key-hash)
- P2SH (pay-to-script-hash)
- P2PK (pay-to-public-key)
In this course we’ll only treat the first ones. For your information, Testnet miners skip the
IsStandard check completely, thus making the Testnet network suitable for trying experimental scripts.
The most common standard scripts in the blockchain are named after P2PKH addresses (pay-to-public-key-hash). By having a destination P2PKH Bitcoin address, we can write an output script that will send coins to it. By having the private key from which the destination address was generated, we can write an input script that will later spend such coins.
A P2PKH output script contains a Base58Check-decoded destination address, that is the hash160 of an ECDSA public key:
OP_DUP OP_HASH160 [hash160(public_key)] OP_EQUALVERIFY OP_CHECKSIG
Take our sample compressed public key:
02 82 00 6e 93 98 a6 98 6e da 61 fe 91 67 4c 3a 10 8c 39 94 75 bf 1e 73 8f 19 df c2 db 11 db 1d 28
and its hash160 digest:
6b f1 9e 55 f9 4d 98 6b 46 40 c1 54 d8 64 69 93 41 91 95 11
that after Testnet versioning and Base58Check encoding is displayed as:
The output script that sends money to this address is:
76 (OP_DUP) a9 (OP_HASH160) 14 6b f1 9e 55 f9 4d 98 6b 46 40 c1 54 d8 64 69 93 41 91 95 11 88 (OP_EQUALVERIFY) ac (OP_CHECKSIG)
14 is an implicit push opcode indicating there are 20 bytes coming next, namely the hash160 digest. The output script alone is meaningless without knowing the corresponding input script, so keep reading.
A P2PKH input script contains a DER-encoded ECDSA signature and a raw public key, either uncompressed or compressed. In such an input script, there are no opcodes other than pushes:
For example, take the 70-bytes signature from the ECDSA chapter and append the
SIGHASH_ALL constant (
01) to it:
30 44 02 20 2b 2b 52 9b db dc 93 e7 8a f7 e0 02 28 b1 79 91 8b 03 2d 76 90 2f 74 ef 45 44 26 f7 d0 6c d0 f9 02 20 62 dd c7 64 51 cd 04 cb 56 7c a5 c5 e0 47 e8 ac 41 d3 d4 cf 7c b9 24 34 d5 5c b4 86 cc cf 6a f2 01
SIGHASH suffix is an advanced topic related to contracts. In this series we’ll stick with
SIGHASH_ALL because we’ll always sign all transaction inputs.
If you now take the public key from the previous paragraph, you have a typical input script:
47 30 44 02 20 2b 2b 52 9b db dc 93 e7 8a f7 e0 02 28 b1 79 91 8b 03 2d 76 90 2f 74 ef 45 44 26 f7 d0 6c d0 f9 02 20 62 dd c7 64 51 cd 04 cb 56 7c a5 c5 e0 47 e8 ac 41 d3 d4 cf 7c b9 24 34 d5 5c b4 86 cc cf 6a f2 01 21 02 82 00 6e 93 98 a6 98 6e da 61 fe 91 67 4c 3a 10 8c 39 94 75 bf 1e 73 8f 19 df c2 db 11 db 1d 28
21 are the hex lengths of the pushed signature and public key respectively.
If we want to spend the money we received on our sample address, we must provide a specific input script so that the composite validation script succeeds. If the input is “authentic”, the following script will return non-zero:
[signature] [public_key] OP_DUP OP_HASH160 [hash160(public_key)] OP_EQUALVERIFY OP_CHECKSIG
A step by step description in case the input script is valid:
- The input signature is pushed.
- The input public key is pushed.
- The top item (public key) is duplicated on the stack.
- The top item (public key) is hashed with hash160.
- The output hash160 is pushed.
- Input and output hash160 are popped then checked for equality.
- The input signature is verified against the public key.
OP_TRUEis pushed as a result of successful signature verification.
Let’s see what happens on the stack:
 [signature] [signature, public_key] [signature, public_key, public_key] [signature, public_key, hash160(public_key)] [signature, public_key, hash160(public_key), hash160(public_key)] [signature, public_key] 
The final stack holds
OP_TRUE, so the transaction input is legit. Along the road, two constraints were satisfied:
- The public key in the input script must hash to the Bitcoin address in the output script (step 6).
- The signature must be valid for the public key (step 7).
You may think that the input script alone is enough for signature verification, and you’d be wrong. I didn’t mention the third parameter of the verification process: the message! This is left for the next posts about transactions and, for your information, it’s going to be a tricky subject.
By the way, can you also see how important is to know if a private key is associated to an uncompressed or compressed public key? In case of “compression mismatch” between public keys and addresses, the first constraint would break. As a consequence, you cannot spend bitcoins sent to a compressed address with an input script containing an uncompressed public key, and vice versa.
Next block in chain?
You learned that only a standard subset of all possible scripts are accepted by the Bitcoin network. P2PKH scripts are the most common standard scripts you’ll find in the blockchain. Input and output scripts together form validation scripts. Miners execute validation scripts to either accept or reject a transaction.
In the next article we’ll finally start analyzing transactions. You’re about to make sense of the Bitcoin magic. Please share this post if you enjoyed it and use the form below for questions and comments!