March 28, 2020

Recreating Bitcoin 3:Getting Rid of the Account Model

Prologue #

Bitcoin’s first version had launched. The significance of this milestone is that it demonstrated the application of the system.

Cancelling the Account Model #

Since the launch of Bitcoin v0.0.1, business of the cafe had been getting better and better. Bob obviously made a wise decision.

Satoshi, however, grew gradually more annoyed, “Too many people are coming to me to register account and exchange Bitcoin. I don’t even have time for coding. I need to think of another way. Maybe I can delegate the exchange work to Bob.”

Satoshi went to the cafe and asked Bob, “Hey Bob. A lot of people are coming to me for Bitcoin. Now I don’t have time for system upgrade. How about you handle the exchange work?”

“No problem! That works fine with me. But can I adjust the exchange rate?”

“Of course!”

Bob agreed happily. Satoshi told Bob his username and password. Bob’s cafe officially became Bitcoin’s offline exchange.

Satoshi was relieved, “Now I can finish up the remaining user registration function.” He took out his laptop as he was thinking.

A thought flashed through Satoshi’s mind: can I completely do away with account registration?

The reason why the account registration process exists is that every user needs to create a record in user.txt.

Every record has three parts: username, password, and balance.
If there is another way to replace these parts, getting rid of the account model would be easy.

Username can be replaced by transaction.txt, because every transaction record includes the username of the sender and the recipient. So transaction.txt can replace user.txt to locate the username.

Balance can also be replaced by transaction.txt. Because the file is essentially a full transaction record, the accumulated transactions can yield the current balance. So transaction.txt can now replace user.txt to obtain balance (the specific process to obtain the balance is shown in the graph below).

Two ways to obtain the balance

After solving the username and balance issue is the most difficult part - how to get rid of password.

The role of password is to prove to the server that Alice is the real Alice, instead of some fake Carol - unless Carol managed to get Alice’s password.

Therefore, the essence of password is a key.

Is there another way?

“What about symmetrical encryption?” Satoshi thought.

Symmetrical Encryption #

Symmetrical encryption is a commonplace encryption method.

For example: John sent a message to Peter, “See you at 11 tonight by the river.” But the message is in clear text. If it is intercepted, the secret is blown.

Symmetrical encryption can solve their worry: once John encrypts the message with a commonplace encryption algorithm, cleat text will turn into secret text, which looks like this:

U2FsdGVkX18tGXt20Jb/mu
CW7ipyKF5fTbNV9gUkJZx
RIVNGk6ziokkrOXyZ8qkh

Even if it is intercepted, no one would understand it.

Setting the clear text and the secret key as the parameters, pass them into the encryption algorithm to get the secret text.

The pseudo formula has the form:

function encryption algorithm (clear text, secret key) = secret text

Encryption algorithm is public, but the secret key is private. John and Peter share the same secret key for the content. Others won’t be able to decrypt because they don’t know the secret key.

“Encrypted” Chat

If John was Alice and Peter was Bitcoin’s server, Bitcoin would have the communication encryption capacity.

Secret key is first generated at the server’s end. Alice is assigned one upon first login. The key is stored in the browser after it was assigned.
Server also needs to store the relation between Alice and this secret key.

Afterward, every time Alice sends a message, it would be encrypted with this key. After the server receives a message from Alice, it can use the same key to decrypt the message (see graph below).

Symmetrical Encryption

But can replacing password with secret key solve the problem?
Remember our original problem?

We wanted to get rid of the whole account model, not just the password. If we lose the password but added the secret key, it’d be same old stuff but with different labels.

Account registration can be seen as the server assigning the key to the user (see graph below).

Replacing password with secret key

“Is there a way to let users independently create a ‘key’?”

Satoshi again fell into deep thought.

“There’s asymmetrical encryption,” said slowly by a bearded man sitting at the other side of the cafe.

Satoshi looked at the big beard. The man had a laptop in front of him as well.

“You also a coder?” Satoshi asked.

“Yes,” big beard said, expressionless.

Satoshi reached out his hand happily, “Ha! Not easy meeting another developer in Midway. Hi. I’m Satoshi. Yours?”

“Gilfoyle,” he blinked this time, with a slight node, probably a sign of friendliness.

This historic moment should have been photographed. Two genius developers met in Midway. Bitcoin, in their sustained cooperation, far exceeded the level of understanding of their peers, reaching a level unimagined before.

Asymmetrical Encryption #

“You said asymmetrical encryption can solve my problem?” Satoshi asked.

“Yes,” Gilfoyle nodded, and started to explain, “What you need is not encrypting the clear text. Disclosing the clear text is not an issue. What you need is a unique sign that proves ‘I am I.’ Asymmetrical encryption can achieve that.”

Gilfoyle further explains the details. “That’s it!” Satoshi exclaimed having listened to him all the way through.

Asymmetrical encryption is magical. It originates from an ingenious mathematical principle (Elliptic Curve Cryptography). It’s unlike symmetrical encryption where Alice and the server use the same key.

In asymmetrical encryption, Alice can independently generate a pair of keys, one public key that everyone can know and one private key that only Alice knows.

Public key and private key

Asymmetrical encryption is like a magic box. There’s a key (private key) to lock it up but it cannot open the box. For opening the box, there is another key (public key). This method is rather counter-intuitive, which is why it’s called “asymmetrical encryption.” (see graph below)

Public key and private key

Precisely because of this “asymmetrical” feature, Alice can use the private key to encrypt the transaction data (“Alice to Bob 30”), get the encrypted message (“e2edeae7a01d226367ccb0220447d8f1dfcf14f6defb9bf”), put the message and the public key into the transaction as parameters, and send it to Bitcoin’s server (message = encrypted message + public key).

Bitcoin server receives a message and gets two data: encrypted message and public key. It uses the public key to get the decrypted text “Alice to Bob 30.”

Based on the feature of asymmetrical encryption, if the public key can decrypt the encrypted message, the encrypted message must have been encrypted by the corresponding private key. So we can determine that the sender of this message is Alice.

So in Bitcoin’s use scenario, using asymmetrical encryption is not to protect the message but to prove “only I can generate this message,” thus proving “I am I.” (see graph below)