March 28, 2020

Recreating Bitcoin 7:UTXO

Prologue #

The second version of Bitcoin has been launched and was running without issues.

Important changes included:

Adding digital signature
Replacing usernames with public keys
Adding the digital signature to the transaction model
Deleting the account model

This chapter talks about how to redefine transactions.

Transactions are the core of economic theories. Transactions are everything.

Transactions carry not only the motivation of each individual, but also the mottle of the whole world. Understanding the concept of transactions determines how high Bitcoin can reach. How to understand transactions reis determined by how to define transactions.

The Bug #

After the launch of the new version, everything seemed to be running normally.

However, where there is human design there are bugs.

One day, Alice found Satoshi and told him that her balance returned to zero and suspected that her private key had been leaked.

Satoshi immediately checked the server and looked up the transaction records in the ledger. He discovered that there was something wrong about the Alice’s transactions.

How would there be repeated transactions (see graph below)?

Ledger

Satoshi asked, “Alice, how many transactions did you have?”

“Just once. I sent Carol 20 Bitcoin yesterday,” Alice said.

“But, I have here three transactions to Carol in the ledger,” Satoshi said.
Satoshi found Gilfoyle to take a closer look at the situation and found the problem.

It turned out that Carol played a trick to the server. He intercepted Alice’s transaction request and sent it to the server repeatedly. The server received the requests and processed all of them. The result was all of Alice’s balance went to Carol (see graph below).

Carol’s trick

Analyzing the Bug #

What was the cause of the problem?

It turned out that the problem originated from the signature. In the current design, different transactions from the same address had the same signature.

The server would only verify the authenticity of the signature. As long as the signature was authentic, it did not care about duplicates.

Hackers would repeatedly send fake transaction requests until the balance was depleted.

So why did the signatures not vary for each new transaction?

That was because the signature was to encrypt the public key. As long as the public key was the same, the signature would stay the same.

The same signature meant that it could access all of the address’s balance.

Up to this point, Satoshi said to Gilfoyle, “We need to make every signature in transactions different. It’d better be a unique signature.”

How could they make every signature unique?

Gilfoyle said, “Encrypt the whole of transaction data, because transaction data vary from transaction to transaction.”

This solution looked pretty good but was still problematic.

Satoshi said, “If the user wants to send two transactions at the same time, would the server decline the requests then? If the server doesn’t decline the request, what if the hacker is sending repeated requests like as in the bug
Alice experienced?”

Gilfoyle said, “Then we can modify the transaction model and add a random number parameter that the browser creates at the creation of transaction data. This way each transaction won’t be repeatable.”

Satoshi said, “That’s too complicated and old-fashioned. Not elegant enough. Also, random numbers can occasionally be the same even though the chance is extremely small.”

Satoshi closed his eyes, trying to search for an intuitive solution that he felt was just so close.

A Non-Conventional, Elegant Solution #

The initial problem of Bitcoin was the signature having locked on the whole of the balance.

After the version update, the signature was fixed on the transaction.
But now the new problem became that transaction data could be duplicated.

The question became: how to make each transaction unique?

What is the nature of transaction?

Transaction is essentially the change in ownership of Bitcoin. That is, the ownership of n amount of Bitcoin transferred from the sender to the recipient.

For example, Alice transferred 3 Bitcoin to Bob. In essence, what happened was the ownership of that 3 Bitcoin went from Alice to Bob. How can we make this unique?

Alice is a constant. Bob is a constant. 3 Bitcoin is also a constant.

But, 3 Bitcoin can change! That is, if each Bitcoin has a number, then each Bitcoin is different.

Suppose on Alice’s balance, there is 6 Bitcoin, numbered Bitcoin001 to Bitcoin 006.

Then the description of this transaction becomes: the ownership of Bitcoin001, Bitcoin002, Bitcoin003 transferred from Alice to Bob.

Next time Alice wants to transfer 3 Bitcoin to Bob, the description becomes: the ownership of Bitcoin004, Bitcoin005, Bitcoin006 transferred from Alice to Bob.

When Bitcoin is tagged with a number, the transactions that were previously undistinguishable from each other can now be differentiated. The description of transactions now has become semantically unique.

Every Transaction is First Melted and then Created #

Transactions are the core of economic theories. Transactions are everything.

Satoshi followed this line of reasoning and felt he was on the right track. But the plan now was still too rough and needed further deliberations.

To tag Bitcoin with a number was to view each Bitcoin as a coin, divisible to the unit of 1 but indivisible further.

Each transaction required detailed accounts of each Bitcoin’s number.
However, although transactions now were semantically different, there were two issues.

First, if Bitcoin would be very clumsy in use if it didn’t support fractional transactions as in cents in dollars.

Second, if the transaction amount was too big like 10,000 Bitcoin, the referenced Bitcoin numbers would create a large package of transaction data too. This would be equivalent to using one-dollar bills to pay for a $10,000 check.

Suddenly, it dawned on Satoshi:

What if every transaction mints a new amount of coins? That is, make a bunch of coins into a new coin of a larger amount.

This way, the new coin minted in each transaction can be used by the next transaction, only to be used once (since if used multiple times, a “double spend” problem is created, an idea we will talk about later).

Of course, the current transaction also uses the coins minted previously in one or more transactions (see graph below).

UXTO

The coins used by a transaction are melted (IN) and minted again to create the new coin of the larger amount (OUT).

In the ledger, the unused coins in the transaction are called: Unspent Transaction Output. We use TX to represent transaction, so we ultimately get: UTXO.

The balance of an address is essentially the total of the UTXO it can use.

“Brilliant! So how do we deal with change? Alice uses a coin in the amount of 5 but only wants to give Bob 3.5 Bitcoin,” asked Alice.

Satoshi replied, “We mint two OUT coins, 3.5 and 1.5 respectively. The 3.5 one goes to Bob and the 1.5 one stays to Alice. This is like how we break for change in real life.” (see graph below)

UTXO creates change for itself

Every transaction references UTXO generated by past transactions and mints new UTXO for future transactional use.

All transactions connect with the one before and after, creating a continuous flow of records that starts from the beginning and branches off in the process.

From this standpoint, the Bitcoin system is a river of time consisted of transactions.
The technical term to describe such data structure is: Directed Acyclic Graph (DAG) (see graph below).

Directed Acyclic Graph

In the head of Satoshi, he was running simulations of the new design: the current design should have no big problems. We can start designing the new transaction model.

“UTXO is indeed elegant. The transaction model will change a lot,” Gilfoyle added.

The so-called transaction model design is restructuring the transaction model to accommodate the UTXO mechanism.

Epilogue #

The part of UXTO is now complete. The next chapter is about restructuring the transaction data model and also includes the mechanism for locking and unlocking scripts.

Important distinction: “Semantically unique” and “syntactically unique” #

Semantics means what the meaning of a sentence wants to express.

The meaning of grammar is, in what form, the language is organized.

Semantics is the essence, and grammar is its manifestation.

The semantics are unique. That is, the meaning expressed in one sentence is deterministic. Take this sentence: “The number is Bitcoin001, Bitcoin002, Bitcoin003’s Bitcoin ownership, from Alice to Bob.” There is no ambiguity in comprehending this text. Even if the server executes this sentence multiple times, result would be the same, and Alice’s balance will only be reduced by 3 Bitcoins, and she will not lose money.

However, the description could be semantically ambiguous: “The ownership of three Bitcoins, from Alice to Bob.” If the server receives a duplicate request, it can’t determine its exact meaning: whether Alice really wants to pay more, or if the client experienced a problem (a request made by a transaction) or an attack because a hacker intercepted the message.
The traditional solution is to use grammatical uniqueness instead of semantic uniqueness.

Grammatical uniqueness is similar to phrasing a sentence in different ways.

Adding a random number is one of the implementation methods, like this:

“Random number 001, ownership of 3 Bitcoins, changed from Alice to Bob”

“Random number 002, ownership of 3 Bitcoins, changed from Alice to Bob”

“Random number 003, ownership of 3 Bitcoins, changed from Alice to Bob”

With the addition of random numbers, the server can disregard repeated quests as abnormal data.

So the current system vulnerabilities are essentially flaws in the definition of transactions. That is, they are not semantically unique.

Next chapter ：Recreating Bitcoin 8:System Refactoring Based on UTXO