From 4cee290032139d4d322ef0363b5e24f08206b761 Mon Sep 17 00:00:00 2001 From: Shannon Appelcline Date: Wed, 15 Jul 2020 13:33:01 -1000 Subject: [PATCH] Update 09_4_Scripting_a_P2PKH.md --- 09_4_Scripting_a_P2PKH.md | 460 ++++++++++++++++++++------------------ 1 file changed, 246 insertions(+), 214 deletions(-) diff --git a/09_4_Scripting_a_P2PKH.md b/09_4_Scripting_a_P2PKH.md index f87bba4..0f59e15 100644 --- a/09_4_Scripting_a_P2PKH.md +++ b/09_4_Scripting_a_P2PKH.md @@ -1,19 +1,21 @@ -# 7.3: Scripting a P2PKH +# 9.4: Scripting a P2PKH > :information_source: **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. +P2PKH addresses are quickly fading in popularity due to the advent of SegWit, but nonetheless they remain a great building block for understanding Bitcoin, and especially for understanding Bitcoin scripts. (We'll take a quick look at how Segwit-native P2WPKH scripts work differently in the next section.) ## 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 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. +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 the previous section showed, a ` `: -`3045022100c4ef5b531061a184404e84ab46beee94e51e8ae15ce98d2f3e10ae7774772ffd02203c546c399c4dc1d6eea692f73bb3fff490ea2e98fe300ac6a11840c7d52b6166[ALL] 0319cd3f2485e3d47552617b03c693b7f92916ac374644e22b07420c8812501cfb`. +That's what the `scriptSig` unlocking script seen in [§9.1](09_1_Understanding_the_Foundation_of_Transactions.md) showed: a `` and a ``: +``` +04402201cc39005b076cb06534cd084fcc522e7bf937c4c9654c1c9dfba68b92cbab7d1022066f273178febc7a37568e2e9f4dec980a2e9a95441abe838c7ef64c39d85849c[ALL] 0315a0aeb37634a71ede72d903acae4c6efa77f3423dcbcd6de3e13d9fd989438b +``` ## Understand the Locking Script -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 ``. +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 ``. ## Run a P2PKH Script @@ -38,7 +40,7 @@ Script: OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG Running: OP_DUP Stack: [ ] ``` -Why the duplicate? Because that's what's required by the script! +Why the duplicate? Because that's what the script says to do! Next, `OP_HASH160` pops the `` off the stack, hashes it, and puts the result back on the stack. ``` @@ -51,7 +53,7 @@ Then, you place the `` that was in the locking script on the stack: Script: OP_EQUALVERIFY OP_CHECKSIG Stack: [ ] ``` -`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` 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 `es` are equal, you will have the following result: ``` @@ -59,7 +61,7 @@ Script: OP_CHECKSIG Running: OP_EQUALVERIFY Stack: [ ] ``` -At this point you've proven that the `` 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. +At this point you've proven that the `` 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: OP_CHECKSIG @@ -67,226 +69,256 @@ Stack: [ True ] ``` The Script now ends and the transaction is allowed to respend the UTXO in question. +### Use btcdeb for a P2PKH Example -## Running through a real 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). -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 - -```Bash -$ btcdeb