top of page

Blockchain Demystified: A Comprehensive Guide to Understanding Blockchain Technology (Part 2)


We have understood the fundamentals of Blockchain technology and it can be summarised as below:

1. Hash: A random number generated through an input.

2. Block: A Block contains ‘Block,’ ‘Nonce,’ ‘Hash,’ and ‘Data.’ A Block is used to contain information about the transactions and act as a ledger to these transactions.

3. Blockchain: A chain of Blocks that are linked through the referencing of the Hashes.

4. Tokens: A fundamental unit that is used as a considerations or currency to settle the transactions on the Blockchain.

5. Coinbase: A random amount of Tokens transferred to a random participant that act as genesis of the Tokens.

It is a fully digital Blockchain-based Currency that is not issued by the government, and no banks are needed to manage the accounts with respect to transactions that take place on it. It was invented by a person called Satoshi Nakamoto, but no one knows who this person is. We just know that it is a person or an alias of a person who wrote the Bitcoin Whitepaper.[1] After going through the subsequent units, you would be able to read the Whitepapers of various blockchain networks and create your own.

We shall now understand about Bitcoin and other technicalities associated with it by examining a method of how a person might have invented their own Bitcoin or some other virtual currency.


[1] This is a paper that explains the working of the Bitcoin and how these currencies would come into existence.

Let us try and keep track of the payments that are being made by keeping a community ledger. In our example, we would consider A, B, C, and D (together, herein referred to as ‘friends,’ and separately as a ‘party’) as friends who frequently exchange money amongst each other. But as we start trusting the stakeholders and participants in the system lesser and lesser, and we bring some ideas from the cryptography, we could develop our own cryptocurrency.

There are many cryptocurrencies in the world, and Bitcoin is just the first implementation of the cryptocurrency. After understanding our idea of cryptocurrency, we would be able to appreciate why there are different cryptocurrencies and what is the significance of different design choices. These designs are based on decentralized trust-less verification based on some maths born in cryptography.

Let us consider the case: Friends are frequently exchanging money amongst themselves. They might be paying their share of movie tickets, rent, etc. It might be inconvenient to exchange cash all the time. So, let us maintain a shared ledger on a website that records all of the payment that the one might intend to make in the future. An example is in table 1 below:

The above is an example of a ledger that records all the transactions. Let us say that it is public and accessible to everyone, like a webpage where everyone can go and add new lines. Let us then assume that friends meet up at the end of every month and settle up. If more money was spent than received, the Party has to pay-up, and if a party receives more than the Party spent, the Party has to take back the extra money.

For example, if one party spent INR 120 and received INR 20, it would have to give back INR 100 and if another one party received INR 120 and spent INR 20, it would take back the money. These transactions would take place on the ledger and settlement would happen at the end of every month in this hypothetical scenario.

We would keep coming up with different protocols, i.e., a set of rules that would govern our transactions.

So, let us set up a protocol for a system as described above. The Protocol is as follows:

· Anyone can add lines to the ledger.

· At the end of every month, settlement happens.

One problem in a public ledger like this is that anyone is allowed to add a line. So, how do you know, in the example being discussed, B from writing the first sentence in the ledger, i.e., A Pays B INR 100 without approval from A. How do we trust what is written on the public ledger is accurate and is in no way fictitious.

To solve this problem, we will now use digital signatures. The payer shall be able to approve the transaction, and the approval shall be in such a way so that the person approving the transaction shall be uniquely identifiable, possible through digital signatures. The table 2 below shows how the transactions and public ledger would look like after adding digital signatures (in ‘signed by’ column).

This would prove that the transaction has been seen and approved by the signee. We also need to ensure that it is unfeasible for anyone to forge the signature.

It might seem that the digital signature is not even possible. For example, the signature of A might be represented by certain binary bits, say 110011. Now, someone might argue that another one might copy these bits. So, how can forgery be prevented? To prevent this, everyone would generate a public key (“PK”)-private key (“SK” because the Private key is sometimes also referred to as the Secret key) pair. So, the public key and private key pairs might be represented for different Party as follows in Table 3:

SK is just like a password that one shall not share with anyone. In the real world, the signatures that we use look similar, but a digital signature is much more reliable because it changes for different messages. It consists of a string made up of ‘1s’ and ‘0s’ and is 256 bit long, i.e., there are 256 ‘1s’ and ‘0s’ in total. This is what 256 bits mean. If the message on which the document is used is altered even slightly, a complete change of signature on that message happens. Consider the signature as a function that depends both on the message and SK. It can be denoted as follows:

Sign(message, SK)= Digital signature. It is a function in which inputs are message and SK, and output is a digital signature. The SK ensures that only the person who owns the private key can produce the signature. And because the signature also depends on the message, the signature cannot be copy-pasted.

This means that one generates a unique signature for every message using their SK.

An illustration for the same is in Table 4 below:

As we can see from the illustration, the message depends both on the message and SK. The illustration uses a 6-bit example, but actually, it is a 256-bit signature. Hence the signature cannot be forged on any other document or message without access to the SK. Now, how do we know whether the signature is forged on the document? That is where the PK comes in. Verification would need three inputs, Message, Signature, and PK, and whether the signature is authentic or not (‘True for authentic’ and ‘False for forged’) would come out as an output. To understand better, consider the verify function below:

Verify(Message, Signature, PK)= True/ False. This function would help us determine if the signature produced by the SK for the message is valid or not using the PK associated with the SK. The idea behind using this methodology is that it shall be completely infeasible to find a valid signature if the SK is unknown. Specifically, the best strategy to come up with a valid key is just hit and trial, and guess your way towards a valid signature. This could be used by the public key, which is known to everyone.

To put it simply, the Private Key is used to create a signature & the Public Key is used to verify a signature.

Thought Experiment: The signature is 256 bit long, and each bit might have two values, i.e.,’1’ or ‘0.’ There are a total of 2^256 possibilities at any given time, which is a number incomprehensible by the human mind. Try and come up with the number! And only one of them can be an actual value to a particular message!

If you performed the thought experiment above, you would feel extremely confident while using your digital signatures now. Because you are sure that the signature for the message could only be feasibly produced if they had the SK associated with the PK used to verify the signature.

Now, let us assume that the signature used in Table 2 is a 256-bit digital signature, which has been derived from the method discussed above. Currently, there is one more problem associated with the ledger that we came up with in Table 2. A transaction could be copied again and again, and as the signature would remain the same for the same transaction (which has the same ‘message’), B would copy the first row, i.e., A Pays B INR 100 multiple times. The problem has been illustrated in Table 5 below(see the last transaction):

To circumvent this issue, we also put a unique identity as shown below, so now the ‘message’ would also consist of the unique id associated with the transaction, making it impossible to be replicated. After inserting the unique ID to Table 2(Unique id is represented as serial number), we would get the Table 6 below.

We also need to keep in mind as the Sr. No. would be part of the message, it would generate a unique Hash for each transaction. Now, if A signs the transaction with serial no. 0, this cannot be copied again as the Hash would change if the same transaction is copied again. Consider Sign (message, SK) and Verify (Message, Signature, PK) producing different results consequently. The Sr. No. would be automatically produced depending on the transaction number.

Now, let us add to the previous Protocol:

· Anyone can add lines to the ledger.

· At the end of every month, settlement happens.

· Only signed transactions are valid.

The new Protocol removed the issues concerning trust in the new Protocol. But there is still the issue that the Protocol has right now. It is based on the promise system that everyone would meet once a month to settle their dues. What if the Party C incurs lakhs of INR in debt as might be the case below in Table 7.

Now C has lakhs of INR debt, and he might disappear before settling his dues. Therefore, we come up with an idea through which no one ever actually has to settle up in cash if we have a mechanism to stop people from spending too much than they can take in. Initially, what can be done is that everyone contributes a fixed amount to the pot, and we have a new form of entry in the ledger, as shown below in Table 8.

Now, let us add to the previous Protocol:

· Anyone can add lines to the ledger.

· Only signed transactions are valid.

· Overspending is not allowed.

Therefore, no one would be able to spend more than they deposit. Consequently, we have solved the issue of someone incurring an excessive amount of debt and not showing up when they have to settle the debt. Now consider the following transaction as follows in Table 9:

Transaction 6 would now be invalidated because C now wants to overspend and hence would be in violation of Protocol. It would be invalid, and it would be deemed that C never signed it. This transaction would cease to exist on the ledger.

This would mean that verifying the transactions would now include knowing the history of all the transactions so that the balance of each individual could be tracked. This would be the case with cryptocurrencies with some more optimization.

The next step would remove the need for the link between the fiat currency (fiat currency is any currency recognized by as legal tenders such as Dollar, Indian Rupee, etc.) and the ledger. In the example above, we have been relying on INR (fiat currency) but this reliance could be replaced with a token that is recognized as consideration by everyone. Theoretically, if everyone was using this ledger, we could follow all the transactions on this ledger without a need to rely on fiat currency. All the accounts could potentially be settled using this ledger. There would be no need to convert into fiat currency.

So instead of INR, we will start now use the Tokens (such as Bitcoin) that would be theoretically recognized as valid consideration by everyone participating in the ledger. We would refer to the Token as Ledger Currency (“LC”). We can, at any point in time, exchange LC with INR or any other fiat currency. For example, A pays B 1000 INR, and in return, B pays A 1000 LC, provided B had 1000 LC balance on the ledger. The Protocol does not guarantee the exchanges between the LC and fiat currency. Also, LC can signify any cryptocurrency at this point. For example, Bitcoin, Ether, Litecoin, etc.

Now, this is the first significant bit concerning Cryptocurrencies. We would understand this through Bitcoin (“BTC”). It is a Ledger which contains the transactional history. And this history of transactions is the Currency.

History of Transactions= Currency. Now, there is a difference between the current system LC and the BTC. While BTC is based on a decentralized system, our LC is based on a centralized system. We have said that the current Protocol is present on a website in which anyone can make edits. But this requires us to trust a Centralized Website. The person who hosts or controls may change the contents of the ledger or delete the ledger entirely. The person who hosts the website controls the Protocol of the ledger. Now, to remove the trust from a centralized entity, we would let each of the participants keep a copy of the ledger so that the dependency on a centralized entity would be terminated. Now all will have a copy of the ledger, and the friends can now be seen as below.


Now consider that the ledger is based on Table 10 for understanding purposes:

After A records Transaction ‘0’ on his copy of the ledger, he broadcasts the contents of Transaction ‘0’ across the world so others may ‘hear’ them and include the transactions in their ledger copies. But as you notice, this system is quite fallible. Some of the problems with this system are as under:

· How do you determine which copy of the ledger is the right one?

· If A sent the message to everyone concerning transaction ‘0,’ how can everyone believe and receive the transaction?

· How to ensure that everyone is recording the same transactions in the same order?

We need to determine addition to the Protocol above to ensure that the problems discussed above do not arise so that everyone in the world who follows the Protocol would have the same ledger. This is the problem that was addressed by Satoshi Nakamoto in the Bitcoin Whitepaper. The paper proposes to trust the ledger which has the most computational work put into it. Let us understand what it means through Cryptographic Hash functions. We will build into the idea that the computational work that if we use the computational work as a basis to trust the legitimate ledger, the fraudulent ledgers would require an infeasible amount of computational work. To understand more on this, please read below:

Let us now understand the concept of Proof of Work:

Let us now revisit what we had discussed earlier about Hash. It requires an input ‘message’ and produces a 256-bit Hash function. This function is defined as SHA256 and defined as follows:

SHA256(“Siddharth Dalmia”) = 10111111000110000101000100111101100111101011001110011111110001001111100011111100111101110100000000011000100100010011011001010100111000000101000001110010001011110011010110111111100101110110101001100011010100011110101001010100100110110101111111100000110(in binary format) = 2701084972240082290225282244638419938315045918369428019366306600203505565446 (in the decimal format)

NOTE: ‘Siddharth Dalmia’ can be replaced with any other message or file.

The output above is in the binary system (represented by ‘1s’ and ‘0s’ is known as Hash or Digest). This function intends to get a random output for a particular message or file. The function always gives the same output for a given input. So, the result of the message “Siddharth Dalmia” would always be the same if you use the SHA 256 algorithm. As we have seen before, the Hash of the program would completely change by editing anything in the message. And the way the output changes is entirely unpredictable. SHA 256 is an example of a cryptographic hash function. It is not feasible to reverse engineer the output, i.e., it is mathematically infeasible to know the input from a given output. There are 2^256 possibilities for the hash number, and you might have to guess 2^256 times to reach the right input for a given output without SK. Remember the thought experiment we did before?

Now, let us try and figure out how a cryptographic Hash function, i.e., SHA 256, may help us determine a large amount of computational effort, i.e., Proof of Work. This is similar to our understanding of Blockchain in the previous Chapters. Let us try and put everything in perspective now.

Suppose we input a particular Block in the SHA 256 function, such that Nonce is such that the first 30 bits of the 256-bit output are ‘0s.’ The probability of this would be (1/2^30, which is almost a 1 in a billion chance) to land on such a number. Similarly, finding a nonce, so that the first 20 bits are ‘0s’ is (1/2^20). Please refer back to the importance of Nonce in Blockchain in case you have forgotten.

But once such a nonce value is found, it is relatively easy to verify that the given Hash started with 30 ‘0s’ by inputting the Block in SHA 256 function. This would prove that the person who claims that he found such a nonce value went through a large amount of work without going through it ourselves. This is called the ‘Proof of Work.’ All of this work is intrinsically tied to the list of transactions (or messages), as we had seen in the previous Chapters. Now, what would happen if someone were to change the transaction record? He would have to go through a billion guesses (because of 1/ 2^30 probability). To understand why, please go through the chapter to Distribute Blockchains once more.

Now, let us consider again the friends involved in the distributed ledger transaction. Now, we want them to agree on which one is the correct version of the ledger.

The core idea is the ledger with most work done can be trusted according to the Bitcoin paper. Now each of the ledgers is first organized into Blocks, where each Block consists of transactions together with the Proof of Work (the Hash). Let us assume that the Block starts with 60 zeroes for now, but we would come up with a proper way to determine the number of starting ‘0s.’

Similar to the transaction which is considered valid if it has a digital signature, a Block is deemed to be valid if it has the Proof of Work. As we have discussed before, each Block would also contain the Hash of the previous Block. Please refer to the earlier chapters to understand why this mechanism is secure. Now, let us update the Protocol, now anyone in the world could be a Block creator. Now all the stakeholders would look like the figure shown below:

In the diagram above, all the Friends have a copy of the ledgers on the Blockchain, which have all the transactions ever recorded on the Blockchain. Block Creators will find the Hash of the current Block (through Proof of Work mechanism), and once the Hash of the Block is found, the Block would be added to the Blockchain owned by all the Friends following the Protocol, after the new Block is broadcasted to every Blockchain holder by the BC. Block Creators are often referred to as ‘Miners.’ Suppose, Block Creator (“BC”) 2 manages to find the Hash before any other BC, the Protocol will permit the BC to include one unique transaction at the top of the Block which has been highlighted in Table 11 below in transaction ‘0’:

This highlighted transaction is the reward for all the Computational work (for Proof of Work mechanism) that the BC 2 put in. This reward is known as the Block Reward. It’s an exception to our Protocol that we have created for accepting or rejecting the transactions. The exceptions are as follows:

· It does not need to be signed as there is no sender.

· Adds to the total number of LCs which are present on the Blockchain.

The BC (or Miners) are performing the following functions:

· They are listening to the transactions that are being broadcasted.

· They are creating Blocks (through Proof of Work).

· They are broadcasting the Blocks.

· They are getting Block Rewards for the creation of New Blocks.

The BC who manages to come up with the Nonce first is rewarded with the Block Reward. Each BC is guessing numbers as fast as they can to earn the Block Reward until one BC guesses the number such that it satisfies Proof of Work conditions.

The Friends are now only listening to the broadcasts concerning Blocks and broadcasting Block transactions wherever they are involved. This results in their own ledgers or Blockchain to be updated. Remember, when any Party listens to more than one broadcast to 2 different Blockchain with conflicting transactional histories, they must include the Blockchain with the highest number of Blocks to their personal copy of the Blockchain. It is because the longer the Blockchain, the more work has been put into it. If there is a tie, the Party must wait for one of the Blockchain to become longer before including it into their private copies.

This whole mechanism removes the need for trust in the central authority and results in trust in the amount of computational work that is being put in to create the Blocks. The Proof of Work mechanism, along with distributed ledger, helps us trust the decentralized ledger.

To understand the security of the system and why we should trust it, let us refer back to our discussion of Blockchain in the previous chapter.

In a distributed ledger system, your voting weightage is determined by the proportion of ‘Tokens’ that you hold. This voting weightage is used to vote on whether a transaction is valid or not. An individual will earn a ‘Token’ by putting in ‘work’ or computational power. Therefore if you have to cheat the system, you must have atleast 50% of the tokens, i.e you must have put 50% of the total computational power that was put in the Blockchain.

To cheat the system, she would need a 50 percent consensus, which would require 50% of the computational power on a Blockchain, i.e., the nodes would have to agree to the correct version of the distributed ledger.

Also note that our Protocol to accept the longest Blockchain is what makes the system more challenging to break. The Friends shall not accept individual Blocks immediately but shall wait for some more Blocks before accepting a valid Blockchain into their existing Blockchain.

Final Protocol would look like the following:

· Anyone can add lines to the ledger.

· Only signed transactions are valid.

· Overspending is not allowed.

· Trust the Proof of Work mechanism.

· Anyone in the world could be a Miner.

· The exceptions for Miners concerning Block Rewards to the Miners shall be incorporated.

· Accept the longest Blockchain when there is a conflict.

Now coming specifically to BTC, the Proof of Work is not dependent on 60 consecutive zeroes, but on an algorithm so that number of initial zeroes keeps on changing such that to validate a particular Block, it does not take more than 10 minutes(Block Time). The number of initial zeroes for Proof of Work would depend on the total number of BCs.

Now, we can understand what is BTC network. The Bitcoin network operates on a cryptographic protocol for peer-to-peer payments. Users receive and send the Bitcoins through this network. This is done by digitally signing the transactions on the network. These transactions are recorded on a blockchain network and the consensus is achieved through the process called mining. Minimal structure is required to share the transactions on the network. A volunteer based ad hoc system of decentralized system is sufficient to record the transactions without the need of a central authority. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will. Upon reconnection, a node downloads and verifies new blocks from other nodes to complete its local copy of the blockchain.[1]

In the BTC network, each Block is limited to contain only 2400 transactions. You can incentivize the miner on BTC network to push your transaction through the BTC network by using BTC. This means you can pay more as the transaction fees so that you transaction is included in the 2400 transactions.

The payment that you make to get your transaction recorded is the value of a Bitcoin.

Therefore higher the demand for being included in the BTC network, higher will be the value of the Bitcoin & vice-versa.

This makes the BTC network unviable and results in higher transaction fees.

This is how the Bitcoin protocol works!

Note: the Block Reward on the Bitcoin network keeps on updating, and they are halved every four years. Till July 2016- Feb 2020, the Block reward was 12.5 BTC, which has now been reduced to 6.25 BTC till September 2023. For more details on the Blocks, visit

Now you have understood how the Blockchain Technology Works and that Cryptocurrencies are one of the applications of the Blockchain Technology?

Questions to ponder:

1. What is the Block Time for XRP, Litecoin, and Ether?

2. List out the transactions on the first three Blocks of the BTC network. (visit

3. Compare the number of transactions that happen on the BTC network with the number of transactions on the VISA and Mastercard network.

Where else could you use the Blockchain Technology?

By Siddharth Dalmia

The StartUp Sherpa


Recent Articles

Subscribe to Our Newsletter

Thanks for submitting!

bottom of page