From bdca6810af867ef689c8a08d6cc9087f66b0cf68 Mon Sep 17 00:00:00 2001
From: katesalazar <52637275+katesalazar@users.noreply.github.com>
Date: Sat, 26 Jun 2021 20:36:07 +0200
Subject: [PATCH] Update 2021-06-21-blockchain.markdown

---
 _posts/2021-06-21-blockchain.markdown | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/_posts/2021-06-21-blockchain.markdown b/_posts/2021-06-21-blockchain.markdown
index 1d09a678..4a48b9ff 100644
--- a/_posts/2021-06-21-blockchain.markdown
+++ b/_posts/2021-06-21-blockchain.markdown
@@ -926,7 +926,14 @@ OP_CHECKSIG
 
 This is where things get a bit crazy with Bitcoin. It has a whole stack-based scripting language, but unless you're doing crazy multisig smart contract triple escrow backflips (?), the vast majority of transactions use one of very few simple "special case" scripts, just like the one here. By now my eyes just glaze over it as the standard simple thing. This "Pkscript" is the "locking script" for this specific Output, which holds 0.001 BTC in it. We are going to want to spend this Output and turn it into an Input in our upcoming transaction. In order to unlock this output we are going to have to satisfy the conditions of this locking script. In English, this script is saying that any Transaction that aspires to spend this Output must satisfy two conditions. 1) their Public key better hash to 4b3518229b0d3554fe7cd3796ade632aff3069d8. And 2) the digital signature for the aspiring transaction better validate as being generated by this public key's associated private key. Only the owner of the secret key will be able to both 1) provide the full public key, which will be checked to hash correctly, and 2) create the digital signature, as we'll soon see.
 
-By the way, we can verify that of course our public key hashes correctly, so we'll be able to include it in our upcoming transaction, and the all of the mining nodes will be able to verify condition (1). Very early Bitcoin transactions had locking scripts that directly contained the public key (instead of its hash) followed by OP_CHECKSIG, but doing it in this slightly more complex way protects the exact public key behind the hash, until the owner wants to spend the funds, only then do they reveal the public key. (If you'd like to learn more look up p2pk vs p2pkh transactions).
+By the way, we can verify that of course our public key hashes correctly, so
+we'll be able to include it in our upcoming transaction, and then all of the
+mining nodes will be able to verify condition (1). Very early Bitcoin
+transactions had locking scripts that directly contained the public key
+(instead of its hash) followed by OP_CHECKSIG, but doing it in this slightly
+more complex way protects the exact public key behind the hash, until the owner
+wants to spend the funds, only then do they reveal the public key. (If you'd
+like to learn more look up p2pk vs p2pkh transactions).
 
 
 ```python