Blockchain Note – BTC UTXO

In this chapter, we will briefly introduce the UTXO (Unspent transaction output).

UTXO Basics

As an account-based ledger, the problem with this type of accounting is that the balance of each account must be queried to determine if a transaction is valid. For example, in the last transaction, you have to check Alice’s account, and how many coins remain in total. In the example above, if there is no global data structure to maintain the user’s balance, then you may have to trace back to the starting transaction to see how much Alice has left. If you want to hurry, you have to maintain additional data structures, such as a global data structure, to update the account balance after each transaction.


Figure 1. Block transaction

Specifically, it is the content of the transaction Tx2 except for the signature part (the transaction content of the signature can be simplified by the flag bit, in this case, pub-key Script is used instead of Signature to fill). The above picture has three parts, the middle is Signed Data, which is the signed data. The upper part is Tx1 and Bob’s own data, and the lower part is Bob’s final Tx2. A lower portion is formed from the upper portion and the intermediate portion. (Another benefit of the signature is that the plaintext portion of Tx2 cannot be arbitrarily tampered with by the attacker)


These 1.5 bitcoins are not the balance, but the unspent transaction output (UTXO) in your address.
The reason why the account has no balance is not because there is no currency, but because the bitcoin system does not have an “account”, only
There is the concept of “address”. “Account” corresponds to “balance”; “Address” only corresponds to UTXO.

What is the difference between UTXO and the balance:
If the balance sheet is updated every time, there must be information redundancy: if you did not buy anything on the Black Friday, your balance will be updated 1.48 billion times with the people of the country.
After any transaction occurs, the balance of the owner will be updated even if it has not changed. Why?
Because you want to avoid double payments.

Someone gave me 1 bitcoin, I am very happy, but I changed my mind: I should confirm whether the money has been paid by someone else.
Others, otherwise I will be like a bad check.
So, I opened the balance sheet and found that others actually have the money. I am more happy, and I am excited to send it to others.
Then the bad news came: I was double spent, and the bitcoin I received was simply useless because it was already paid it to someone else, and the balance sheet I checked was not updated at the time.

The peer-to-peer system does not have an authoritative ledger of the center. Consensus needs to be confirmed by most nodes if the information is transmitted.
If there is a time difference, you cannot confirm all account balances at the same time, so you must face double spent.

If Bitcoin is designed to be like this, it must be the first to die, and UTXO will not balance the balance plan.

Two big problems to be solved: database fat and double payment problems.
UTXO’s solution is simple to the extreme: only confirm the transaction itself.

The database generated using UTXO is much smaller than the database using the balance system. Bitcoin has been running for more than eight years, and the transaction record is only a few hundred G, and a normal home computer can be installed.

As for the account balance, you scan all the in and out of the same address from top to bottom, and wait for it. You only

To wait for the confirmation time of the 6 blocks, you can ensure that you are not double spent, because the transaction is distributed across the network.

Use case:
On December 1st, your father gave you 1 coin;
On December 2, your mother gave you 2 coins;
On December 3, your client will give you 5 coins;
There are now 8 coins on your address.
If you want to buy 4 yuan for a cake, then you will see the transaction record like this:
Subtract 5 coins from your address.

However, if you spend 4 coins, why do you deduct 5?
Because Bitcoin has no balance, only UTXO.

You have three unpaid transaction outputs (UTXO), 1, 2 and 5, respectively. These three UTXOs are like three coins.
The same, there is no way to open the flowers, you can only pay for it, but the system will give you a change.
So don’t worry, it seems that you have paid more, but 4 of them are for the pie, and the other 1 will return to your address. And all of this is done automatically by the system.

ETH (Ethereum)

Distribution, security and efficiency can not be combined, only up to two.

Ethereum has a complicated appearance, but when you open the lid and look inside, there are only three parts: accounts, transactions and blocks.

The account is a passbook, remembering your balance;
The transaction is the remittance slip, you are responsible for filling out the signature and losing the password;
The block is the bank, and the teller enters the transaction into the system, which is equivalent to the miner cutting the transaction into the block and changing the account information.

In the UTXO model, each input is the unspent output of the previous transaction, interlocking, and there will be no duplicate transactions.
The account model is different. Each account change is like applying a layer of correction fluid. Only the latest results can be seen. Once the account is repeated,

Will it be wrong again and again, how to prevent this hidden danger?
Ethereum’s approach is to add a label to the account, the number of the label after the transaction is +1, check whether the label has a heavy number before each transaction, and cancel the transaction once the number is repeated.

The name of this tag is nonce, which looks the same as the random number found in the Bitcoin workload proof, but the nonce in the Ethereum means “serial number”, and with it you can pay with peace of mind.

However, the most important thing in the account is not only the serial number, but the balance. The essence of the transaction is to change the balance of both parties. Once the miner has dug up the transaction information, it will be credited to the block to rewrite the account information.

ETH is an external account, which has the same function as a Bitcoin address, and uses a private key to trigger the balance.
The other is a contract account. Each time a message is received, the contract code in the account will run intelligently. This is the origin of the Ethereum “smart contract”.

Ethereum’s most famous contract account is ERC20, ERC refers to Ethereum Request for Comment, and 20 is the account number. ERC20 is the contract to issue Token, and the Token is only required to call the contract. In this mode, the serial number, balance, contract code, and storage information are called status.

In terms of efficiency, the account model wins UTXO. For example, when we calculate the balance of an address, the account mode will output the result in seconds. The UTXO model will traverse all the blocks in the network and add the total balance, but UTXO does not care about slowness. Because it insists that the data written cannot be changed.

In terms of security, the UTXO model is recognized as a leader, so many people think that the combination of UTXO and private key can protect wealth, because the private key represents the ownership of wealth, and UTXO can ensure the security of the account system.

The difficulty of custody is still second. The most important thing is that once the private key is lost or leaked, the user will lose all wealth, and the stability of UTXO will be meaningless.

EOS does not bind a person’s identity to a bare private key, but instead is labeled in an account that corresponds to a password. The biggest advantage is that the wealth of ordinary users is greatly protected. Once the password is leaked and the property is lost, the average user can choose one more option: cancel the transaction within the preset time.

For example, you can preset a transfer of more than 10,000 coins and it takes 1 hour to confirm, so once someone steals your wealth through a password, you will be notified that within 1 hour, you can cancel through the default social relationship. transaction.

Impossible triangle: distributed, safe and efficient
Since all are distributed, they can only be weighed between security and efficiency. Bitcoin is going to be an electronic cash system, which is safe and sound, so it is on the left with UTXO. Ethereum and EOS both want to be smart contract platforms, and pursue efficient and flexible, so choose the account model on the right.

UTXO account detail

  1. UTXO
A transaction input must always refer to an unspent transaction output (uTxO). Consequently, when you own some coins in the blockchain, what you actually have is a list of unspent transaction outputs whose public key matches to the private key you own.
In terms of transactions validation, we can only focus on the list of unspent transactions outputs, in order to figure out if the transaction is valid. The list of unspent transaction outputs can always be derived from the current blockchain. In this implementation, we will update the list of unspent transaction outputs as we process and include the transactions to the blockchain.
The data structure for an unspent transaction output looks like this:
classUnspentTxOut {
   public readonly txOutId:string;
   public readonly txOutIndex:number;
   public readonly address:string;
   public readonly amount:number;

   constructor(txOutId:string, txOutIndex:number, address:string, amount:number) {
The data structure itself if just a list:
letunspentTxOuts: UnspentTxOut[]=[];
  1. Get the balance of the account
A reminder from the previous chapter: when you own some coins in the blockchain, what you actually have is a list of unspent transaction outputs whose public key matches to the private key you own.
This means that calculating the balance for a given address is quite simple: you just sum all the unspent transaction “owned” by that address:
const getBalance = (address:string, unspentTxOuts:UnspentTxOut[]):number=> {
   return _(unspentTxOuts)
       .filter((uTxO:UnspentTxOut) => uTxO.address === address)
       .map((uTxO:UnspentTxOut) => uTxO.amount)

Generating transactions

When sending coins, the user should be able to ignore the concepts of transaction inputs and outputs. But what should happen if the user A has balance of 50 coins, that is in a single transaction output and the user wants to send 10 coins to user B?
In this case, the solution is to send 10 bitcoins to the address of user B and 40 coins back to user A. The full transaction output must always be spent, so the “splitting” part must be done when assigning the coins to new outputs. This simple case is demonstrated in the following out picture (txIns are not shown):
Let’s play out a bit more complex transaction scenario:
  1. User C has initially 0 coins
  2. User C receives 3 transactions worth of 10, 20 and 30 coins
  3. User C wants to send 55 coins to user D. What will the transaction look like?
In this case, all of the three outputs must be used and the outputs must have values of 55 coins to user D and 5 coins backto user C.
Let’s manifest the described logic to code. First we will create the transaction inputs. To do this, we will loop through our unspent transaction outputs until the sum of these outputs is greater or equal than the amount we want to send.
constfindTxOutsForAmount=(amount:number, myUnspentTxOuts:UnspentTxOut[])=>{
   let currentAmount=0;
   const includedUnspentTxOuts=[];

   for(const myUnspentTxOut of myUnspentTxOuts) {
       if(currentAmount>=amount) {
           return{includedUnspentTxOuts, leftOverAmount}

   throwError('not enough coins to send transaction');
As shown, we will also calculate theleftOverAmountwhich is the value we will sendbackto our address.
As we have the list of unspent transaction outputs, we can create the txIns of the transaction:
const toUnsignedTxIn=(unspentTxOut:UnspentTxOut)=>{
   const txIn:TxIn=newTxIn();
const {includedUnspentTxOuts, leftOverAmount}=findTxOutsForAmount(amount, myUnspentTxouts);

const unsignedTxIns:TxIn[];
Next the two txOuts of the transaction are created: One txOut for the receiver of the coins and one txOut for the leftOverAmount`. If the txIns happen to have the exact amount of the desired value (leftOverAmount is 0) we do not create the “leftOver” transaction.
const createTxOuts=(receiverAddress:string, myAddress:string, amount, leftOverAmount:number)=>{
   const txOut1:TxOut=newTxOut(receiverAddress, amount);

   if(leftOverAmount===0) {
       const leftOverTx=newTxOut(myAddress, leftOverAmount);
       return [txOut1, leftOverTx];
Finally we calculate the transaction id and sign the txIns:
   const tx:Transaction=newTransaction();
   tx.txOuts=createTxOuts(receiverAddress, myAddress, amount, leftOverAmount);;, index:number)=>{
       txIn.signature=signTxIn(tx, index, privateKey, unspentTxOuts);
       return txIn;


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s