Bitcoin: the basics
By: Dhruv Mohapatra
Tags: Distributed Ledgers, Proof Of Work, Bitcoin, Dlt, Crypto

I’ve been spending the last little while trying to wrap my head around Distributed Ledger Technology, so I figured I’d start with figuring out blockchains and bitcoin as they seem to be the most prevalent use case for the technology. As time goes on and I dig further I’ll make more notes but this is where we shall start. I’m still pretty new to this whole thing and for me to understand things I need to have a very clear picture of the general landscape so the article that follow will be just that, trying to wrap my head around this beast.

Bitcoin essentially converts the entries into a decentralized ledger into a currency. Was this easy to implement? Hells to the nah. I tried looking at some bitcoin script code and my head went woooooooooooooooooooooooooooo.

There’s a problem called the Byzantine General’s problem which tries to find a way to maintain trust in a network in the presence of suspect mofos. Bitcoin (admittedly using the proof of work solves it, I’ll expand on it later) needed to have a few properties. First, it had to be immutable so no guy can just jump in and start playing with the numbers. Second, because we wanted a ledger that would maintain state across the whole network, there had to be a way to pull the whole ledger immediately into every system. Cryptography and merkle trees helped us with that.

In 1991, Stuart Haber and W. Scott Stornetta proposed a system where a document gets created and signed (with a timestamp) and linked to the previous documents in the chain. Each previous document is linked to the successor with a pointer. No user can alter the timestamp of any document and no author can alter the message without forking a whole new chain and everybody knowing that some sus shit is going down.

So bitcoin lifted the basic idea from this, transactions replacing documents and layered in the incentivized proof-of-work scheme which made messing up the system way more expensive than maintaining its integrity and humans being the majestically selfish creatures we are, find it easier to not fuck it up…. At least for now.

So each block’s Merkle Tree..oh wait, let’s describe a Merkle Tree. Essentially, when you take 2 transactions and cryptographically hash them using SHA256 algorithm (don’t worry about it, just trust the very intelligent cryptographers and mathematicians on this one and rest easy knowing that this algorithm is just about impossible to decode) you come up with a bunch of numbers that look like you just faceplanted onto the keyboard. You take that hash and with another hash run that same SHA256 algorithm and you get some more keyboard pukes. You run it again and now you have a number that if every computer on the planet was busy just decrypting this one hash, it would take millions of years. Ain’t nobody got time like that.

So each block’s Merkle Tree’s leaf is a transaction (the L series data blocks in the figure). The node itself acts like a cryptographic digest (which is a way of saying ledger). You try changing even a single solitary letter or number anywhere and the changes ripple all the way down to the top hash and now you can’t be trusted by the other parties in the network.

All your friends trying to get into mining owe everything to the proof-of-work so let’s peek at it for a minute. The first proof-of-work concepts were developed by Cynthia Dwork and Moni Naor cuz they were tired of spam. They designed a system that would only process the emails when the computer sending them had done a certain amount of computational work. If spammers wanted to spam, cool, go right ahead and send your millions of messages, but they’d have to do millions of times of work as compared to the average user who’s sending one or two emails. Also, an important addendum to this is that the proof-of-work needs to be specific to the email otherwise the damn spammers would start flooding my inbox with a bajillion emails without any penalty. Another important thing to consider is that the recipient shouldn’t have to spend his resources to solve this puzzle that the proof-of-work instance generates.

John Douceur in his paper on Sybill attack, which is pretty similar to spamming and denial-of-service attack in that an attacker creates a large number of identities and tries to take over the network, proposed that all nodes should solve a hashcash puzzles. Let’s just say it’s a hard but not a super hard function that a computer needs to solve. Here’s Wikipedia filling us in.

Hashcash is a cryptographic hash-based proof-of-work algorithm that requires a selectable amount of work to compute, but the proof can be verified efficiently. For email uses, a textual encoding of a hashcash stamp is added to the header of an email to prove the sender has expended a modest amount of CPU time calculating the stamp prior to sending the email. In other words, as the sender has taken a certain amount of time to generate the stamp and send the email, it is unlikely that they are a spammer. The receiver can, at negligible computational cost, verify that the stamp is valid. However, the only known way to find a header with the necessary properties is brute force, trying random values until the answer is found; though testing an individual string is easy, satisfactory answers are rare enough that it will require a substantial number of tries to find the answer.

The hypothesis is that spammers, whose business model relies on their ability to send large numbers of emails with very little cost per message, will cease to be profitable if there is even a small cost for each spam they send. Receivers can verify whether a sender made such an investment and use the results to help filter email.

So if one guy was trying to look like 100 guys, we’d get him to solve 100 puzzles which he wouldn’t be able to do (I mean, unless they arent state funded….) and when they won’t be able to solve the puzzle, we’ll know they’re a fake.

Now, this method was limiting cuz what if, let’s say, the attacks do in fact find a way to fool the system by let’s say investing in hardware that in fact does solve the puzzle in the required time…. Then what? Well, this was a limitation of proof-of-work and a primary reason why it wasn’t able to solve the problem of spammers. But in a follow up paper in 2005 it was suggested that instead trying to isolate the faulty nodes, why not just mimic their behaviour and all nodes try to take over the network? Why would anyone spend the time and money resources to do that, you ask?

Because bitcoin. When the concept of a cryptocurrency was introduced into this mix, incentives lined up and it made sense to do the proof-of-work, and suddenly all my friends, their brothers, their sister-in-laws and their dads were investing in bitcoin.

One of the things that set Nakamoto’s invention apart is not just the innovation in ideas but a functional product that could be chipped away at by multiple contributors. So reading about all this is well and good, but I need to get coding ASAP.

In conclusion, one of the coolest things about bitcoin is its design and how circular the needs of every party involved are. We can only reward miners if there’s value to the currency. Double spending (that is, not being able to spend the same currency token twice, more on this in a separate post) and ensuring the currency has value globally can only be done if we have a decentralized shared ledger and finally miners are absolutely necessary to secure the ledger, which allows us to reward the miners with a currency that has value.

Brilliant, if you ask me. I wonder who will come up with the next big thing in deFi. It could be you. It could be me. Who cares, as long as it comes out and we can get some smoother systems in place, life will be alright.