The aim of this guide to help you understand the logic behind  Bitcoin Script. Since there will be too much to cover, the guide will be divided into two parts.

Bitcoin was created for one purpose alone…transactions. Bitcoin was able to show the world that a payment system can exist on a decentralized peer-to-peer system. However, what goes on behind the scenes of these transactions? Behind every little transaction, there is some code working in the background. This code is the Bitcoin Scripting Language or just Bitcoin  Script for short.

The Best Bitcoin Script Guide

Introduction to  Bitcoin Script

Script is a Forth-like, stack-based, reverse-polish, Turing Incomplete language. Yes, that sounds very complicated, but it really isn’t. Let’s go through each and every term from reverse.

Turing Incomplete

A Turing Incomplete language will have limited functionality and not be capable of making jumps and/or loops. Hence they can’t enter an endless loop. Being Turing Complete means that given the resources and memory, a Turing Complete program will be able to solve any problem. Solidity is an example of a Turing Complete language.

So why isn’t  Bitcoin Script Turing Complete?

Because it doesn’t need to be.  Bitcoin Script doesn’t need to be as complicated as an Ethereum smart contract. In fact, if a script was Turing Complete, it would have given malicious parties the freedom to create complicated transactions and eat up the hash-rate of the Bitcoin Network and slow down the entire system.

Reverse Polish

Reverse polish notation is a system where the operators follow the operands.

Meaning:

• 3+4 will appear as 34+.
• So, for longer more complicated sums:
• 5*3+4 will appear as +*.

Stack Based

Stacks are one of the most popular data structures out there. According to Wikibooks, they can be logically thought of as linear structure represented by a real physical stack or pile, a structure where insertion and deletion of items take place at one end called top of the stack.

The basic idea of stack is LIFO or Last In First Out. Consider the following stack of books:

What was the first book that was put on this stack? Lone Wolf & Cub right? What was the last book? Gardens of the Moon.

If one were to take out a book from this stack, Lone Wolf & Cub won’t be the book you take out first, Gardens of the Moon will be the first you take out.

Hence, Last In First Out.

The Last book that went on this stack pile will be the first book taken out.

Now, there are two stack operations that you need to know about:

Push: The act of adding things into the stack is called pushing.

Pop: The act of removing things from the stack is called popping. As has been mentioned before, the last item which got pushed into the stack gets popped out first.

Image Credit: Wikimedia

Forth-Like

This one is pretty straight-forward.  Bitcoin Script happens to resemble the programming language “Forth” which also happens to be stack-based.

So, now we at least know what script is, let’s understand how Transactions work.

How do transactions in a Bitcoin work?

Before we continue, a huge shoutout to Professor Donald J Patterson and his Youtube channel “djp3” for the explanation.

Suppose Alice wants to send a certain number of bitcoins to Bob. How does the transaction system in bitcoin work? bitcoin transactions are very different from Fiat wallet transactions. If Alice was to give $2 to Bob, she would physically take 2 dollars from her wallet and give it to Bob. However, things don’t work like that in bitcoin. You don’t physically own any bitcoin, what you have is the proof that you have Bitcoins.

There are two more things that you need to know:

• The miners validate your transactions by putting the data inside the mines that they have blocked. In return for giving this service, they charge a transaction fee.

• When it comes to FIAT currency, you don’t really keep track of how and where you got that specific note from. Eg. Open your wallet right now and take out all the notes and coins in it. Can you tell where exactly did you get each and every specific note and coin from? Chances are that you don’t. However, in bitcoin, the history of each and every single bitcoin transaction is taken note of.

Ok, so now let’s do a deep dive into how a bitcoin transaction between Alice and Bob takes place. There are two sides to a transaction, the Input, and the Output. This entire Transaction will have a name that we will figure out in the end. For now, let’s look at the dynamics.

Transaction Input

In order to make this transaction happen, Alice needs to get bitcoins which she has received from various previous transactions. Remember, like we said before, in bitcoins, each and every coin is accounted for via a transaction history.

So, suppose Alice needs to pull bitcoins from the following transactions which we shall name TX(0), TX(1) and TX(2). These three transactions will be added together and that will give you the input transaction which we shall call TX(Input).

Diagrammatically, it will look like this:

So, that is it from the input side, let’s check out what the output side will look like.

Transaction Output

The output basically will have the number of bitcoins that Bob will possess, post-transaction and any remaining change that is left over, which is then sent back to Alice. This change then becomes her input value for all future transactions.

A pictorial representation of the output side looks like this:

Now, this is a very simple transaction that has just one output (apart from the CHANGE), there are transactions that are possible with multiple outputs.

This is what the basic layout of the transaction looks like. For this entire thing to go through, however, certain conditions must be met.

Conditions of a transaction

• TX(Input) > TX(output). The input transaction has to be always greater than the output transaction. In any transaction, the deficit between the input and the output (output+change) is the transaction fees that miners collect. So:
  
  Transaction fees = TX(Input) – (TX(output) + Change).
• In the input side:
  
  TX(0) + TX(1) + TX(2) = TX(Input).
  
  If Alice doesn’t have the funds necessary to carry out the transactions then the miners will simply reject the transactions.

• Bob will have to show that he can provide the proof needed to get the bitcoins. Alice will lock the transactions with Bob’ public address. He will need to produce his private key to unlock the transactions and gain access to his fees.

• Alice also needs to verify that she has the required rights to send over the bitcoins in the first place. The way she does that is by signing off the transaction with her digital signature (aka her private key). Anyone can decode this by using her public key and verify that it was indeed Alice who sent over the data. This proof is called “Signature data”. Remember this because this will be very important later on.

So, what is going to be the name of this entire transaction?

The Input (including the signature data) and the output data is added together and hashed using the SHA hashing algorithm. The output hash is the name that is given to this transaction.

So, now lets a look behind the scenes and see what the transaction actually looks like.

The bitcoin Script Transaction: Behind the Scenes

This is what the transaction looks like in the code form.

Suppose Alice wants to send BTC to Bob and in order to do so, she sends inputs which are worth BTC. This is what the transaction detail looks like:

Image courtesy: djp3 youtube channel.

The first line you see:

Is the name of the Transaction aka the hash of the input and output value.

Vin_sz is the number of input data since Alice is sending the data using only one of her previous transactions, it is 1.

Vout_sz is 2 because the only outputs are Bob and the change.

This is the Input data:

See the input data? Alice is only using one input transaction (in the example that we gave above, this will be TX(0)), this is the reason why vin_sz was 1.

Below the input data is her signature data.

Underneath all this is the output data:

The first part of the data signifies that Bob is getting BTC.

The second part signifies that BTC is what Alice is getting back as change.

Now, remember that out input data was BTC? This is greater than ( + ). The deficit of these two values is the transaction fee that the miners are collecting.

A Closer Look at Transaction Outputs

As we have seen above, every input in a transaction turns into outputs, some of these outputs are spent, while some are unspent and becomes change. This change is also known as UTXO or Unspent Transaction Output. UTXO goes on to become Inputs in future transactions.

Every transaction output consists of two parts:

• The value of that output.

• The cryptographic puzzle which either called a locking script, or a witness script or a scriptPubKey. The puzzle needs to be unlocked in order to spend the money. This puzzle is coded using the bitcoin Script language.

So, let’s examine the outputs of a transaction to identify the above-mentioned parts in it. Code taken from Andreas M. Antonopoulos. “Mastering bitcoin.”

Alright, so we have two outputs in the code given above.

One output has a value of BTC while the other has a value of BTC. In order to unlock the value of , the locking script that one needs to unlock goes like this:

“scriptPubKey”: “OP_DUP OP_HASH abc3dbd2f7b92a94ef5d50fe7 OP_EQUALVERIFY OP_CHECKSIG”

An Even Closer Look at Transaction Inputs

Now let’s looks at the other side of the coin, the transaction inputs.

In order to do an Input, the user’s wallet goes through their UTXOs and selects the ones which have enough value for the transaction to go through.

Eg. if Alice wants to send BTC to Bob and here UTXO set looks like this:

• UTXO A = BTC
• UTXO B = BTC
• UTXO C = BTC

Which UTXOs will be chosen for this transaction? That ‘s correct, A and B will be chosen, and whatever is left over will become the UTXO for Alice’s next transaction.

Now, let’s look at an input code.

Let’s see what each part of the input script includes:

• txid: The transaction ID refers the transaction from which this UTXO was generated. This helps keep track of the transaction

• vout: This refers to which output from that transaction is being used. Eg. if that transaction had two UTXOs the first one will be labeled 0(because as we have seen before, counting starts from 0 and not 1) and the second one will be labeled 1. In this case, we are using the first UTXO conwaytransport.com.au 0.

• scriptSig: As we have mentioned before, each UTXO contains a locking script. The scriptSig includes the data necessary to unlock the data.

• sequence: Was included to help people update their transactions before they are confirmed and finalized in a block, Not really that relevant to help understand the basics.

Serialization of Transactions

Now let’s bring of this together and see what we have. When a transaction is relayed over a network, they are serialized. As Andreas Antonopoulos says,

“Serialization is the process of converting the internal representation of a data structure into a format that can be transmitted one byte at a time, also known as a byte stream.”

In the previous two sections, we saw a simple one input and one output transaction. if we were to serialize it and store it in hexadecimal format, what would it look like?

f9fa5aa6fe51dda14d8a0f1a8add73 4dfe65fabdda3f47 baecbbfbdab1deccbbc75c4ae24cbb9f ff08df09cbe9f6addaccadaea8fc09db8f6e ecc0d46fbfa0e4ed99f16a0fb4fdee7ade84 16ab9feccdeceee41c04fde5cc1 7b4a10faa8dadfffffffffeaab6 c3dbd2f7b92a94ef5d50feacd0ef af9b1a7fb68d60cc2fd8aeaa53a8f3ccaac

Yup, this author didn’t accidentally bang his head on the keyboard here… that’s what it actually looks like.

However, don’t get scared. We will make sense of it soon enough. Somewhere in that hexadecimal stream, we have out input data and our output data. Let’s find both of them!

The Output Serialization

The serialization of the output part of the transaction contains the following parts:

Image Credit: Andreas Antonopoulos “Mastering Bitcoin”

Now, what data about the output do we actually know?

• There are two output values.

• One output value is worth BTC or 1,, satoshis

• In hexadecimal 1,, is 16 e3 60, which when coded in little-endian i.e. least significant byte first notation gives 60 e3

• The scriptPubKey length is 25 bytes, which is 19 in hexadecimal.

So, take note of these pieces of information, let’s search for our output data.

f9fa5aa6fe51dda14d8a0f1a8add73 4dfe65fabdda3f47 baecbbfbdab1deccbbc75c4ae24cbb9f ff08df09cbe9f6addaccadaea8fc09db8f6e ecc0d46fbfa0e4ed99f16a0fb4fdee7ade84 16ab9feccdeceee41c04fde5cc1 7b4a10faa8dadfffffffff0260eaab6 c3dbd2f7b92a94ef5d50feacd0ef af9b1a7fb68d60cc2fd8aeaa53a8f3ccaac

The Input Serialization

The input serialization contains the following components:

Now can you locate the input of her transaction?

f9fa5aa6fe51dda14d8a0f1a8add73 4dfe65fabdda3f47 baecbbfbdab1deccbbc75c4ae24cbb9f ff08df09cbe9f6addaccadaea8fc09db8f6e ecc0d46fbfa0e4ed99f16a0fb4fdee7ade84 16ab9feccdeceee41c04fde5cc1 7b4a10faa8dadfffffffffeaab6 c3dbd2f7b92a94ef5d50feacd0ef af9b1a7fb68d60cc2fd8aeaa53a8f3ccaac

Alright, so what have we seen so far?

• The outputs of a transaction and the UTXOs.
• The inputs of a transaction.
• How the entire transaction is being serialized.

Now, we know that UTXOs can only be used if they are unlocked. We know that input values have scriptSig which helps unlock them. How do they interact with each other?

Before we get to that though, we should have an idea of how calculations and operations happen in a bitcoin script.

How Does the Script Work?

Before we continue with Script, it will be helpful to understand how a stack-based, reverse-polish system works.

Simple Addition in a Stack-based Reverse-polish System

As we have said before 3+4 in reverse-polish will look like 34+, let’s execute the addition operation using a stack.

That’s how a simple addition operation gets done on the stack. Now that this is done, how would this look like if it were a script?

OP_3 OP_4 OP_ADD

Just the appearance changes, the rest of the operation remains the same as shown above. The “OP_” prefix is a signature of the Script language.

If you want a primer on the different Opcodes that are used in a script then click here.

Simple Addition Using Bitcoin Script with a Check

Now suppose we want to do 2+3=5.

In Reverse Polish it will look like 23+5=.

In script notation it will look like this:

OP_2 OP_3 OP_ADD OP_5 OP_EQUAL

Now, what would have happened if we used the postfix VERIFY in EQUAL? Meaning, instead of OP_EQUAL we used OP_EQUALVERIFY?

The moment you add the VERIFY suffix, TRUE or FALSE doesn’t get pushed on the stack, instead, the script continues executing if TRUE or it stops executing if it is FALSE.

This is what happens when you append “VERIFY” to an opcode. Keep this in mind for future examples.

Alright, let’s take one last example.

Simple Duplication in the Script

We are taking this example just to introduce you to an extremely important opcode, DUP aka duplicate.

Let’s, we want to push a number into a stack, duplicate it, and see if the two numbers are same or not (which it obviously will be).

We are going to use this script:

OP_5 OP_DUP OP_EQUALVERIFY

Alright, now you have an idea of how calculations get processed in bitcoin Script, let’s continue with our transactions and see how they get executed.

The Game of Locking and Unlocking

Transactions in bitcoin are a constant game of locking and unlocking. The UTXOs are locked up by the scriptPubKey while the inputs of the transaction contain the scriptSig. The idea of scriptPubKey is to offer a cryptographic puzzle which can only be unlocked via the corresponding scriptSig.

So, what exactly happens and how is this game played?

Suppose, Alice wants to send Bob some bitcoin. Bob’s public address is common knowledge and she will send her Bitcoins to Bob’s public address along with a condition, Bob must prove that it is indeed him who is getting the bitcoin.

Now, let’s go back for a bit, and revisit some basic concepts.

Everyone in bitcoin has two keys:

The public key is cryptographically derived from the private key.

Now, in order to get money sent to them, everyone must have a public address. The public is run through two hashing algorithms, SHA and RIPEMD The reason why we do this is to make sure that you have an extra layer of protection, IF in the case that someone somehow figures out how to generate your private key using your public key (which is infeasible).

Note: The public key first goes through SHA to give a bit output hash, and then that hash is run through RIPEMD which gives a bit output hash. So, the final output is a bit hash.

Alright, so Alice will send the money to Bob’s public address along with a condition that Bob must show a proof, that it is indeed him who have gotten the money.

The proof that Bob uses to unlock the funds is his Digital Signature, which cryptographically derived from his private key.

Think of the transactions that Alice sends Bob as a locked chest, and Bob’s signature as the passcode.

Now, getting back to our script.

Alice sends Bob an output which has the scriptPubKey, which includes Bob’s address.

Bob unlocks the input using his signature of scriptSig which includes his signature and his public key.

So, how do we represent this in code?

scriptPubKey = OP_DUP OP_HASH <Bob’s public address> OP_EQUALVERIFY OP_CHECKSIG.

Note: How OP_HASH and OP_CHECKSIG works will be clear to you soon.

scriptSig = <Bob’s signature> <Bob’s public key>

In order to unlock the output and use his funds Bob concatenates or kinda joins the scriptSig and the scriptPubKey like this:

Image Credit: CryptoCompare

Alright, now let’s see how the script works to give poor Bob access to his funds. The script right now looks like this:

<Bob’s signature> <Bob’s public key> OP_DUP OP_HASH <Bob’s public address> OP_EQUALVERIFY OP_CHECKSIG.

Script Implementation of the Unlocking/Verification Process

Ok, now let’s see how the script implementation of the entire verification/unlocking process works.

Right now, the code looks like this

The OP_CHECKSIG pops out <Bob’s public key> and <Bob’s signature> and checks to see their validity to know that they are valid signatures and public addresses.

When this entire process is done, Bob can unlock the transaction and gets access to his funds.

Congratulations! You just went through an entire bitcoin transaction!

What you see here is the most common type of bitcoin transaction:  The P2PKH aka The pay to public key hash.

So, what is this mysterious CHECKSIG operator and how does it work? Well, for that we need to look at the cryptography behind bitcoin.

How does CHECKSIG work?

In order to know how CHECKSIG works, we will need to know what a digital signature is. A digital signature is a digital code (generated and authenticated by public key encryption) which is attached to an electronically transmitted document to verify its contents and the sender’s identity.

The digital signature algorithm used by bitcoin is ECDSA or the Elliptical Curve Digital Signature Algorithm.

Elliptical curve cryptography is what is used by bitcoin, ethereum etc. for their encryption purposes. So what is an elliptical curve? An elliptical curve is any curve that satisfies the following equation:

Y^2 = x^3 + ax + b

Where (x,y) is a point on the curve and a and b are constants.

There are infinite curves that you can make. The following is how one of these curves, in general, look like: