Recreating Bitcoin 8:System Refactoring Based on UTXO

Refactoring Transaction Model #

In his head, Satoshi runs a simulation of UTXO’s design: “there should be no major flaws in the design now, so we can go into the design of the trading model.“

Gilfoyle said: "the UTXO is really elegant and the transaction model will change a lot.”

The new transaction model comprises four parts:

  1. TXID: Hash Value of the transaction (as to what Hash is, there will be detailed explanations later. For now, it can be understood as: any data as a parameter entered into the hash function will produce a unique fixed-length character string. That is, Hash = FuncHash(m))

  2. IN: all the UTXO referenced by the current transaction.

  3. OUT: all the UTXO generated by the current transaction.

  4. ScriptSIG: the signature script of the current transaction – digital signature (encrypted) + sender’s public key (unencrypted)

For a more detailed look into these terms:

TXID: the Hash Value calculating the transaction data. TXID = FuncHash (TX)

UTXO numeric fields referenced in IN: TXID, VOUT (VOUT is the queue number of the UTXO in its TX)

UTXO numeric fields generated by OUT: queue number, public key of recipient, amount

Encrypted digital signature: encrypted text generated by TXID. Digital signature = FunSig (sender’s private key, TXID)

ScriptSig: encrypted digital signature + sender’s public key.

For an example scenario: Alice is sending 3.5 Bitcoin to Bob.

Alice’s browser needs to create four parts for the transaction:

  1. IN: references two UXTO on her own address

  2. OUT: creates two new UXTO, one for Bob and the other for change left to Alice

  3. TXID: generates the Hash Value of current address.

  4. ScriptSig: Alice’s digital signature + Alice’s public key (see graph below)

图片 1.png

Refactored Transaction Model

Using JSON structure to represent the transaction model (see graph below):

图片 1.png

Transaction Model in JSON

From now on every transaction in the ledger would have the following data in JSON format:

图片 1.png

Refactored transaction.txt

Refactoring the Program #

Client’s program also needs refactoring.

Refactoring the Server #

Server has several primary functionalities:

  1. Analyze transaction requests from the client side.

  2. Verify transactions including UTXO, ScriptSig and balance
    &nbsp:&nbsp:&nbsp:&nbsp:a. Verify UTXO: verify if the UTXO referenced by the transaction is useable
    &nbsp:&nbsp:&nbsp:&nbsp:b. Verify ScriptSig: verify signature script, decrypt the signature for TXID, and verify if TXID is valid
    &nbsp:&nbsp:&nbsp:&nbsp:c. Verify balance: verify if the amounts in IN is larger or equal to the amount in OUT.

  3. Write in the transaction to transaction.txt

  4. Enquires the remaining UTXO based on the public key ()

图片 1.png

Refactored server program part

Refactoring the Client #

The primary functionalities of the client program include:

  1. Import private key: user can directly import the private key saved by themselves

  2. Create private key: user can directly generate the private key through client’s algorithm

  3. Generate public key through private key

  4. Inquire the balance from the UTXO inquiry service of the server

  5. Create transaction
    &nbsp:&nbsp:&nbsp:&nbsp:a. Generate IN: construct useable UTXO from server’s UTXO inquiry service
    &nbsp:&nbsp:&nbsp:&nbsp:b. Generate OUT to create a new UTXO
    &nbsp:&nbsp:&nbsp:&nbsp:c. Generate TXID: calculate the Hash Value of the transaction data
    &nbsp:&nbsp:&nbsp:&nbsp:d. Generate ScriptSig: encrypt TXID to get signature and the public key

  6. Put the transaction data into the message and send a request to the server

图片 1.png

Refactored program

For reminder, although the client program runs on the browser, the program’s code comes from the server. When the browser visits, it requests the code and stores it on the browser for later use.

Because essentially the server controls the change in code in client, there is no prevention of server-side malicious acts, so this type of design is still not optimized for freedom and fairness.

How to reduce the reliance of client on server is a huge issue. We will leave it for Satoshi to solve later.

After the refactoring of the data part and the program part, Bitcoin now had the UTXO mechanism.

Epilogue #

UTXO had been complete, but Satoshi was still thinking if the transaction model had room for improvement?

Is transaction only a transfer? Can it be abstracted into a function?

Next chapter :Recreating Bitcoin 9:Everything is Transaction


Recreating Bitcoin:A Fictional Story of Why Bitcoin was Designed This Way

Part one : Transactions
Recreating Bitcoin 1:Start over with a Simple Web Transaction System
Recreating Bitcoin 2:First Version is Online!
Recreating Bitcoin 3:Getting Rid of the Account Model
Recreating Bitcoin 4:Digital Signature
Recreating Bitcoin 5:Public Key and Private Key
Recreating Bitcoin 6:Version 0.0.2 is Online!
Recreating Bitcoin 7:UTXO
Recreating Bitcoin 8:System Refactoring Based on UTXO
Recreating Bitcoin 9:Everything is Transaction
Recreating Bitcoin 10:Transaction Script

Part Two : Swarm System
Recreating Bitcoin 11:Swarm System (Part I)
Recreating Bitcoin 12:Swarm System (Part II)
Recreating Bitcoin 13:P2P Network
Recreating Bitcoin 14:Synchronizing Transactions
Recreating Bitcoin 15:Synchronizing Ledger
Recreating Bitcoin 16:Block chain
Recreating Bitcoin 17:Network Flexibility
Recreating Bitcoin 18:Proof of Work (Part I)
Recreating Bitcoin 19:Proof of Work (Part II)
Recreating Bitcoin 20:The Reorganization and Division of

Complete book selling at Amazon( > US > UK > CA > JP > DE > FR > ES > IT) #


BSV Donate:

©2019 - all rights reserved


Now read this

Recreating Bitcoin 9:Everything is Transaction

Epilogue # This chapter will explain the reason to design transaction as a function equivalent. And, what is the essence of a function? Transaction Designed as a Standard Function Equivalent # In the café, softened chatter mixed with... Continue →