From 69eddac103899e0e51b39cdf71aba518488d9e61 Mon Sep 17 00:00:00 2001 From: Shannon Appelcline Date: Fri, 12 May 2017 16:09:39 -0700 Subject: [PATCH] Update 7_2_Running_a_Bitcoin_Script.md --- 7_2_Running_a_Bitcoin_Script.md | 64 ++++++++++++++++----------------- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/7_2_Running_a_Bitcoin_Script.md b/7_2_Running_a_Bitcoin_Script.md index 31ded41..fb0b6a7 100644 --- a/7_2_Running_a_Bitcoin_Script.md +++ b/7_2_Running_a_Bitcoin_Script.md @@ -24,14 +24,14 @@ _What is a stack?_ A stack is a LIFO (last-in-first-out) data structure. It has Whenever Bitcoin Script encounters a constant, it's pushed onto the Stack. So the above example of `1 2 OP_ADD1` would actually look like this as it was processed: ``` -*Script:* 1 2 OP_ADD -*Stack:* [ ] +Script: 1 2 OP_ADD +Stack: [ ] -*Script:* 2 OP_ADD -*Stack:* [ 1 ] +Script: 2 OP_ADD +Stack: [ 1 ] -*Script:* OP_ADD -*Stack:* [ 1 2 ] +Script: OP_ADD +Stack: [ 1 2 ] ``` _Note that in this and in following examples the top of the stack is to the right and the bottom is to the left._ @@ -41,31 +41,31 @@ So in this paradigm, what do opcodes do? They pop zero or more elements off the OP_ADD pops two items off the stack (here: 2 then 1), adds then, and then pushes the resul (here: 3). ``` -*Script:* -*Stack:* [ 3 ] +Script: +Stack: [ 3 ] ``` ## Run a Simple Script Here's an example of a more complex script. It shows how operators continue to interact with the Stack, not just with the operands right before them: ``` -*Script:* 3 2 OP_ADD 4 OP_SUB -*Stack:* [ ] +Script: 3 2 OP_ADD 4 OP_SUB +Stack: [ ] -*Script:* 2 OP_ADD 4 OP_SUB -*Stack:* [ 3 ] +Script: 2 OP_ADD 4 OP_SUB +Stack: [ 3 ] -*Script:* OP_ADD 4 OP_SUB -*Stack:* [ 3 2 ] +Script: OP_ADD 4 OP_SUB +Stack: [ 3 2 ] -*Script:* 4 OP_SUB -*Stack:* [ 5 ] +Script: 4 OP_SUB +Stack: [ 5 ] -*Script:* OP_SUB -*Stack:* [ 5 4 ] +Script: OP_SUB +Stack: [ 5 4 ] -*Script:* -*Stack:* [ 1 ] +Script: +Stack: [ 1 ] ``` ## Understand the Usage of Bitcoin Script @@ -79,23 +79,23 @@ As we've seen, every input for a Bitcoin transaction conttains a `scriptSig` whi So, presume that a UTXO were locked with a `scriptPubKey` that read `100 OP_EQUAL` and that the `scriptSig` `1 99 OP_ADD` were run to unlock it. The two scripts would efectively be run in order as `1 99 OP_ADD 100 OP_EQUAL` and the following were occur: ``` -*Script:* 1 99 OP_ADD 100 OP_EQUAL -*Stack:* [] +Script: 1 99 OP_ADD 100 OP_EQUAL +Stack: [] -*Script:* 99 OP_ADD 100 OP_EQUAL -*Stack:* [1] +Script: 99 OP_ADD 100 OP_EQUAL +Stack: [1] -*Script:* OP_ADD 100 OP_EQUAL -*Stack:* [1 99] +Script: OP_ADD 100 OP_EQUAL +Stack: [1 99] -*Script:* 100 OP_EQUAL -*Stack:* [100] +Script: 100 OP_EQUAL +Stack: [100] -*Script:* OP_EQUAL -*Stack:* [100 100] +Script: OP_EQUAL +Stack: [100 100] -*Script:* -*Stack:* [TRUE] +Script: +Stack: [TRUE] ``` This abstraction isn't quite true. For security reasons, the `scriptSig` is run, then the contents of the stack are transferred for the `scriptPubKey` to run, but it's correct enough for understanding how the key of `scriptSig` fits into the lock of `scriptPubKey`.