May 11, 2018

By: ShantiSwarup Satpathy, Senior Consultant- BFSI, LTI

I have been following advancements in blockchain technology for some time now, and this blog is an attempt to provide some insights to the “Bitcoin Validation Process”, which is a critical aspect of the blockchain use case “Bitcoin”.

Bitcoin is a digital peer-to-peer payment platform which doesn’t require any central authority to authenticate a transaction; instead, each eligible participatory node acts as a validation agent. The payment platform uses the (virtual/crypto/digital) currency Bitcoin as the transferable attribute of a transaction. The transactions are near real-time, non-reversible and tamper-proof, while the transfer fee is much lower.

While Bitcoin is described as the virtual currency/cryptocurrency/digital currency, Blockchain is the technology behind it. To simplify it a little more, “Bitcoin” can be attributed as a use case of blockchain technology – part of a growing list. The non-Bitcoin use cases of Blockchain deal with a transaction type which is famously known as Smart Contract, used to define the current ownership of an asset as well as the condition on which ownership can be transferred to other stakeholders.

Smart Contract is outside the purview of the topic discussed here, i.e. “SCRIPT”, which is a language created for Bitcoin transaction validation purposes. So, now we are better equipped with the analogy of Bitcoin and blockchain to move further into the language “SCRIPT”.

“SCRIPT” is a programming language which runs in every single node of the Bitcoin system. It is used to create the validation program which is required by nodes before propagating the transaction to the subsequent nodes. It’s a light-weight programming language, as it needs to run quickly and needs to run in every computer, supercomputer, ASIC board or individual laptop which is currently acting as a node. Secondly, it’s non-Turing complete, which means there are certain control flows in the language which are not possible, such as looping. The reason behind keeping it non-Turing is to prevent people from creating transactions, which cause the nodes to get into an infinite loop and bring down the system. Lastly, being stack-based, there is a list of instructions which act on a stack (a locally held list of variables stacked on each other in a logical way).

As the program is executed, the instructions interact with the stack to put new numbers on top of the stack, or it takes a member from the top of a stack and manipulates it.

In the next and the last segment, we will discuss Bitcoin transaction validation while getting a feel about the what, why & how part of locking and unlocking script. The locking and unlocking scripts are two parts of the same puzzle, which gets solved during the transaction validation process by using both the scripts together, and passing it through a series of script language instructions.

The intent of the locking script is to make sure only the correct recipient claims the fund after providing an unlocking script, as described.

The unlocking script is intended for usage in conjunction with the locking script during a Bitcoin transaction validation process, where the recipient tries to place a claim on the fund with the evidence kept inside unlocking script.

A sample transaction process is shown below.

Figure 1.1 Pay To Public Key Hash Transaction ProcessNodes perform the transaction validation through a seven-step process and finally, check if the value left in the stack is true – in which case, the transaction is valid. You can find the script instruction execution flow depicted in the below figure. As you read through the top row showing validation Instructions, follow how the values in the stack below are populated or manipulated.

Figure 1.2 – 7-Step Process of Transaction ValidationTo expand the critical step seven (OP_CHECKSIG) instruction further, understand how the “PUBLIC KEY HASH from Txn XYZ” is compared with “Signature provided in the Txn XYZ”. The pictorial representation below provides a close look into step seven alone.

Figure 1.3 – Instruction AnalysisBitcoin nodes sign-off the transaction as a valid transaction for further processing, as long as step seven has arrived at TRUE. If the correct recipient has created the Transaction XYZ and provided the appropriate unlocking script, the last value in the stack will come out as TRUE.

I hope this fundamental insight into the process of Bitcoin validation has left you with no doubt on how securely a transaction is processed inside a Bitcoin network, even when the network is infamous for keeping stakeholders anonymous. Unless a stakeholder’s private key is compromised, it’s absolutely impossible for a wrong recipient to claim Bitcoin.

There are several other aspects of Bitcoin, but let’s save those for another day. I’m signing off with the thought that this article has provided enough fuel for a Bitcoin enthusiast.