This is not investment advice. The author has no position in any of the stocks mentioned. Wccftech.com has a disclosure and ethics policy.
This article is part of a series on the world of cryptocurrency and Blockchain as we extend our financial coverage to include those. The first milestone is naturally going to be about Bitcoin, or more accurately, a gentle primer to the first generation Bitcoin Blockchain.
So what is a blockchain anyways?
Blockchain has become an overused and abused buzzword in the world of finance now. Few people understand how it works (unless you are a computer science student) and even fewer understand the possible improvements. To understand Blockchain, we need to start at a very fundamental problem that has been prevalent in the entire history of financial transactions, the problem of trust.
Starting with the trust-less assumption
Imagine there are three people sitting in a bar: Alice, Bob and Charlie. None of them trust the others. None of them are present at the bar at the same time of the day but let us assume due to some odd reason they have to share the open tab. The conventional idea that comes to mind is to simply record the transactions in the tab in front of the name of the person.
The tab may look something like this:
A bought a drink $10
B bought a drink $20
C bought a snack $5
At the end of the week, they reconcile the balances and pay their dues. Now the immediate problem that arises with this is that that any of them can write entries in anyone else’s name. Alice can write an entry into the ledger in Bob’s name and vice versa. The same goes for Charlie. Let’s assume they have now gotten a bit smarter and they start signing their entries with their signatures so the ledger starts look something like this:
A bought a drink $10. Signed Allen
B bought a drink $20. Signed Barney
C bought a snack $5. Signed Charles
The tab has now become slightly harder to tamper with, but it’s still possible. If any one of them has a stable enough hand, they can forge the signature and create false entries quite easily. So the problem of trust isn’t solved still. This is where conventional wisdom comes to an end and we start to branch off into computer science. This is also where a hash comes in and the entire concept of private and public keys.
A computer signature, or a hash, has 3 major components. The message, the private key and the public key. Before we get into that detail however, we need to understand what a merkle tree and a merkle root is. You can actually try a very basic merkle root yourself: write down any 10, single digit numbers in a row. Now on top of them, add every 2 numbers together. Rinse and repeat till you just have a single number remaining. This is your merkle root. Now, if you change any number at the bottom of the tree, the root will change as well. In this example, it is possible to replace numbers without changing the root since we are using simple addition, but if you are using a hash function (which works on prime numbers by the way) it is pretty much impossible to do so. (As an exercise, try decrypting this SHA 256 hash over here: 1F7274540291759F86A09FD121A9C9FF26D433628C2B6FE472063D164E64E323).
Now back to the original problem. The digital signature will consist of the message, which is encrypted (or hashed) with the private key. And anyone can use the public key to verify that the message was in fact hashed with its private key pair. Think of it like this, every user has 2 unique locks and each lock has only 1 known key. One lock can be used to lock the box, and the second one can be attached to the handle of the box to act as an identifier. I’ll keep the key to the lock that opens the box, but hang the key to the one that opens the non-essential lock in my home in a key ring with my name on it. Let’s say 4 other people use the same tactic. Now anyone can simply pick up my private key and see if it opens the non-essential lock on the box. If it does, the first lock is mine as well.
Adding cryptographic hashes to the mix
Allen, Barney and Charles are now signing their transactions using their digital signature. So we get the following:
Allen bought a drink $10. [HASH]
Barney bought a drink $20. [HASH]
Charles bought a snack $5. [HASH]
All three have signed the transaction with their private keys and can use the public key of the others to check whether a message was truly signed by them. This solves the problem of forging transactions. But there is now a new problem. While you cannot fake a transaction, any one of them with a malicious intent could simply duplicate the transaction (you do not need to know the contents of the hash to copy paste it). Another fundamental problem now exists as well. We set out to remove the element of trust. But A, B and C still have to meet up at the end of the week, and pay up their dues. That’s not exactly the most trust-free of networks.
The solution, then lies in a ledger that has its own supply of coins or tokens.
Let’s say the bar tender offers them the following solution. A, B and C will pay the bar tender $300 and he will put in the first entries that denote the 10 Bar Tender Tokens to each A, B and C (with an implicit exchange rate of $10 for 1 BTT). He also suggests that the entries be serialized and have a unique identifier with each entry, so a malicious entry cannot simply copy existing entries. Since they are now starting with a fixed money supply (30 BTT), over spending is no longer a concern. The newly distributed ledger now looks something like this:
- 10 BTT Added to Allen’s Account [Hash]
- 10 BTT Added to Allen’s Account [Hash]
- 10 BTT Added to Allen’s Account [Hash]
- Allen bought a drink 1 BTT. [Hash]
- Barney bought a drink 2 BTT. [Hash]
- Charles bought a snack 0.5 BTT. [Hash]
The significance of the serial numbers is that they are included in the hash now, so duplicating entries is no longer possible. Since the money supply is now fixed in the start, it is not possible for Allen, Barney or Charles to have any counterparty risk – since they can only spend what they have. There’s another problem that Allen, Barney and Charles see, but the bar tender does not. They don’t really trust the Bar Tender either so they ask him to suggest a solution to that problem as well. Being the good sport he is, he suggests a new distributed ledger, so each of Allen, Barney and Charles carry a copy of the ledger and receive any transactions over the internet at all times.
The "block" breakthrough
But how do you make sure that all ledgers look exactly the same? Well. That’s where blocks come in. Since each transaction can only be verified if you know the last one (notice you can only verify Allen has 10 BTT available when he bought the drink, if the previous transactions had already been verified), the bar tender suggests that the transactions should be processed in “blocks”. He doesn’t want to spam A, B and C so he suggests reconciling ledgers in blocks of 5 transactions. The newly distributed ledger now looks like the following:
[Hash code of previous block]
- Allen bought a drink 1 BTT. [Hash]
- Allen bought a drink 1 BTT. [Hash]
- Allen bought a drink 1 BTT. [Hash]
- Allen bought a drink 1 BTT. [Hash]
- Barney bought a drink 2 BTT. [Hash]
[Hash code of this block]
This is a block, and as time passes and blocks are accumulated, you get a Blockchain. Allen, Barney and Charles are now completely satisfied, they think this is a pretty much impossible to beat solution and looks like it cannot be tampered with. So they get ready to leave. Fortunately for them however, the bar tender points out the obvious flaw:
Calculating all those hashes is going to take a lot of time, it took him 10 minutes to crunch the hash and he used his best calculator. There’s also the fact that even then, a particularly malicious agent might send out fake transactions with wrong hashes. How do you make sure that the hashes are real? And how do you solve the computational power requirement? The answer he suggests is by incentivizing some of his other customers to act as ‘miners’.
Getting a block-chain
He suggests adding a puzzle to the end of every block. To calculate a hash that ends with 20 zeros. That puzzle when ‘mined’ will authorize the person to process 1 block of transactions. But of course, if they spend 10 minutes of their time to do some maths for unknown strangers, they will probably want to be rewarded for it. He suggests tipping that person, 0.1 BTT per block. That seems like a fair deal and will allow Allen, Barney and Charles to enjoy a completely trust free system, so they readily agree. The final version of a given block in their newly created BTT Blockchain, looks like this:
[Hash code of previous block]
- Allen bought a drink 1 BTT. [Hash]
- Allen bought a drink 1 BTT. [Hash]
- Allen bought a drink 1 BTT. [Hash]
- Allen bought a drink 1 BTT. [Hash]
- Barney bought a drink 2 BTT. [Hash]
- Mining reward 0.1 BTT [Hash]
[Hash code of this block with hash ending in 20 zeroes]
This is now a virtually untamperable system and they have created what we call a Blockchain system. This is obviously a very simplified explanation of one, but should serve to give you a basic idea of what it entails. The difficulty (or how many zeros their needs to be at the end of a given hash) will go up as more and more miners enter the ecosystem with block rewards going down. If anyone tries to hijack the system, they will fail. Because while someone might get lucky calculating a hash ending in 20 zeroes, faster than the entirety of the Blockchain, they cannot get continuously lucky for every single block there on and eventually, the raw computational power of the Blockchain will catch on and simply invalidate the malicious block.
Notice I say it’s virtually untamperable, because there is no known way to tamper with the chain through a malicious agent, there is actually a very well-known weakness of the first generation Blockchain: the 51% attack. Basically Allen and Barney can collude and control 51% of the chains power and roll out hashes ending with 20 zeroes faster than anyone else, and the “valid” chain will never be able to catch up. This is why to ensure safety of the chain, they need to bring in as many miners as they possibly can, because the more there are, the harder it will become to mount a 51% attack.
Second and third generation blockchains have gotten around this problem using a new algorithm like Proof of Stake instead of Proof of Work, but that’s a discussion for another time. Hopefully, this will serve as a nice gentle primer to Blockchain tech.
