Skip to main content

The Unspent Transaction Output Model (UTXO)

In this section, learn how the Unspent Transaction Output (UTXO) model affects how transactions are formatted, how the current state is structured and how smart contracts are written.

Overview​

  • 2.2 UTXO Transaction Structure
  • 2.3 User Defined Code in UTXO Transactions
  • 2.4 Read your First UTXO Transaction
  • 2.5 UTXO State
  • 2.6 Read your First UTXO State

[2.2] UTXO Transaction Structure​

To modify a distributed ledger that is tracking assets via a UTXO data structure, you will need a UTXO formatted transaction. This type of transaction mainly contains an array of transaction outputs (destinations) and an array of transaction inputs (origins).

Note that in this section we use transaction output interchangeably with transaction destination and we use transaction input interchangeably with transaction origin. This is because transaction destination and transaction origin also have meaning in the accounts based model, which forms a part of Overledger’s standardised data model between the accounts and UTXO data structures.

Transaction Output

Each output contains a certain amount of a numeric asset (if the asset is fungible) or a particular unique asset (if the asset is non fungible). Each transaction output has its own spending conditions. For example, a simple spending condition is that a signature needs to be provided which corresponds to a particular DLT account. If a transaction output has not yet been used (spent) by another transaction, we call it an unspent transaction output.

Unspent Transaction Output Owner(s)

The owner of an unspent transaction output is therefore the one or multiple parties who can satisfy the spending conditions. This may be explicit via parameters embedded in the transaction output. But this can also be implicit, hence why the UTXO state is not organised via DLT accounts, as we will describe in section 2.5.

Transaction Input

Each input usually contains a link to a previously unspent transaction output that is now being spent. An input that references a previously unspent transaction output will also contain data to prove that the spending conditions of the referenced output have been satisfied.

There can also exist other transactions not referencing an unspent transaction output. These transactions are creating (minting) new assets. For instance, the first transaction of each Bitcoin block does not reference an unspent transaction output. This is because this transaction, known as a coinbase transaction, is used to distribute the new Bitcoins mined in this block (as well as distribute the collected transaction fees).

UTXO Transaction Example

Bitcoin Transaction Diagram (See here)

The diagram above shows on the left two transactions (transaction 1 and 20) that have already been accepted by the nodes of the DLT network, whereas on the right we have a more recent transaction that we are currently creating. This new transaction has:

  1. Transaction outputs (destinations). The new transaction’s destinations declare to what address these coins will be assigned to. I.e., the new transaction will give Alice’s address 5 coins and Bob’s address 10 coins.
  2. Transaction inputs (origins). The new transaction’s origins firstly reference where the spendable coins have come from. Specifically, 5 coins have come from transaction 1 destination number 1, whereas 10 coins have come from transaction 20 destination 2. Finally, these destinations have spend conditions attached. In this example, the spend conditions are simply that they must be spent by Fred’s address. So, to prove that Fred has authorised the spending of these coins, Fred digitally signs these transaction origins with the private key that corresponds to his address (visualised on the diagram with the signature symbol).

Should Alice or Bob later want to spend these coins they will have to create another transaction that references the above transaction and the relevant destination number, while satisfying the spending conditions.

Collecting Change

Bitcoin Transaction With Change Diagram (See here)

Note that as part of the UTXO model, the assets contained within a transaction output must be entirely spent. Therefore, if Fred wants to pay Alice and Bob less than the total value of his transaction inputs, he needs to send himself back some change, in the form of another transaction output. This is visualised in the diagram above.

Transaction Fees

In permissionless DLT networks, a transaction fee must be paid for the transaction to be accepted. The required fee for a transaction to be added to a block is variable and dependant on the current network congestion. In UTXO transactions, the transaction sender implicitly states the transaction fee. That is, the fee is the difference between the total value of the transaction inputs and the total value of the transaction outputs.

[2.3] User Defined Code in UTXO Transactions​

In a UTXO formatted transaction, each output has an associated spending condition. This spending condition has to be detailed in a format set by the DLT.

There may be default spending conditions provided by the DLT. Whereas other spending conditions can be user defined (via smart contracts), within the limits of the DLT required format.

Developers can either code directly in this DLT specific format or use a higher level language which compiles down to the correct format.

Bitcoin Spending Conditions

Bitcoin has the honour of being the first DLT created that can be used in a permissionless network. It uses a unique stack-based scripting language to detail its spending conditions.

From a computation point of view, the Bitcoin scripting language is deliberately simple. It has the following properties:

  • Stateless: meaning that a script detailing a transaction output’s spending conditions has no accessible historical state and therefore cannot save any state for another script to access later.
  • Loopless: No loops are allowed in the scripts, meaning that it is not a Turing complete programming language.

This computational simplicity allows for predictable execution and wide applicability, due to the fact that the software requirements to process and verify transactions are low. But as the Bitcoin scripting language is fairly low-level, it can be complex from a development perspective.

Still, developers can use the Bitcoin script programming language to develop their own spending conditions. But due to the scripting language’s technical restrictions, developers are significantly limited on the functionality they can provide.

UTXO Smart Contracts using Turing Complete Languages

Corda was the first DLT to introduce smart contracts for the UTXO asset tracking model, where the smart contracts can be written in a Turing complete language. Corda smart contracts can also save state, which can be consumed or modified by future smart contracts.

The Corda DLT can only be used in permissioned DLT networks. Each Corda DLT network is architectured to have a DAG transaction ordering system, where there are different notaries who track different subgraphs of the entire ledger state. In Corda, the problem of processing complicated spending conditions and preventing double spend is effectively moved to the notaries to resolve. This is workable due to Corda’s permissioned nature.

More recently, the Cardano DLT, which also utilises a UTXO model, has upgraded to allow smart contracts written using a Turing complete language known as Plutus. Cardano was designed for permissionless DLT networks using a blockchain transaction ordering system. Cardano handles complicated spending conditions via:

  1. Transaction Fees: The more computation required to process the smart contract code, the higher the transaction fee; and
  2. Block Limit: Each block has a limit on the amount of computation that it can contain. A smart contract cannot use more computation that the block’s limit.

This computation limit restriction does in fact mean that code deployed onto a blockchain can never truly be Turing complete, even if the code was written in a Turing complete language. This is a desirable restriction as otherwise the DLT nodes will easily be open to denial of services attacks.

[2.4] Read your First UTXO Transaction​

Note that the external exercise linked to in this page is a non-essential element of the course. It is provided for your benefit to build your blockchain developer skills. FutureLearn advises you that interacting with the content may require or result in personal data transfer to this external website; FutureLearn recommend that you check external websites privacy policies before use.

Overledger UTXO Transaction Search Example

In our next example, we will use Overledger to read UTXO transactions from the Bitcoin testnet.

Recall that UTXO transactions have 1 or more origins (inputs) and 1 or more destinations (outputs).

For this task, go to the third exercise link on our Github repository in a new tab and follow the step by step instructions.

[2.5] UTXO State​

To track assets correctly, the current state and transitions to possible future states must be defined.

UTXO Current State

The UTXO current state is fundamentally a list of currently unspent transaction outputs. Each unspent transaction output (UTXO) is uniquely referenced by a combination of:

  • A transaction identifier: specifically, the transaction id of the transaction that created this output. Note that this transaction id is usually equal to the transaction hash.
  • Transaction output array index: specifically, the transaction output array index pointing to this output, inside the transaction that created it.

Some examples are:

  • f18f7b9aaaa568040b742f3e39c746a33b6380ff114f259bd58f85fd7b5836c7:0
  • f18f7b9aaaa568040b742f3e39c746a33b6380ff114f259bd58f85fd7b5836c7:1

Referencing output 0 and output 1 of transaction f18f7b9aaaa568040b742f3e39c746a33b6380ff114f259bd58f85fd7b5836c7 respectively.

You will see further examples of these UTXO ids in the developer task of section 2.6.

UTXO State Transition

The UTXO state transaction function is fairly simple. For each newly accepted transaction by the DLT node:

  1. Remove from the current state each unspent transaction output referenced in each of the new transaction’s inputs.
  2. Add to the current state each of the new transaction’s outputs.

Double Spend Prevention

Double spends are prevented as the first transaction to spend a UTXO removes it from the state.

Note that temporary double spends can occur if there is a dispute on transaction ordering between DLT nodes. These disputes are resolved via the consensus protocol.

[2.6] Read your First UTXO State​

Note that the external exercise linked to in this page is a non-essential element of the course. It is provided for your benefit to build your blockchain developer skills. FutureLearn advises you that interacting with the content may require or result in personal data transfer to this external website; FutureLearn recommend that you check external websites privacy policies before use.

Overledger UTXO State Search Example

In our next example, we will use Overledger to read UTXO state from the Bitcoin testnet.

Recall that the UTXO state is made up of a list of unspent transaction outputs.

For this task, go to the fourth exercise link on our Github repository in a new tab and follow the step by step instructions.