what is bitcoin script

bitcoin script

 In the last discussion, we have looked into a little detail about the bitcoin basic-2 transactions and how we make a transaction of certain bitcoin from one account that is characterized by an address.

 from one bitcoin address to another bitcoin address now in this particular discussion we will look into the details of the concept of bitcoin script.

 during the last discussion, we have looked into this kind of forth programming language based on which the bitcoin scripts are designed. So, we will look for more details about this bitcoin script.


So, as we were mentioning that the transactions in a bitcoin can be characterized by the inputs and the corresponding outputs. So, it is like the number of bitcoins

which are being transferred from one user to another.

you can represent the bitcoin transactions in the form of a series of inputs and outputs.

So, it is like that one user, Alice. He has received some 100 bitcoins. So, once alices have received these 100 bitcoins out of these 100 bitcoins Alice sends a say 40 bitcoins to Bob and some 60 bitcoins to Charley.

So, in that case, this particular transaction has one input that is coming to Alice from someone else and has two output one output is going to the input of Bob and another output is going as the input of say Charley.

Now, once Bob gets this 40 bitcoin Bob by for this 40 bitcoin Bob can spend 30 bitcoin the out of that 40 bitcoin to some say a fourth person says some delta with  30 bitcoin and the 10 bitcoin is still with Bob.

Then this 30 bitcoin they can be spent in one output at 10 bitcoin another output at as another 10 bitcoin and the Charley he had received some 60 bitcoin out of these 60 bitcoins he can spend some 50 bitcoins in a transaction.

So, that way the bitcoins that are generated in the network the bitcoin moves through multiple parties  with these different transactions which are happening.And every transaction that we have mentioned that can be characterized by one output and the corresponding input.

Then this output of a transaction is like someone is sending that particular bitcoin and the input is that someone is receiving that bitcoin. And with the help of the bitcoin script, we want to actually ensure that this particular input corresponds to this particular output.


How will Bob verify that the transaction actually originated from alice?

So,  let us see how bitcoin script works.

So, explaining the bitcoin script would be easier if we go with an example. So, let us go with an example that Alice wants to make a certain transaction to Bob. So, Alice initiates a transaction  that contains the address of Alice and Bob will say a certain amount.

 The amount I have not written here says the amount can be something like  something like 10 bitcoins.So, Alice wants to make a transaction of 10 bitcoins to Bob and this A and B correspond to the addresses and as we know this addresses comes from the hash value of the corresponding public addresses.

Now, the question is how Bob will verify that the transaction actually originated from Alice. So, if the transaction actually originated from Alice and this is not a force transaction Then Bob can spend this 10 bitcoin into another transaction.

Send the public key of alice along with the signature-> bob can verify this

So,  what we generally do that we have mentioned several times earlier like with the transaction we include two other parameters one is the public key of Alice. K^A pub, This is the public key of Alice and we also include the signature from Alice. So, these two things are included in the transaction now as we know based on the digital signature mechanism that only Alice can have her private key.

 Alice has her private key and with these private keys she has generated this particular signature and if the public keys of Alice are available using this public key, you can verify the signature.

So, Bob can verify this signature and Bob can be sure that this transaction has actually originated from Alice and that is the valid transaction. So, in that case, the bobs wallet can consider that whatever amount.

 Earlier it was some 10 bitcoin the 10 bitcoin amount that has been transferred. So, Bob can certainly take these 10 bitcoins and use that 10 bitcoins for another transaction.

Bitcoin indeed transfers scripts instead of the signature and the public key

 Now, what bitcoin actually does that instead of sending this individual public key and corresponding signature bitcoin actually transfer some scripts.

So, what are those scripts?

 Traditionally bitcoin uses two scripts one corresponds to the signature which we call the script Sig and another script corresponds to the public key that is the script public key. So, this script public-key basically tells you how you can use the pub key to validate the corresponding signature.


  • Simple, compact, stack-based, and processed left to right
  • FORTH like language
  • Not Turing complete(no loops)
  • The halting problem is not there

So,  this bitcoin script in general it is a simple programming language that is compact

a stack-based language that is processed from left to right. So, from the left operator or operand, you can start processing it and then you can proceed further in the right and it is a kind of forth-like language.

 It was inspired by forth and based on the forth language; the basic bitcoin script has been designed. But the interesting fact of bitcoin script is that it is not Turing complete; it means like it does not support all the operations like it does not support a loop kind of operation and it was intentionally made simple So, that people can the write down some simple scripts and the scripts can be validated and it also makes difficult to write down some kind of attack scripts.

And because this particular scripting language is not Turing complete by turning completeness we mean that it supports any of the languages that can be accepted by a Turing machine; because we do not have this concept of loops and few other complicated things we this particular scripting language was not traditionally turing complete,. But recently the bitcoin developers are including new features in the script and they are planning to make it  Turing complete language, but keeping that side apart intentionally the language is very simple and as it is not a Turing complete language you do not have the kind of halting problem.

So, it does not have the loop; so, you do not have a problem of infinite loops inside your language.


  • With every transaction, Alice must provide
  •     A public key that when hashed, yields the address of Alice embedded in the script
  • A signature to provide ownership of the private key corresponding to the public key of Alice

 In the case of bitcoin script. So, with every transaction, Alice must provide a public key. So, this public key whenever you are hashing over that public key it yields the address of Alice which is embedded inside the key inside the script; that way you can validate that the transaction actually originated from Alice.

And then a signature that signature verifies that the public key which has been transferred that public key actually corresponds to Alice. So, the idea is very interesting the idea is that you are making a transaction from say A to B along with this transaction.

So, Alice to Bob along with that a transaction you are putting a public key of saying the public key of Alice and you are putting the signature of Alice which was generated using the private key of Alice.

Now, what is the guarantee that the public key that you are getting that public key actually belongs to Alice? So, what you can do first of all you can be using this public key you can check the signature if the signature matches; that means, you actually know that this private key has been used for generating this particular transaction; it actually belongs to.

this public key belongs corresponds to the private key which was used to generate this signature. Now, as you know this particular address was actually generated from this public key by applying some hash function.

So, you can apply the same hash function over this public key and you can see whether you are getting back this address or not. If you are getting back this address; that means, that this was the original sender who had actually sent the transaction to you and by doing this validation you are making sure that the transaction is actually authenticated and no one else in the future will be able to claim the transaction.

And at the same time later on Alice will not be able to deny this particular transaction.

Now, these things are actually embedded inside the script.


 So, let us look into this example script.

So, as you have mentioned that we have the transaction input and the transaction output.

 at the transaction input; we have this scriptSig which contains the signature. So, this signature corresponds to so we have two components here one the first component is the signature, and the second component is the public key.

 we have these components  so, we have the signature and the public in this scriptSig and in script public key you have a certain operation and then you have the address of Alice.

So, that hash function where that hash through which you are actually getting out the address.

So, this address is embedded inside the script; now let us look into how this script is actually executed and using this script sig and script pub key how can you validate the authenticity of the transaction.

 This is a sample script; so, in the sample script, you have two entries you have the script pub key and a script sig. So, in the script Sig you have the signature and the public key and in script public key you have certain operations.

So, while explaining the operation I will actually explain to you what is the meaning of all these different operations. So, as you have mentioned earlier, the bitcoin script is a forth like a programming language.

 it is processed from left to right and it is processed with the help of a stack. So, will take the help of a stack and try to process this particular script. So, let us look into how this script is being processed.

So, initially, the first task is that we need to combine these two scripts together. So, by combining these two scripts together we get a combined script like this. So, first, we put the input, and then we put the output.

 The input script is your scriptSig. So, first, you put the scriptSig that means the sig and the public key and then you put your script pubkey that is the output script. So, the output script is written here; so, initially the stack is empty and you have generated this combined script by combining the input script and the output script.

So, once you have done it then let us process it using the similar concept of this reverse polish notation that we had used to process forth language.

So, how will you process that?

 We have this initial sig and pub key which are the  operant. So, if these are the operands we push that operand in the stack. So, after pushing the operand in the stack  initially the stack was empty then we have pushed these two operands in the stack.

Now that is our  resultant  script after pushing this to operant in the stack.

So, then we have this operator OP dup. So, what OP dup does OP dup the dup operator it actually makes a duplicate of the stack top value.

So, earlier the stack dump stack value was this pub key; so, on top of that pub key we have  duplicated those things.

 So, another entry of that pub key is  pushed into the stack by this  OP dup operator then we have this.

So, what does this hash 160 operators do?

It applies this RIPEMD 160 hashing mechanism on top of the. So, it applies this RIPEMD 160 hashing mechanism on top of this pub key entry that was there at the top of the stack.

So, by applying this hash you are getting an operand like pub hash. So, after applying this operator you got the pub hash and that is pushed inside the stack; then at the next step.

At the next step operator of hash 160; you have the pub key hash. So, you this is the operand; so, you push the pub key hash in the stack top then you have the operator equal verify.

So, this equal verifies checks whether the two hash values which are there whether they are equal or not. If they are equal then you returned true you just simply popped it out and if they are not equal then you return a false or an error.

So, this equality is checked between the top two items in the stack. So, if these two hashes are equal then that means the ID that has been transferred in the transaction.

So, whenever you have made a transaction from A to B you are actually verifying that its address corresponds to the address of Alice. So, once that thing is done then The next operator is OP checksig.

In the OP checksig, the operator again takes the two operands from the stack top, and after taking these two operands from the stack top; it verifies whether the signature corresponds to this public key whether that is a valid signature or not.

So, you are doing a signature validation here; so, after doing a signature validation here if you have validated that the signature is correct; that means, you have validated that the signature is actually coming from Alice.

So,  in total what you have basically done by executing the input script and the output Script by looking into the output script; you have found out that well Alice‚Äôs actually made that particular transaction.

 The address which was there inside the transaction that address corresponds to the address of Alice. And then by looking into the output script where they are you have the signature and the public key; you have actually validated that the signature corresponds to that particular public key; so the signature is a valid signature of Alice.

Combining this input script and the output script together you have actually ensured that the transaction has originated from Alice itself and the transaction is a valid transaction.

So, now once you have validated the transaction that the transaction is a valid transaction then you can include that transaction accept that transaction as a correct transaction, and whatever bitcoin that has been transferred to Bob; Bob can start utilizing that amount of bitcoin for other transactions. So, this bitcoin script is a very intelligent mechanism to make such kind of checking that whether a particular transaction input; corresponds to a transaction output or not.


  • Total 256 opcodes (15 disabled, 75 reserved)
  • Arithmetic operations
  • If- then conditions
  • Logical operators
  • Data handling(likes OP_DUP)
  • Cryptographic operations
  • Hash functions
  • Signature verification
  • Multi-signature verification

Now, in the case of bitcoin instruction that was the earlier version of bitcoin script the initial version of bitcoin script has a total of 256 different opcodes out of them 15 are currently disabled, and seventy-five per reserved.

So, you have different arithmetic operators, you have different if-then conditions then the logical operators, the data handling operators like OP dup which duplicate the entries of a stack top.

Then you have different kinds of cryptographic operators like the hash functions, the signature verification operations, the concept of multi-signature verification operations where the signature from multiple users are combined together and that multi-signature is used to verify the signature coming from a  set of users.

So, you have all those different kinds of  OPcodes as a part of your bitcoin script.


  • Provably unspendable or printable output
  • Scriptpubkey :OP_RETURN {zero or more ops}
  • Anyone-can -spend outputs

            Scriptpubkey : {empty}

            Scriptsig : OP_TRUE

 So, here are some interesting bitcoin scripts; so, the first bitcoin script it talks about is that you are making some kind of transactions for probably unspendable or printable output.

 In the script pub key mistakenly you are writing as OP returns. So, whenever you are immediately writing as OP, return; so it will immediately return from the stack top with the false operand.

 whenever it will return from the stack top with a false operand then you are sure that this particular transaction whatever bitcoin that has been transferred as a part of this transaction there is not usable bitcoin.

So, you cannot use that bitcoins any further than the second interesting script that anyone can spend output; it is like that whatever transactions you are making in the bitcoin network anyone in the network can use that bitcoin.

 In that case in the pub key, we have made it empty. So, you do not have any pub key information in the scriptSig it is always returning as true. So, whoever is going to validate that the script they will immediately get a true and they will be able to use that bitcoin, without making any further validation.

  • Freezing funds until a time in the future

   Scriptpubkey: <expiry_time>




    Scriptsig: <sig> <pubkey>

 Then in the third script, it is like we are trying to freeze the funds until a time in the future.

So, in the script pub key, you have an expiry time; so, this expiry time specifies that till what time you will be able to you will not be able to use that particular bitcoin.

So, this OP check time checks lock time verify this particular operator checks whether the current time is more than the expiry time or not if the current time is less than the expiry time then immediately it will return this OP drop; that means, it will return a false and that particular bitcoin will not become usable.

 if this operator check lock time verifies if it finds out that well the current time is more than the expiry time; that means, the time has been expired; then it will go to this next part of the operator, it will skip this OP drop it will come to this normal validation script which was OP dup followed by OP hash 60 the pub key hash equal verify and check the normal script it will execute.

And the intended participant will be able to use that fund in the future. So, this particular script basically ensuring that the bitcoin that has been transferred that bitcoin will remain unusable for a certain amount of duration; it is like that you have transferred a certain bitcoin, but you do not want the user to be able to use the bitcoin say for three days that you can embed  inside this kind of script.


  • An ad-hoc network with random topology, Bitcoin protocol runs on TCP port 8333
  • All nodes (users) in the Bitcoin network are treated equally
  • New nodes can join any time, non-responding nodes are removed after 3 hours

 Next, we come to the concept of bitcoin peer to peer networks. So, as you have discussed earlier that bitcoin works on top of a peer to peer network architecture in a completely decentralized manner.

So, this bitcoin peer-to-peer network is an Adhoc network with a certain kind of random topology and on top of that, it runs the bitcoin protocol using the well-known TCP port 8  triple 3.

And all nodes who are the users in that bitcoin network are treated equally and new nodes can join in the bitcoin network any time and one interesting property of bitcoin is that It is permissionless.

So, to join the bitcoin network you do not need to verify yourself to some authentication The server is not required. So, whenever you want to join the bitcoin network; you can simply open up your wallet and after opening up your wallet you can immediately start sending a join message to join in the network and can start doing your own transactions.

Now,  for the old nodes if the old nodes are not responding to the old peers; if they are not responding for a certain duration in general it is for three hours then they are automatically removed from the bitcoin network.

And those users whenever they will open their wallet again and start participating in some transactions; they can join in that specific network. 


Now,  let us look into how you can implement joining in a bitcoin peer to peer network.

As we have said that in a bitcoin network it is a kind of a random topology of nodes and the leaves that are there in between two nodes those are kind of virtual links or Those are kind of overly linked.

So, do not expect that there are kind of physical links between the two users; those are kind of virtual links or a kind of peer to peer link; that means, we are considering if the, if I have a link with, say another user Alice so; that means, from myself to Alice we are virtually considering each other as a neighbor. So in such a kind of network whenever a new node comes and once to join in the network, 

there are certain nodes in the network which work as the seed node. So, the task of the seed node is to provide the initial information to the new nodes who are going to join the network.

So, whenever you are installing your bitcoin applet inside your bitcoin applet the address of those seed nodes is already there. So, whenever you are trying to join in the network you send a message to one of the seed nodes that give me the peer addresses.

So, in response, this seed node will send you a set of addresses that you can consider as the peer. Now, among that set of addresses which has been returned by the seed node; 

you can select a certain random number of nodes and you can create a kind of peering relationship with those particular nodes and you can join in this over a network.

So, this means that whenever you have joined this over network whatever information you are going to send in the network. So, as you already know that whenever you are making a new transaction; the new transactions are broadcasted in the network or for the mining node, whenever the mining node has found out some new blocks the new blocks are again broadcast in the networks and whenever you have done.

 Then you can broadcast those transactions or broadcast the new block information to your peer nodes. 

So, once you have joined the network the first task of a node is to get the most recent blockchain from your peer nodes and update your local copy of the blockchain.

 that is again an interesting principal like you may be offline for a certain duration and whenever you are offline; during that time maybe the blockchain has increased with the new transactions and it will certainly happen whenever that has happened then you are actually after doing this joining procedure, you are asking your peers to give them the most recent or most updated blockchain information that they have.

So, once they are transferring the most recent blockchain information to you compare that blockchain. So, we apply some kind of  50 percent rules because of this principle of decentralization it may sometimes happen.

So, the details will discuss later on it may sometime happen that you are getting two different copies of blockchain from your neighbors. If you are getting two different copies of blockchain from your neighbors you accept the copy of the blockchain which has been transferred to you by the most number of peers; that means if a certain copy of the blockchain has transferred to you by more than 50 percent of the nodes in your peer list; then you accept that particular copy of the blockchain.

And while accepting the blockchain copy; you also need to need to ensure that you are also considering the longest chain in the current blockchain. So, once you have got the most recent copy of the blockchain then you can start the transaction procedure.

So, in the next discussion, we will look into the details about after doing this joining procedure; how can you initiate a transaction, and how that transaction gets propagated in the bitcoin network.


follow us on facebook

Leave a Comment