Blockchains and Bitcoins

Ravikiran durbha
Data And Beyond
Published in
12 min readDec 11, 2021

Blockchain

Blockchain promises much, but it is hard for the casual observer to process and gain an intuition as to how it works. There is a lot of math behind it, but let’s attempt to look at it using primitives everyone understands.

At its core, the “Block”, is a structure that stores data and the “Chain” fosters trust among a network of users. Now, trusted data is after all a cornerstone of BI and it is natural then to pose the question — “Can we apply blockchain to somehow build trust into BI ?” Before we can answer this though, we need to look at other applications of blockchain, like Bitcoin. After all, it relies on complete strangers reaching a consensus on a document (Ledger). To understand this, we need to look more closely at how bitcoin works and more importantly why it works. Once we gain this intuition, we can then explore how it may apply to something else, like BI.

Bitcoin

Bitcoin is a digital currency that was invented by Satoshi Nakamoto (Pseudonym — It could be an individual or a group of people) with the blockchain as its backbone. There are many concepts that come together that makes Bitcoin work. The concepts themselves were not novel or new at the time of the invention of bitcoin, but the genius of Satoshi was to really put everything together.

Figure 1: Many concepts come together for Bitcoin

Distributed Ledger

Let’s say we need to keep a record of all financial transactions between four people, so that they don’t have to transfer cash immediately. Someone trusted needs to maintain a document with these transactions which we call a ‘Ledger’. We generally rely on banks to do this at scale, since in our digital economy we don't transfer physical cash immediately. The banks themselves rely on yet another entity called the “Central Bank” to maintain a ledger of all transactions between the banks. In short, we appoint an entity to trust since we cannot trust everyone. This centralizes authority, but leads to reversible transactions (In other words, I can dispute the transaction with the authority and get it changed). The central authority cannot help but mediate such disputes. This raises the cost of transaction and merchants must be wary of their customers and collect more information than they have to lest they dispute and reverse the transaction [1]. In contrast, the decentralized or the distributed ledger approach trusts no one and makes the transaction immutable (no one entity is in charge of the ledger — so it would be infeasible to reverse a transaction. Plus, we will see that the data structure itself enables this).

But, how does it actually work in practice? How can we implement a decentralized ledger, where every one maintains their own copy and yet agree to one version of truth ? How do we know the transactions are legitimate? We can go back to the simple example between four people to illustrate the solution.

Figure 2: A Simple Ledger

In the figure above, we can see an example of a very simple Ledger. It is just a collection of transactions between four people. I have used dollars here for simplicity (since we have not yet seen what a Bitcoin really is), but it can really be anything — Bitcoin, or some other crypto currency. Imagine all four of them have a copy of this on their respective computers as seen in Figure 3 and every new transaction between any of them is broadcasted to all of them over the internet, which they can add to their copy of the ledger.

Figure 3: Distributed Ledger

Clearly, there are several problems that need to be addressed. For example, how will Joe know that Amy actually has $3 to give him? There is no bank or Visa or Mastercard sitting in the center to validate it. Let us also bear in mind that all of them could be strangers. So, how will anyone know that any transaction they actually received is legitimate?

One way to improve the situation is to change the way a transaction is recorded. What if every transaction has to indicate the source of the money being transacted? For example, Let’s look at the last transaction in the ledger above. Amy has to get the $3 from another transaction before she could give it to Joe. We know that she got it from Alice. Of course, she may have received the money from other transactions too (not listed here) and she could use any of those transactions as source for this transaction. The modified transaction T3, then looks like the one shown below.

Figure 4: Modified Transaction T3

You can see that all the outputs of a transaction have to add up exactly to the inputs. Since Amy is giving lesser amount of money than the source to someone else, she can give herself the change. If Amy needs to give $2 to someone else later, she can use this transaction (T3) as the source. There are two rules we need to impose for this to work:

  1. The source has to be a previously verified transaction (In the above example, T1 needs to be verified before it can be used as a source).
  2. A transaction can only be used once as source (T1 cannot appear in any other transaction as a source).

With this new structure of the transaction, Joe can have some faith that Amy indeed has the cash to give him $3. You may have already inferred that this creates an implicit “chain” of transactions all the way back to the very first time the dollar (or Bitcoin) was minted. Just to be clear — this is not the “chain” that Blockchain is referring to. There is another chain and we will get to it shortly.

We still have another issue to solve though — Joe may know that Amy does have the cash to give him $3, but how can he verify that it was indeed Amy who placed that transaction and no one else? (maybe someone malicious did it?) or from Scott’s perspective, how will he know that Joe didn't slide that transaction in maliciously to give himself cash? The solution is asymmetric cryptography. We have to digress a bit to gain the intuition on how this works.

Asymmetric Cryptography

Cryptography is the study of secure communication between two entities in the presence of adversaries. There are a few ways to do this, but where does asymmetry come into this? Lets look at a simple technique to motivate the need for asymmetry.

Imagine in a high school class, Alice wants to send a secret message to Joe to meet her at the cafeteria. The rest of the class, of course, are adversaries as she doesn't want any of them to know. The challenge is that Alice is not seated near Joe and she has to pass the message (on a sheet of paper)through her adversaries to Joe. What technique can she use to encrypt the message so that only Joe will understand upon receiving it?

Figure 5: Simple technique to encrypt a message, but requires prior secret communication

One technique is to displace the letters by some number, say 3. So if the actual message is “Meet me at café”, the encrypted message will be “Jbbq jb xq zxcb”. J is 3 letters before M, b is 3 letters before e and so on. In this case, the key of encryption is 3 and you need to know this key to decrypt the message. It can be argued that some one motivated enough can easily guess the key, but you could also design a more complex key. The real issue with this technique (no matter how complex the key) is that you need to have secret communication with the receiver before hand so that all future communications can be encrypted. Alice will have to let Joe know that the key is 3 before hand as shown in figure 5. This will not work when you need to communicate with strangers. Enter asymmetry.

Imagine everyone (in the class, keeping with the example)generates a pair of keys that are somehow mathematically related. One key, lets call it a “Public key” is distributed to everyone, including the adversaries (So you avoid the need for prior “secret” communication as in the previous technique). The other called the “Private key” is kept secret that only the owner knows. Now, when Alice wants to send a secret message to Joe, she will need to encrypt the message with the public key that Joe distributed to everyone. This message, then, can only be decrypted using the corresponding private key that only Joe has. Since the keys you use to encrypt and decrypt are different, it is called “asymmetric”.

Figure 6: Asymmetric Cryptography

There is fascinating math behind the generation of these keys, but is too involved to get into here. There is software that allows anyone to generate these key pairs. In fact, anytime you transact online, secure communication is established using asymmetric cryptography. This is what the “s” in https does in the URL of a website. Going back to our distributed ledger, Alice will digitally sign the transaction with her private key and others in the network can use her public key (That she needs to have distributed to every one in the network) to verify that it was indeed Alice that initiated the transaction.

Proof of Work

So far so good. The four people in our example can verify the following when they see a new transaction:

  1. The originator of the transaction has the required funds.
  2. The originator of the transaction is indeed who he/she claims to be.

There is one other issue we have not talked about. The transactions are broadcast across a network to the four individuals, which means that there could be network issues (or latency). At worst, some may not receive all the transactions or they may simply not agree on the order of the transactions. The individual copies of the ledger may deviate from each other. Which one is the the correct version? Once the consensus is reached on the correct version it also needs to be immutable (Remember, this was one of the main features of Blockchain).

Some malicious users may also take advantage of this situation to broadcast bad transactions hoping that it will make its way into the network’s ledger. lets say that Amy is dishonest and broadcasts another transaction, T5 immediately after the T3 transaction as shown below.

Figure 7: Double Spend Problem

Now, other users will reject one of these transactions (remember a source can only be used once), but which one they reject depends on which one they get first. Due to network latency described above, not every user may agree on which transaction came first. So Amy will be hoping that T5 will go through rejecting T3 and Alice, being her friend, maybe working together to direct funds to themselves. To address these issues, we need a protocol for consensus among the users to reconcile the transactions and discourage dishonesty. Let’s describe the protocol first and then explore why it works.

Everyone in the group collect the transactions they receive, verify them and create a “block” (set of verified transactions) and propose the block to be added to the network’s ledger. But, they have to earn the right to propose by winning a guessing game. Every individual needs to guess a random string called “Nonce” that you can add to the transaction contents (that you are creating a block with) which when passed through a hashing function gives a hash in a given range. This hash becomes the signature of the block. Once an individual wins the game they can propose the candidate block to be confirmed by the network. The candidate block should also include the hash of the previous confirmed block, effectively creating a chain all the way back to the first confirmed block. This protocol is the reason why it is called “blockchain”. The network’s ledger is essentially stored as a blockchain (as shown in Figure 8).

Figure 8: Blockchain

There is a key feature to the guessing game — There is no clever way to win the game, you have to use brute force. It is akin to searching a needle in a haystack. Everyone will have to spend the same amount of effort on average. If there is a cost to creating the block, they why does anyone do it? Well, you get rewarded in the form of new bitcoins. Every time a block is proposed and confirmed you mint new bitcoins. This is why the individual or entity who plays the guessing game is called a “Miner” and the process of creating the block — “Mining”. Just like in real mining, there is dedicated machinery used here. They are called ASIC’s(Application specific integrated circuit). Their only job is to play the guessing game.

Figure 9: A bitcoin mining facility(Source: Investing.com)

So, why do we need the miners to play this game? The main reason is to ensure that there is a cost to proposing a block. You need to spend some compute and hence energy (electricity) on the game. For example, today it would take you an average of 10 mins to guess the right answer. Going back to Amy and Alice, this cost should discourage them from being dishonest, as they may not win the game, but incur the cost for trying. Earlier, they could try for free.

At this point, you may be thinking that 10 mins of electricity powering a computer playing the guessing game doesn't cost that much to dissuade someone from cheating, especially if the reward is great when they win the game. To clarify this point, let’s imagine that there are more than four people in the network now and that Alice wins the game and proposes the candidate block. Joe and Scott (along with the rest of the network) will need to confirm the block, but after looking at the transactions in there they will reject it and create their own block as they will disagree on T3 vs T5. This will cause a fork in the chain and each individual in the network can now decide which fork they will continue working on. If the majority in the network feel that T5 should be rejected, they will continue playing the game with the fork that Joe and Scott created(by picking the appropriate previous block’s hash in their block). In the end, consensus is reached in the network by following the longer chain. What this means for Alice is that she not only needs to spend the money on the block she won, but continue to spend and add more blocks to her fork to keep it longer or she needs the cooperation of the majority of the network to be bad actors. This seems easy when there are only four people in the network, but not so when there are many more (given they are all strangers). Right now, there are close to 14.5K nodes in the Bitcoin network. This makes dishonesty infeasible (not impossible).

Figure 10: Fork in blockchain — longer chain in the fork wins the consensus

The chain also makes the transactions immutable (practically speaking), as any change to prior transactions would mean changing not just the block in which the transaction is residing but all the blocks subsequent to it and getting consensus on all the blocks. This is why the chain fosters trust.

References:

[1] The original white paper published by Satoshi Nakamoto — https://bitcoin.org/bitcoin.pdf

[2] MIT Open Courseware — Blockchain and Money https://www.youtube.com/watch?v=EH6vE97qIP4

[3] What is Proof-of-Work https://www.coindesk.com/learn/2020/12/16/what-is-proof-of-work/

[4] Asymmetric Cryptography — https://www.youtube.com/watch?v=wXB-V_Keiu8

--

--