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-11-04 04:17:43 +00:00
Code Issues Releases Wiki Activity

Update 7_2_Running_a_Bitcoin_Script.md

Browse Source
This commit is contained in:
Shannon Appelcline 2017-05-12 16:09:39 -07:00 committed by GitHub
parent f378eaa7ee
commit 69eddac103
1 changed files with 32 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
7_2_Running_a_Bitcoin_Script.md
View File

@ -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: 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 <b>Script:</b> 1 2 OP_ADD
*Stack:* [ ] <b>Stack:</b> [ ]
*Script:* 2 OP_ADD <b>Script:</b> 2 OP_ADD
*Stack:* [ 1 ] <b>Stack:</b> [ 1 ]
*Script:* OP_ADD <b>Script:</b> OP_ADD
*Stack:* [ 1 2 ] <b>Stack:</b> [ 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._ _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). OP_ADD pops two items off the stack (here: 2 then 1), adds then, and then pushes the resul (here: 3).
``` ```
*Script:* <b>Script:</b>
*Stack:* [ 3 ] <b>Stack:</b> [ 3 ]
``` ```
## Run a Simple Script ## 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: 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 <b>Script:</b> 3 2 OP_ADD 4 OP_SUB
*Stack:* [ ] <b>Stack:</b> [ ]
*Script:* 2 OP_ADD 4 OP_SUB <b>Script:</b> 2 OP_ADD 4 OP_SUB
*Stack:* [ 3 ] <b>Stack:</b> [ 3 ]
*Script:* OP_ADD 4 OP_SUB <b>Script:</b> OP_ADD 4 OP_SUB
*Stack:* [ 3 2 ] <b>Stack:</b> [ 3 2 ]
*Script:* 4 OP_SUB <b>Script:</b> 4 OP_SUB
*Stack:* [ 5 ] <b>Stack:</b> [ 5 ]
*Script:* OP_SUB <b>Script:</b> OP_SUB
*Stack:* [ 5 4 ] <b>Stack:</b> [ 5 4 ]
*Script:* <b>Script:</b>
*Stack:* [ 1 ] <b>Stack:</b> [ 1 ]
``` ```
## Understand the Usage of Bitcoin Script ## 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: 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 <b>Script:</b> 1 99 OP_ADD 100 OP_EQUAL
*Stack:* [] <b>Stack:</b> []
*Script:* 99 OP_ADD 100 OP_EQUAL <b>Script:</b> 99 OP_ADD 100 OP_EQUAL
*Stack:* [1] <b>Stack:</b> [1]
*Script:* OP_ADD 100 OP_EQUAL <b>Script:</b> OP_ADD 100 OP_EQUAL
*Stack:* [1 99] <b>Stack:</b> [1 99]
*Script:* 100 OP_EQUAL <b>Script:</b> 100 OP_EQUAL
*Stack:* [100] <b>Stack:</b> [100]
*Script:* OP_EQUAL <b>Script:</b> OP_EQUAL
*Stack:* [100 100] <b>Stack:</b> [100 100]
*Script:* <b>Script:</b>
*Stack:* [TRUE] <b>Stack:</b> [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`. 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`.