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-08 08:26:17 +00:00
Code Issues Releases Wiki Activity

Update 7_3_Scripting_a_P2PKH.md

Browse Source
This commit is contained in:
Shannon Appelcline 2017-05-22 11:10:57 -07:00 committed by GitHub
parent e9d9881f97
commit 0061ad1685
1 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
7_3_Scripting_a_P2PKH.md
View File

@ -6,9 +6,9 @@ With a basic understanding of Bitcoin Scripting in hand, you can now easily anal
## Understand the Unlocking 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 set up so that it requires the redeemer to have the private key associated with the the public-key hash Bitcoin address. To be precise, the redeemer must supply a signature generated by the private key and the actual public key.
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 redeemer to have the private key associated with the the P2PKH Bitcoin address. To be precise, the redeemer must supply both the actual public key and a signature generated by the private key.
That's what the `scriptSig` unlocking script in the previous section showed, a `<signature> <pubKey>`:
That's what the `scriptSig` unlocking script seen in the previous section showed, a `<signature> <pubKey>`:
`3045022100c4ef5b531061a184404e84ab46beee94e51e8ae15ce98d2f3e10ae7774772ffd02203c546c399c4dc1d6eea692f73bb3fff490ea2e98fe300ac6a11840c7d52b6166[ALL] 0319cd3f2485e3d47552617b03c693b7f92916ac374644e22b07420c8812501cfb`.
## Understand the Locking Script
@ -21,9 +21,9 @@ When you unlock a P2PKH UTXO, you (effectively) concatenate the unlocking and lo
```
Script: <signature> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
```
Here's how it runs:
Now, you can evaluate how the P2PKH UTXO is unlocked.
First, the script puts the initial constants on the stack and makes a duplicate of the pubKey:
First, you put the initial constants on the stack and make a duplicate of the pubKey:
```
Script: <signature> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Stack: [ ]
@ -39,30 +39,30 @@ 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.
Next, your `OP_HASH160` pops the `<pubKey>` off the stack, hashes it, and puts the result back on the stack.
```
Script: <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Stack: [ <signature> <pubKey> <pubKeyHash> ]
```
Then, another constant is put on the stack:
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.)
`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, we now have the following situation:
Assuming the two `<pubKeyHash>es` are equal, you will have the following result:
```
Script: OP_CHECKSIG
Stack: [ <signature> <pubKey> ]
```
At this point we've proven that the `<pubKey>` supplied in the `scriptSig` hashes to the Bitcoin address in question, so we 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.
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:
Stack: [ True ]
```
At this point, the Script ends and the transaction is allowed to respend the UTXO in question.
The Script now ends and the transaction is allowed to respend the UTXO in question.
## 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 UTXOs were unlocked with a signature and a public key; and how the new transaction output was in turn locked with a new 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 UTXOs were unlocked with a signature and a public key.