flywithu/Learning-Bitcoin-from-the-Command-Line
1
1
Fork 0
mirror of https://github.com/ChristopherA/Learning-Bitcoin-from-the-Command-Line.git synced 2025-06-07 16:06:26 +00:00
Code Issues Releases Wiki Activity

revised section for better understanding

Browse Source
This commit is contained in:
Shannon Appelcline 2020-07-21 08:36:29 -10:00 committed by GitHub
parent 57669dd806
commit 4098d55699
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 134 additions and 89 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

223
09_4_Scripting_a_P2PKH.md
View File

@ -8,72 +8,55 @@ P2PKH addresses are quickly fading in popularity due to the advent of SegWit, bu
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 public key linked to the private key and a signature generated by the private key.
That's what the `scriptSig` unlocking script seen in [§9.1](09_1_Understanding_the_Foundation_of_Transactions.md) showed: a `<signature>` and a `<pubKey>`:
Take a look again at the transaction you created in [§9.1](09_1_Understanding_the_Foundation_of_Transactions.md):
```
04402201cc39005b076cb06534cd084fcc522e7bf937c4c9654c1c9dfba68b92cbab7d1022066f273178febc7a37568e2e9f4dec980a2e9a95441abe838c7ef64c39d85849c[ALL] 0315a0aeb37634a71ede72d903acae4c6efa77f3423dcbcd6de3e13d9fd989438b
$ bitcoin-cli -named decoderawtransaction hexstring=$signedtx
{
"txid": "34151dac704d94a269cd33f80be34c122152edc9bfbb9323852966bf0ce937ed",
"hash": "34151dac704d94a269cd33f80be34c122152edc9bfbb9323852966bf0ce937ed",
"version": 2,
"size": 191,
"vsize": 191,
"weight": 764,
"locktime": 0,
"vin": [
{
"txid": "bb4362dec15e67d366088f5493c789f22fb4a604e767dae1f6a631687e2784aa",
"vout": 0,
"scriptSig": {
"asm": "304402201cc39005b076cb06534cd084fcc522e7bf937c4c9654c1c9dfba68b92cbab7d1022066f273178febc7a37568e2e9f4dec980a2e9a95441abe838c7ef64c39d85849c[ALL] 0315a0aeb37634a71ede72d903acae4c6efa77f3423dcbcd6de3e13d9fd989438b",
"hex": "47304402201cc39005b076cb06534cd084fcc522e7bf937c4c9654c1c9dfba68b92cbab7d1022066f273178febc7a37568e2e9f4dec980a2e9a95441abe838c7ef64c39d85849c01210315a0aeb37634a71ede72d903acae4c6efa77f3423dcbcd6de3e13d9fd989438b"
},
"sequence": 4294967295
}
],
"vout": [
{
"value": 0.00090000,
"n": 0,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 06b5c6ba5330cdf738a2ce91152bfd0e71f9ec39 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a91406b5c6ba5330cdf738a2ce91152bfd0e71f9ec3988ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"mg8S7F1gY3ivV9M9GrWwe6ziWvK2MFquCf"
]
}
}
]
}
```
You can see that its `scriptSig` unlocking script has two values. That's a `<signature>` (and an `[all]`) and a `<pubKey>`:
```
304402201cc39005b076cb06534cd084fcc522e7bf937c4c9654c1c9dfba68b92cbab7d1022066f273178febc7a37568e2e9f4dec980a2e9a95441abe838c7ef64c39d85849c[ALL] 0315a0aeb37634a71ede72d903acae4c6efa77f3423dcbcd6de3e13d9fd989438b
```
## Understand the Locking Script
The associated `scriptPubKey` locking script from the previous section was `OP_DUP OP_HASH160 06b5c6ba5330cdf738a2ce91152bfd0e71f9ec39 OP_EQUALVERIFY OP_CHECKSIG`, which is the standard locking methodology used for an older P2PKH address. That long string in the middle is a `<pubKeyHash>`.
Remember that each unlocking script unlocks a previous UTXO. In the above example, the `vin` reveals that it's actually unlocking vout `0` of txif `bb4362dec15e67d366088f5493c789f22fb4a604e767dae1f6a631687e2784aa`.
## Run a P2PKH Script
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 the script says to do!
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` based on the comparison; and `OP_VERIFY` which pops that result and immediately marks the transaction as invalid if it's `False`. (Chapter 12 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. But, they also 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.
### Use btcdeb for a P2PKH Example
Testing out actual Bitcoin transactions with `btcdeb` is a bit trickier, because you need to know the public key and a signature to make everything work, and generating the latter is somewhat difficult. However, one way to test things is to let Bitcoin do the work for you in generating a transaction that will unlock a UTXO. And, we already did that back in [§9.1](09_1_Understanding_the_Foundation_of_Transactions.md).
Remember that each unlocking script fits the locking script of the _previous_ UTXO, so in that section we were building an unlocking script for a transaction to unlock the UTXO with a txid of `bb4362dec15e67d366088f5493c789f22fb4a604e767dae1f6a631687e2784aa` and a vout of `0`. To fully test things out we need to examine the previous UTXO.
You can examine that with `gettransaction`.
```
$ bitcoin-cli gettransaction "bb4362dec15e67d366088f5493c789f22fb4a604e767dae1f6a631687e2784aa"
{
@ -101,7 +84,7 @@ $ bitcoin-cli gettransaction "bb4362dec15e67d366088f5493c789f22fb4a604e767dae1f6
"hex": "020000000001011efcc3bf9950ac2ea08c53b43a0f8cc21e4b5564e205f996f7cadb7d13bb79470000000017160014c4ea10874ae77d957e170bd43f2ee828a8e3bc71feffffff0218730100000000001976a91441d83eaffbf80f82dee4c152de59a38ffd0b602188ac713b10000000000017a914b780fc2e945bea71b9ee2d8d2901f00914a25fbd8702473044022025ee4fd38e6865125f7c315406c0b3a8139d482e3be333727d38868baa656d3d02204b35d9b5812cb85894541da611d5cec14c374ae7a7b8ba14bb44495747b571530121033cae26cb3fa063c95e2c55a94bd04ab9cf173104555efe448b1bfc3a68c8f873342c1b00"
}
```
That `hex` is the raw transaction for the UTXO, so if we save that and decode it, we can see the `scriptPubKey` information.
But as you can see, you didn't get the `scriptPubKey`. You need to take an additional step to retrieve that by examining the raw transaction info (that's the `hex`) with `decoderawtransaction`:
```
$ hex=$(bitcoin-cli gettransaction "bb4362dec15e67d366088f5493c789f22fb4a604e767dae1f6a631687e2784aa" | jq -r '.hex')
$ bitcoin-cli decoderawtransaction $hex
@ -158,35 +141,67 @@ $ bitcoin-cli decoderawtransaction $hex
]
}
```
So, `OP_DUP OP_HASH160 41d83eaffbf80f82dee4c152de59a38ffd0b6021 OP_EQUALVERIFY OP_CHECKSIG` was the locking script for the UTXO, and as we already know from looking at the `scriptSig`, the unlocking script was `304402201cc39005b076cb06534cd084fcc522e7bf937c4c9654c1c9dfba68b92cbab7d1022066f273178febc7a37568e2e9f4dec980a2e9a95441abe838c7ef64c39d85849c[ALL] 0315a0aeb37634a71ede72d903acae4c6efa77f3423dcbcd6de3e13d9fd989438b`.
You can now look at `vout` `0` and see it was locked with the `scriptPubKey` of `OP_DUP OP_HASH160 41d83eaffbf80f82dee4c152de59a38ffd0b6021 OP_EQUALVERIFY OP_CHECKSIG`. That's the standard locking methodology used for an older P2PKH address with the `<pubKeyHash>` stuck in the middle.
Note that we could find that public key ourselves by using `getaddressinfo`:
```
$ bitcoin-cli getaddressinfo mmX7GUoXq2wVcbnrnFJrGKsGR14fXiGbD9
{
"address": "mmX7GUoXq2wVcbnrnFJrGKsGR14fXiGbD9",
"scriptPubKey": "76a91441d83eaffbf80f82dee4c152de59a38ffd0b602188ac",
"ismine": true,
"solvable": true,
"desc": "pkh([f004311c/0'/0'/2']0315a0aeb37634a71ede72d903acae4c6efa77f3423dcbcd6de3e13d9fd989438b)#t3g5mjk9",
"iswatchonly": false,
"isscript": false,
"iswitness": false,
"pubkey": "0315a0aeb37634a71ede72d903acae4c6efa77f3423dcbcd6de3e13d9fd989438b",
"iscompressed": true,
"ischange": false,
"timestamp": 1594835792,
"hdkeypath": "m/0'/0'/2'",
"hdseedid": "f058372260f71fea37f7ecab9e4c5dc25dc11eac",
"hdmasterfingerprint": "f004311c",
"labels": [
""
]
}
```
Figuring out that signature, however, requires generating a transaction and signing it (or really understanding the nuts and bolts of how Bitcoin transactions are created).
Running it will show how it works.
We can put those together the locking script, the signature, and the pubkey using `btcdeb`, showing how simple a P2PKH script is.
## Run a P2PKH Script
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 examinine 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 the script says to do!
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` based on the comparison; and `OP_VERIFY` which pops that result and immediately marks the transaction as invalid if it's `False`. (Chapter 12 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. But, they also 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.
### Use btcdeb for a P2PKH Example
Testing out actual Bitcoin transactions with `btcdeb` is a bit trickier, because you need to know the public key and a signature to make everything work, and generating the latter is somewhat difficult. However, one way to test things is to let Bitcoin do the work for you in generating a transaction that will unlock a UTXO. That's what you've done above, generating a new transaction to let `bitcoin-cli` do the work of calculating the `<signature>` and `<pubKey>` and then looking at the raw transaction information of the UTXO to learn the locking script including the `<pubKeyHash>`
You can put together the locking script, the signature, and the pubkey using `btcdeb`, showing how simple a P2PKH script is.
```
$ btcdeb '[304402201cc39005b076cb06534cd084fcc522e7bf937c4c9654c1c9dfba68b92cbab7d1022066f273178febc7a37568e2e9f4dec980a2e9a95441abe838c7ef64c39d85849c 0315a0aeb37634a71ede72d903acae4c6efa77f3423dcbcd6de3e13d9fd989438b OP_DUP OP_HASH160 41d83eaffbf80f82dee4c152de59a38ffd0b6021 OP_EQUALVERIFY OP_CHECKSIG]'
btcdeb 0.2.19 -- type `btcdeb -h` for start up options
@ -316,10 +331,40 @@ OP_CHECKSIG | 0315a0aeb37
#0006 OP_CHECKSIG
btcdeb> step
error: Signature is found in scriptCode
[[NOTE: THIS CURRENTLY HAS SOME ERRORS IN THE OUTPUT AND THE CHECKSUM]]
[[NOTE: THIS CURRENTLY HAS SOME MESS IN THE OUTPUT AND THE CHECKSUM]]
```
If you read through that you can see the usage of elements like the `OP_DUP` to duplicate the hash for testing, and how that result is then pushed out of the way to test out the signature. As is shown, a P2PKH is quite simple: its protection comes about those the strength of its cryptography.
### How to Look Up a Pub Key & Signature by Hand
What if you wanted to generate the <signature> and <PubKey> information yourself, without leaning on `bitcoin-cli` to create a transaction.
It turns out that it's pretty easy to get a `<pubKey>` You just need to use `getaddressinfo` to examine the address where the UTXO is currently sitting:
```
$ bitcoin-cli getaddressinfo mmX7GUoXq2wVcbnrnFJrGKsGR14fXiGbD9
{
"address": "mmX7GUoXq2wVcbnrnFJrGKsGR14fXiGbD9",
"scriptPubKey": "76a91441d83eaffbf80f82dee4c152de59a38ffd0b602188ac",
"ismine": true,
"solvable": true,
"desc": "pkh([f004311c/0'/0'/2']0315a0aeb37634a71ede72d903acae4c6efa77f3423dcbcd6de3e13d9fd989438b)#t3g5mjk9",
"iswatchonly": false,
"isscript": false,
"iswitness": false,
"pubkey": "0315a0aeb37634a71ede72d903acae4c6efa77f3423dcbcd6de3e13d9fd989438b",
"iscompressed": true,
"ischange": false,
"timestamp": 1594835792,
"hdkeypath": "m/0'/0'/2'",
"hdseedid": "f058372260f71fea37f7ecab9e4c5dc25dc11eac",
"hdmasterfingerprint": "f004311c",
"labels": [
""
]
}
```
Figuring out that signature, however, requires really understanding the nuts and bolts of how Bitcoin transactions are created. So we leave that as advanced study for the reader: creating a transaction to "solve" a UTXO is the best solution to that for the moment.
## Summary: Scripting a Pay to Public Key Hash
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.