March 28, 2020

Recreating Bitcoin 10:Transaction Script

Epilogue #

Gilfoyle had this ambitious thought of making Bitcoin a general world computer.

Satoshi and Gilfoyle had a general idea for its design.

Now it was time for implementation.

Transaction Data Model #

“How do we functionalize transactions?” Satoshi asked.

Gilfoyle gave his idea for implementation.

The current transaction model included:

IN: references two UXTO on her own address
OUT: creates two new UXTO, one for Bob and the other for change left to Alice
TXID: generates the Hash Value of current address.
ScriptSig: Alice’s digital signature + Alice’s public key

Server’s Verification Logic #

The server-side computing resources focused on if the ScriptSig was valid with the following steps:

Calculate the Hash Value of the current transaction data
Decrypt digital signature to get the TXID
Verify if the results from step 1 and 2 are the same. If they are the same, the ScriptSig is valid.

Conventional Modification Method #

There are two places to change.

Our purpose is to change transactions into function equivalents.

The traditional method suggests the following:

Select a well-developed functional script language such as JavaScript, Lisp or Forth
Use this language to assemble the ScriptSig part, not just to encrypt TXID.
Client is responsible for the construction of the function. That is, client uses the language to express the computing logic.
Server is responsible for the computation of the function. That is, server runs the code of ScriptSig and outputs the result to the transaction. Then it sends the message back to client.

Adding computing power

Problems and Defects #

Satoshi was not satisfied with Gilfoyle’s idea, “This idea is too traditional, not elegant enough. In addition, I noticed several problems and defects in the design.”

He continued:

Infinite loop: if the script code is written by the user and there is an infinite loop, Bitcoin’s server will be done.
Computation overload: even if there is no infinite loop in the code, if the code has too much script logic, the server will not be able to handle the computing required.
Mutable transaction data: the computing result of the script code should not be written again into the transaction data. The ledger should only record the original transaction data.

The Elegant Method #

We will address the above problems respectively.

Problem 1: Choose a script language without loop statements #

The most direct solution to the first problem is to choose a script language without loop statements. It would be Forth.

Forth is simple and stable. Like in Léon: The Professional, the most lethal weapon is the simplest one.

Forth is a dagger, stable and flexible

In contrast, script languages with loop statements are like heavy machine guns. Misuse and stuck magazine happen often. The more complicated it is, the more dangerous it is.

The complex programming language is a machine gun: although it is highly functional, it is not consistent

Problem 2: Transaction fee #

For the second question, to avoid over-complication of the computation logic, we adopt the transaction fee model: based on the byte size of the transaction, it adjusts the transaction fee. That is, more complicated script code results in higher transaction fee.

“How do we charge transaction fees?” Gilfoyle asked.

“We deduct the transaction fee from the leftover of IN over OUT. For example, Alice’s transaction references UTXO of 5 Bitcoin to send 3 Bitcoin to Bob. A UTXO of 2 Bitcoin should be created for Alice. But if the transaction has a fee of 0.1 Bitcoin, the UTXO to Alice will be 1.9 Bitcoin, and the server will create a UTXO of 0.1 Bitcoin for its address,” Satoshi explained.

“If the server believes the transaction fee of the transaction is insufficient, it will decline and sends it back to the client. We can set a bottom-line price of 1 Satoshi for 1 bit. 1 Satoshi is 100 millionth of a Bitcoin. This way the client has a basis for charging transaction fee when processing transactions,” Satoshi added.

Gilfoyle asked, “What could be the benefit of giving a lot of transaction fee?”
Satoshi said, “The advantage of giving a higher transaction fee is that it will prioritize the transaction to be processed first.” (see graph below)

Transaction fee

Problem 3: question (locking script) + answer (unlocking script) = a complete function #

For the third question, if the transaction becomes immutable, where would the output of the script be?

For example, Alice transfers to Bob, at the same time we want to calculate the result of 5-3.

The traditional method is to view 5-3 as a complete function. The server calculates the function, gets the result of 2 and writes it somewhere.

The reason for this method is that we view Alice as the constructors of the function and the server as the computer of the function.

If we break through this definition of roles and view Alice as the one which raises the question and Bob as the answerer to the question, then the role for the server is that of a verifier, that which verifies if the Bob’s answer is equal to Alice’s question.

That way, a function is separated into two parts, one for question and the other for answer. The server combines these two parts to get the complete function and verifies if the result is correct.

We will call the script code that represents the question “UTXO locking script.”

We will call the script code that represents the answer “UTXO unlocking script.”

When server verifies if the UTXO is valid, it is essentially combining the two scripts and executing them. The result is either “True” or “False.” If it is “True，” then it continues to execute. It is “False,” then it stops the execution. That way there is no need to store the result.

So essentially, whether or not a UTXO can be spent depends on whether or not the unlocking script can unlock the locking script.

We can organize this series of steps as followed:

Alice = the one who raises the question and creates the UTXO. The UTXO has the locking script with it.
Bob = the one who answers the question and references UTXO. The UTXO has the unlocking script with it.
Server = the verifier of the question. It combines the locking script and the unlocking script to verify if the result is “True”.

Refactoring the Transaction Data Model #

The detailed structural changes to the transaction data model looks as followed:

OUT adds a locking script to every UTXO generated: scriptPubKey
IN adds an unlocking script to every UTXO referenced: ScriptSig
Removes the ScriptSig in previous transactions

(see graph below. The graph details the changes, with red signifying the changes. We will see each UTXO has a part of unlocking and locking scripts)

The transaction data model after the addition of locking and unlocking scripts

As in the above graph, the locking script is: 3 OP_ADD 5 OP_EQUAL. The unlocking script is: 2.

Server views ScriptSig + ScriptPubKey as a complete function, as followed:
2 3 OP_ADD 5 OP_EQUAL

OP_ADD is addition. OP_EQUAL outputs “True” if they are equal, “False” if not.

This script means if 2+3 equal 5. If they are equal, the server verification passes.

Transaction model in JSON:

Two related transaction pair constitute a standard function equivalent.

The computing resources of the function moves from the server to the client, essentially making all Bitcoin clients computing resources.
The server only verifies to ensure trust, so essentially Bitcoin is a trust engine.

Since transaction realizes function equivalents, Bitcoin realizes Bitcoin as a general computer.

The next step will be how to make Bitcoin a world-class general computer.

Epilogue #

The first half of the book is now complete. It mainly covers the transaction part.

The second half explains how to evolve Bitcoin into a swarm system. In order to better support Transactions which is the core business of this system to achieve ultimate freedom and fairness.

Next chapter ：Recreating Bitcoin 11:Swarm System (Part I)