How To Invent Bitcoin Part 1

Understanding the Bitcoin Problem Statement

I recently watched an awesome YouTube video about how Bitcoin actually works. This video covered the core problems that Bitcoin needed to solve in order to function as a currency and how it solved those problems. This video did not focus on making a case for the utility of Bitcoin.

I thought this video did such a great job at explaining how Bitcoin worked, that I wanted to write a post summarizing it. If you have a half hour to watch a YouTube video, I recommend watching the video.

My summary will be broken up into two posts. In the first post we will build up to understanding the problem Bitcoin had to solve. In the second post we will understand how Bitcoin solved the problem.

Lets dive in…

Once upon a time there were four friends — Alice, Bob, Charlie and Drew. These friends did a horrible job of remembering to carry cash. So they would end up buying things for each other all the time, and then squaring up later. In order to keep track of who owed who what. They decided to keep a ledger. The ledger looked as follows

Alice pays Bob $100
Bob pays Drew $30 
Charlie pays Alice $35
....

If Drew bought some tacos for Bob that cost $20, then Bob would write on the ledger Bob pays Drew $20 thereby indicating Bob’s promise to pay Drew back. At the end of the month the friends would gather together and read through the ledger. Friends that had a negative balance on the ledger for the month would put the absolute value of their negative balance in cash onto the table. Friends who had a positive balance would take the value of their positive balance off the table.

As long as these friends record every transaction to the ledger and as long as they all square up at the end of the month, then this system would work great.

Alice, Bob, Charlie and Drew were so happy with their system that they started to tell everyone they knew about the system. Other people wanted to join their system. But Alice, Bob, Charlie and Drew did not trust those other people as much as they trusted each other. This lack of trust presented them with their first problem — how do they know if they should trust a line in the ledger when anyone can write any line in the ledger?

Let’s suppose they added a member named, Enemy, to their group. Perhaps the name should have been a giveaway that this was a bad idea…. Let’s suppose that Enemy is always out to cheat their system for his own gain.

Enemy will cheat their current system simply by appending Alice pays Enemy $1,000 in the ledger, even though Enemy did not buy anything for Alice. In order to address this problem we need to introduce signatures to the ledger. As long as every member of the group can produce a signature which no one else can copy but everyone can recognize as valid, then having the payee sign every line of the ledger thwarts Enemy’s first attack.

At this point the ledger will look as follows

Alice pays Bob $100 Alice
Bob pays Drew $30 Bob
Charlie pays Alice $35 Charlie
....

Now Enemy cannot simply append the line Alice pays Enemy $1,000 because Enemy would not be able to produce Alice’s signature.

Now let’s suppose these friends wanted to move this ledger to exist online. Once they move this ledger online, they are faced with another problem. They need a way to sign the ledger digitally. This gets solved with a cryptographic tool known as public/private keys. A public/private key pair has the following properties

• Everyone knows everyone else’s public key.
• Each person knows their own private key but no one else knows anyone else’s private key.
• The public and private keys are actually just very very very large numbers.
• Anyone can sign any message with their private key by using an encryption function that everyone else knows about. This looks like Encrypt(Message, Private Key) = Encrypted Message Notice that this Encrypted Message is uniquely generated taking a private key and an unencrypted message as input. This ensures that only the owner of the private key could possibly produce that Encrypted Message for the given Message
• There is another function used to verify an encrypted message. This looks like Verify(Encrypted Message, Public Key) = True/False This function will only return true if the Encrypted Message had been encrypted using the private key that pairs to the the public key given in the Verify function.

Given these properties public/private keys enable the group of friends to produce digital signatures on their ledger. At this point the ledger looks like

Encrypt(Alice pays Bob $100, Alice's Private Key)
Encrypt(Bob pays Drew $30, Bob's Private Key)
Encrypt(Charlie pays Alice $35, Charlie's Private Key)
....

The next attack that Enemy will make is to buy Alice some tea, then have Alice produce the encrypted message, Encrypt(Alice pays Enemy $10, Alice's Private Key)and now that Enemy knows what that line looks like, Enemy can just copy and paste that line as many times as he wants. Enemy would not be able to sign a message with a different amount because Enemy does not have Alice’s private key to sign such a message, but as long as Enemy copies and pastes the same exact message other and over again, Enemy can take as much money as he wants from Alice.

In order to solve this problem the friends must introduce a unique attribute on every message. Simply numbering the messages in the ledger or including a strictly increasing timestamp will do the trick. At this point the ledger looks as follows

Encrypt(1. Alice pays Bob $100, Alice Private Key)
Encrypt(2. Bob pays Drew $30, Bob Private Key)
Encrypt(3. Charlie pays Alice $35, Charlie Private Key)
....

Now Enemy cannot simply copy and paste the same line over and over again because the friends will be able to see that it is a duplicate line. The friends can just ignore any duplicate line.

The next attack that Enemy could try is just to rack up massive amounts of debt on the ledger, and then at the end of the month when it is time to square up, Enemy just does not show up. Actually more generally the only reason the friends need to square up on some regular timeframe is to keep each other honest. Converting the ledger transactions to USD is nothing more than an integrity enforcement.

Suppose the ledger itself kept a record of how much money each person had. Furthermore, suppose that the friends always required all friends to keep a non-negative balance on the ledger. With these two invariants in place there would no longer be any need to square up at the end of every month. In fact the currency recorded on the ledger would not even need to have any relationship to USD currency. The transactions on the ledger would be their own thing entirely.

Once the ledger transactions become decoupled from the currency that was being used to enforce integrity, exchange rates can start to exist between ledger transactions and other currencies or goods. For example Alice could pay Bob $10 USD and in exchange Bob could sign an entry on the ledger which says Bob pays Alice 20 Ledger Dollars

Given this understanding lets start referring to the currency on the ledger as Ledger Dollars or LD

The next observation to make about this model is that the history of transactions is itself the currency. There is no need to actually have any entity you can point at (physically or digitally) which is a Ledger Dollar instead the history of transactions itself is the currency. Said another way, the record of money moving between users is the currency. Lets look carefully at the following ledger in order to see this

Encrypt(1. Alice pays Bob 50LD, Alice Private Key)
Encrypt(2. Bob pays Drew 15LD, Bob Private Key)
Encrypt(3. Charlie pays Alice 17LD, Charlie Private Key)
....

This ledger is simply keeping track of the history of transactions. This history can be read through to figure out who has how much, but it is the history that is the currency.

Let us summarize the two points that resulted from the removing of the squaring up step.

1. New Currency Type: The currency on the ledger is totally decoupled from any other currency. It is its own thing which can be exchanged at fluctuating rate for other currencies or goods.
2. History is the Currency: The history of transactions is the currency, there is no separation between the two.

Up until this point we have taken for granted that the ledger simply exists in some centralized safe place that all the friends have access to. Having the ledger in a centralized place implies the existence of some centralized owner which can enforce safe access to the ledger. The downside of a centralized owner, is that owner has a lot of power over the users of the currency.

• Inflation: The centralized owner has the ability to create new currency. Thereby inflating the existing currency. A real life example of this is a government printing new money.
• Controlling Terms of Exchange: The centralized owner has the ability to control how users use the money. A real life example of this is Amazon banning certain items from being sold on its market place.
• Fees: The centralized owner can impose fees for transactions. A real life example of this is Visa charing transaction fees.
• Controlling Which Parties can Transact: The centralized owner can restrict certain parties from transacting. A real life example of this is governments enforcing a trade embargo between countries.
• Demonetization: The centralized owner can declare the currency is no longer a valid form of money. A real life example of this occurred in 2016 when the Indian government demonetized the 500-rupee note and 1000-rupee note.

If the currency is created and controlled by a centralized party — that centralized party has a lot of power. I will not make any claim about if it is good or not to have this centralization, that is a big can of worms, but I think it should be clear that a central owner has a lot of power.

If we suppose that the group of friends wanted to build this ledger without requiring deference to a centralized entity. They would need to invent a decentralized, verifiable, consistent ledger. This is what the creator of Bitcoin invented.

Stated more formally, the problem statement for the creation of Bitcoin is

Can you come up with a protocol to accept or reject transactions and in which order, so that you can feel confident that anyone else in the world who is running that same protocol has a personal ledger that looks the same as yours. This problem must be solved without any centralized party and the protocol must continue to work even if bad actors run malicious protocols designed to thwart the system.

The following post will explain how Bitcoin solved this problem.