NOTE: This is a draft in progress, so that I can get some feedback from early reviewers. It is not yet ready for learning.
With a basic understanding of Bitcoin Scripting in hand, you can now easily analyze the functioning of a standard P2PKH script.
We've long said that when funds are sent to a Bitcoin address, they're locked to the private key associated with that address. This is managed through the scriptPubKey of a P2PKH transaction, which is designed such that it requires the recipient to have the private key associated with the the P2PKH Bitcoin address. To be precise, the recipient must supply both the actual public key and a signature generated by the private key.
That's what the scriptSig unlocking script seen in the previous section showed, a <signature> <pubKey>:
3045022100c4ef5b531061a184404e84ab46beee94e51e8ae15ce98d2f3e10ae7774772ffd02203c546c399c4dc1d6eea692f73bb3fff490ea2e98fe300ac6a11840c7d52b6166[ALL] 0319cd3f2485e3d47552617b03c693b7f92916ac374644e22b07420c8812501cfb.
The associated scriptPubKey locking script from the previous section was OP_DUP OP_HASH160 371c20fb2e9899338ce5e99908e64fd30b789313 OP_EQUALVERIFY OP_CHECKSIG, which is the standard locking methodology for a P2PKH address. That long string in the middle is a <pubKeyHash>.
When you unlock a P2PKH UTXO, you (effectively) concatenate the unlocking and locking scripts, producing:
Script: <signature> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Now, you can evaluate how the P2PKH UTXO is unlocked.
First, you put the initial constants on the stack, then make a duplicate of the pubKey with OP_DUP:
Script: <signature> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Stack: [ ]
Script: <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Stack: [ <signature> ]
Script: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Stack: [ <signature> <pubKey> ]
Script: OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Running: <pubKey> OP_DUP
Stack: [ <signature> <pubKey> <pubKey> ]
Why the duplicate? Because that's what's required by the script!
Next, OP_HASH160 pops the <pubKey> off the stack, hashes it, and puts the result back on the stack.
Script: <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Running: <pubKey> OP_HASH160
Stack: [ <signature> <pubKey> <pubKeyHash> ]
Then, you place the <pubKeyHash> that was in the locking script on the stack:
Script: OP_EQUALVERIFY OP_CHECKSIG
Stack: [ <signature> <pubKey> <pubKeyHash> <pubKeyHash> ]
OP_EQUALVERIFY is effectively two opcodes: OP_EQUAL, which pops two items from the stack and pushes True or False depending on if they're equal; and OP_VERIFY which pops that result and immediately marks the transaction as invalid if it's False. (Chapter 10 talks more about the use of OP_VERIFY as a conditional.)
Assuming the two <pubKeyHash>es are equal, you will have the following result:
Script: OP_CHECKSIG
Running: <pubKeyHash> <pubKeyHash> OP_EQUALVERIFY
Stack: [ <signature> <pubKey> ]
At this point you've proven that the <pubKey> supplied in the scriptSig hashes to the Bitcoin address in question, so you know that the redeemer knew the public key. They just need to prove knowledge of the private key, which is done with OP_CHECKSIG, which confirms that the unlocking script's signature matches that public key.
Script:
Running: <signature> <pubKey> OP_CHECKSIG
Stack: [ True ]
The Script now ends and the transaction is allowed to respend the UTXO in question.
If you have a scriptPubKey (the script) and a signature and pubkey (the result of running the sigScript of the input), you can debug these by doing
$ btcdeb <script> <signature> <pubkey>For example, transaction 4de699d05b416175ad7a119013563a0f436abe46c6a52f05bf59baca1b2aec41 in block 499033 has as its first output the script sig 483045022100c7d8e302908fdc601b125c2734de63ed3bf54353e13a835313c2a2aa5e8f21810220131fad73787989d7fbbdbbd8420674f56bdf61fed5dc2653c826a4789c685011012103b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42.
The spent transaction output (txid d0fcb7713582e7cda598d79b3ab084132f93db00e2ccde9bbd1d2660c55abe47 index 33) has as its script pub key 76a914897c81ac37ae36f7bc5b91356cfb0138bfacb3c188ac.
We can interpret this in two ways. Either put the two together into one big script:
$ btcdeb 483045022100c7d8e302908fdc601b125c2734de63ed3bf54353e13a835313c2a2aa5e8f21810220131fad73787989d7fbbdbbd8420674f56bdf61fed5dc2653c826a4789c685011012103b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be4276a914897c81ac37ae36f7bc5b91356cfb0138bfacb3c188ac
btcdeb -- type `btcdeb -h` for start up options
valid script
7 op script loaded. type `help` for usage information
script | stack
-------------------------------------------------------------------+--------
3045022100c7d8e302908fdc601b125c2734de63ed3bf54353e13a835313c2a... |
03b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42 |
OP_DUP |
OP_HASH160 |
897c81ac37ae36f7bc5b91356cfb0138bfacb3c1 |
OP_EQUALVERIFY |
OP_CHECKSIG |Or we can interpret them one at a time, and use the script sig resulting stack as the input stack to the script pub key -- since we only really want the
output, we can pipe the script to btcdeb and it will just print out the results (presuming the script executes cleanly):
$ echo "483045022100c7d8e302908fdc601b125c2734de63ed3bf54353e13a835313c2a2aa5e8f21810220131fad73787989d7fbbdbbd8420674f56bdf61fed5dc2653c826a4789c685011012103b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42" | btcdeb
3045022100c7d8e302908fdc601b125c2734de63ed3bf54353e13a835313c2a2aa5e8f21810220131fad73787989d7fbbdbbd8420674f56bdf61fed5dc2653c826a4789c68501101
03b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42We can then run the script pub key with these two stack entries as arguments:
$ btcdeb 76a914897c81ac37ae36f7bc5b91356cfb0138bfacb3c188ac \
3045022100c7d8e302908fdc601b125c2734de63ed3bf54353e13a835313c2a2aa5e8f21810220131fad73787989d7fbbdbbd8420674f56bdf61fed5dc2653c826a4789c68501101 \
03b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42
btcdeb -- type `btcdeb -h` for start up options
valid script
5 op script loaded. type `help` for usage information
script | stack
-----------------------------------------+-------------------------------------------------------------------
OP_DUP | 03b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42
OP_HASH160 | 3045022100c7d8e302908fdc601b125c2734de63ed3bf54353e13a835313c2a...
897c81ac37ae36f7bc5b91356cfb0138bfacb3c1 |
OP_EQUALVERIFY |
OP_CHECKSIG |
#0001 OP_DUPWe can also be fancy and run the results of the pipe call as argument to the second call,
$ btcdeb 76a914897c81ac37ae36f7bc5b91356cfb0138bfacb3c188ac $(echo "483045022100c7d8e302908fdc601b125c2734de63ed3bf54353e13a835313c2a2aa5e8f21810220131fad73787989d7fbbdbbd8420674f56bdf61fed5dc2653c826a4789c685011012103b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42" | btcdeb)
btcdeb -- type `btcdeb -h` for start up options
valid script
5 op script loaded. type `help` for usage information
script | stack
-----------------------------------------+-------------------------------------------------------------------
OP_DUP | 03b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42
OP_HASH160 | 3045022100c7d8e302908fdc601b125c2734de63ed3bf54353e13a835313c2a...
897c81ac37ae36f7bc5b91356cfb0138bfacb3c1 |
OP_EQUALVERIFY |
OP_CHECKSIG |
#0001 OP_DUPEither way we do it, we end up with the script on the left hand side and the stack on the right hand side. The top-most item in the stack is the top item, and things are "popped off" from top to bottom. The first item here is a public key and the second item is a signature.
We can check the stack directly using the stack command.
btcdeb> stack
<01> 03b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42 (top)
<02> 3045022100c7d8e302908fdc601b125c2734de63ed3bf54353e13a835313c2a2aa5e8f21810220131fad73787989d7fbbdbbd8420674f56bdf61fed5dc2653c826a4789c68501101We can also check the script we're running with print:
btcdeb> print
-> #0001 OP_DUP
#0002 OP_HASH160
#0003 897c81ac37ae36f7bc5b91356cfb0138bfacb3c1
#0004 OP_EQUALVERIFY
#0005 OP_CHECKSIGThe -> arrow shows us the next instruction that is to be executed. If we run step we will perform the OP_DUP command:
btcdeb> step
<> PUSH stack 03b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42
script | stack
-----------------------------------------+-------------------------------------------------------------------
OP_HASH160 | 03b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42
897c81ac37ae36f7bc5b91356cfb0138bfacb3c1 | 03b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42
OP_EQUALVERIFY | 3045022100c7d8e302908fdc601b125c2734de63ed3bf54353e13a835313c2a...
OP_CHECKSIG |
#0002 OP_HASH160Firstly, directly following the command are any PUSH or POP operations done to the stack, listed with some right-indentation and with a <> prefix.
Here we see that 03b... was pushed onto the stack. The right side shows us that the 03b... that was there was duplicated and put on the
stack again at the top.
We can keep stepping through the program and watch as it operates on the stack based on the left hand opcodes.
btcdeb> step
<> PUSH stack 03b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42
script | stack
-----------------------------------------+-------------------------------------------------------------------
OP_HASH160 | 03b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42
897c81ac37ae36f7bc5b91356cfb0138bfacb3c1 | 03b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42
OP_EQUALVERIFY | 3045022100c7d8e302908fdc601b125c2734de63ed3bf54353e13a835313c2a...
OP_CHECKSIG |
#0002 OP_HASH160
btcdeb> step
<> POP stack
<> PUSH stack 897c81ac37ae36f7bc5b91356cfb0138bfacb3c1
script | stack
-----------------------------------------+-------------------------------------------------------------------
897c81ac37ae36f7bc5b91356cfb0138bfacb3c1 | 897c81ac37ae36f7bc5b91356cfb0138bfacb3c1
OP_EQUALVERIFY | 03b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42
OP_CHECKSIG | 3045022100c7d8e302908fdc601b125c2734de63ed3bf54353e13a835313c2a...
#0003 897c81ac37ae36f7bc5b91356cfb0138bfacb3c1
btcdeb>
<> PUSH stack 897c81ac37ae36f7bc5b91356cfb0138bfacb3c1
script | stack
-----------------------------------------+-------------------------------------------------------------------
OP_EQUALVERIFY | 897c81ac37ae36f7bc5b91356cfb0138bfacb3c1
OP_CHECKSIG | 897c81ac37ae36f7bc5b91356cfb0138bfacb3c1
| 03b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42
| 3045022100c7d8e302908fdc601b125c2734de63ed3bf54353e13a835313c2a...
#0004 OP_EQUALVERIFYIn the second step above, the "opcode" was simply a chunk of data. Data is interpreted as a "push" operation of the data itself,
which you can see is what happened here. The next operator is the OP_EQUALVERIFY which checks that the two top items are identical.
Which you can observe that they are, so the operation should succeed. If the two were not identical, it should fail.
EXERCISE: Pop off the top entry, and push some other random data on and step into the data. You should receive an error. Now pop your data off and push 897c81ac37ae36f7bc5b91356cfb0138bfacb3c1 back onto the stack and then try stepping again. It should now succeed. Use the
execcommand to perform operations on-the-fly.
If you step two more times, you will have an error. This is because btcdeb does not know enough to verify
the signature of the transaction (specifically, it needs the transaction itself). We can pass that in to test the
signature verification part as well by grabbing the transaction hex (note: not the txid, we need the entire hex
of the transaction) and including it in the call to btcdeb.
We can get the hex of any transaction by appending ?format=hex to the end of a transaction on
blockchain.info. The transaction here is found at: https://blockchain.info/tx/4de699d05b416175ad7a119013563a0f436abe46c6a52f05bf59baca1b2aec41?format=hex
Restart btcdeb with tx=(hex):
$ ./btcdeb \
tx=010000000247be5ac560261dbd9bdecce200db932f1384b03a9bd798a5cde7823571b7fcd0210000006b483045022100c7d8e302908fdc601b125c2734de63ed3bf54353e13a835313c2a2aa5e8f21810220131fad73787989d7fbbdbbd8420674f56bdf61fed5dc2653c826a4789c685011012103b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42ffffffffc6f5428a05fc20d1aa27c14e1e9bacb07f16d67895d2d48b97792167ad9c7cd1010000006a47304402201b0e1e9e3632740859c1f76dc002af546d28ecca10dbe96f5350fbc8daa3b279022017878fda5c2d47bb03d1554ed4637b554ec63b135df5387a4a32125cda6dd794012103e7cfd3c98952410dd14079e9160f91f968240da2603e25e4b3ef555fc7ed7d09ffffffff030066e9000000000017a9146c52f451a2bc85b815610fa5cd13127cb5c5a7c787c3df5307000000001976a914726d8c8926da39704d60dd401fa4026aa836068e88aca0950100000000001976a91475eac11f3cfda3e79c90469dac0ebaaaacde701488ac00000000 \
76a914897c81ac37ae36f7bc5b91356cfb0138bfacb3c188ac \
3045022100c7d8e302908fdc601b125c2734de63ed3bf54353e13a835313c2a2aa5e8f21810220131fad73787989d7fbbdbbd8420674f56bdf61fed5dc2653c826a4789c68501101 \
03b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42
btcdeb -- type `./btcdeb -h` for start up options
got transaction:
CTransaction(hash=4de699d05b, ver=1, vin.size=2, vout.size=3, nLockTime=0)
CTxIn(COutPoint(d0fcb77135, 33), scriptSig=483045022100c7d8e302908f)
CTxIn(COutPoint(d17c9cad67, 1), scriptSig=47304402201b0e1e9e363274)
CScriptWitness()
CScriptWitness()
CTxOut(nValue=0.15296000, scriptPubKey=a9146c52f451a2bc85b815610fa5cd)
CTxOut(nValue=1.22937283, scriptPubKey=76a914726d8c8926da39704d60dd40)
CTxOut(nValue=0.00103840, scriptPubKey=76a91475eac11f3cfda3e79c90469d)
valid script
5 op script loaded. type `help` for usage information
script | stack
-----------------------------------------+-------------------------------------------------------------------
OP_DUP | 03b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42
OP_HASH160 | 3045022100c7d8e302908fdc601b125c2734de63ed3bf54353e13a835313c2a...
897c81ac37ae36f7bc5b91356cfb0138bfacb3c1 |
OP_EQUALVERIFY |
OP_CHECKSIG |
#0001 OP_DUP
btcdeb> step
[...]
々 step
TransactionSignatureChecker::CheckSig(72 len sig, 33 len pubkey, sigversion=0)
sig = 3045022100c7d8e302908fdc601b125c2734de63ed3bf54353e13a835313c2a2aa5e8f21810220131fad73787989d7fbbdbbd8420674f56bdf61fed5dc2653c826a4789c68501101
pub key = 03b05bdbdf395e495a61add92442071e32703518b8fca3fc34149db4b56c93be42
script code = 76a914897c81ac37ae36f7bc5b91356cfb0138bfacb3c188ac
hash type = 01 (SIGHASH_ALL)
SignatureHash(nIn=0, nHashType=01)
- sigversion = SIGVERSION_BASE (non-segwit style)
Serializing transaction
<< txTo.nVersion (00000001)
<< nInputs = 2 [compact]
(serialize input 0)
<< txTo.vin[nInput=0].prevout = COutPoint(d0fcb77135, 33)
(SerializeScriptCode)
<< scriptCode.size()=25 - nCodeSeparators=0
<< script:76a914897c81ac37ae36f7bc5b91356cfb0138bfacb3c188ac
<< txTo.vin[nInput].nSequence = 4294967295 [0xffffffff]
(serialize input 1)
<< txTo.vin[nInput=1].prevout = COutPoint(d17c9cad67, 1)
<< [empty script] (reason: nInput != nIn)
<< txTo.vin[nInput].nSequence = 4294967295 [0xffffffff]
<< nOutputs = 3 [compact]
(serialize output 0)
<< txTo.vout[nOutput] = CTxOut(nValue=0.15296000, scriptPubKey=a9146c52f451a2bc85b815610fa5cd)
(serialize output 1)
<< txTo.vout[nOutput] = CTxOut(nValue=1.22937283, scriptPubKey=76a914726d8c8926da39704d60dd40)
(serialize output 2)
<< txTo.vout[nOutput] = CTxOut(nValue=0.00103840, scriptPubKey=76a91475eac11f3cfda3e79c90469d)
<< txTo.nLockTime = 0 [0x0]
sighash = 8b2fc7c4b0ce353c524dbd1059f2fcb7355597555e5d840ad5506d9b473923fd
pubkey.Verify(sig=3045022100c7d8e302908fdc601b125c2734de63ed3bf54353e13a835313c2a2aa5e8f21810220131fad73787989d7fbbdbbd8420674f56bdf61fed5dc2653c826a4789c685011, sighash=8b2fc7c4b0ce353c524dbd1059f2fcb7355597555e5d840ad5506d9b473923fd):
- secp256k1_ecdsa_verify() returned success
result: success
<> POP stack
<> POP stack
<> PUSH stack 01
script | stack
-----------------------------------------+-------------------------------------------------------------------
| 01
btcdeb>Sending to a P2PKH address was relatively easy when you were just using bitcoin-cli. Examining the Bitcoin Script underlying it lays bare the cryptographic functions that were implicit in funding that transaction: how the UTXO was unlocked with a signature and a public key.
Continue "Introducing Bitcoin Scripts" with §7.4: Testing a Bitcoin Script.