<p>Imagine we have a balance based blockchain, a transaction is produced which sends 1 BTC from Alice to Bob, this transaction is mined into a block and confirmed. Another block arrives which contains the same transaction again. This obviously isn't correct, however it's very difficult for us to create a system where this is not possible. </p>

<p>We either must:</p>

<ul>
<li><p>Store a list of all transactions that have happened, refer to it in real time, and exclude any which have already been acted on (the balance deduced, and increased in the ledger). </p></li>
<li><p>Have a nonce for each address which increases every time it makes a transaction, and not allow a transaction with a lower nonce than we currently believe to be the case. </p></li>
</ul>

<p>The latter, while being most sensible and the system used in Ethereum, is suboptimal. For every individual account as a consensus rule we must store all nonces for all eternity up to a maximum set by the consensus system. We can also not have out of order execution of transactions as they become exclusive actions (if 1 and 3 have happened, 2 can now never happen), this removes the possibility of storing pre-signed but un-broadcast transactions as is used in Bitcoin. </p>

<p>Instead, we store just a list of transaction outputs in the UTXO which have never been spent, and strike them from the database when they have been spent. Replay of an already existing transaction can not happen because it will spend an output that does not exist. This is ultimately the most scalable as spent transactions leave no fingerprint on the nodes storage, and allows for validity checks to happen in milliseconds. </p>

<p>Using a UTXO causes transactions to be atomic, and automatically not re-playable. </p>

CC BY-SA 4.0
2018-09-30T03:19:47.730Z
you should copy your answer to the question this post was marked duplicate of. The answer on the past is good, but I think yours is a nice explanation, and it approaches the answer in a different way.
chytrik
CC BY-SA 4.0
2018-09-30T03:20:13.953Z
Look at the time stamps.
Claris
CC BY-SA 4.0
2018-09-30T03:30:34.073Z
Ah sorry, I made a confusing typo on my first comment, it should say *"The answer on that post is good,..."*. I know you answered here before it was marked duplicate, I just meant to say if that other question is the target for duplicates, you should copy your answer to it. I think it is a helpful answer, and it will get more views if you copy it there (since this question is now marked duplicate).
chytrik
CC BY-SA 4.0
2018-09-30T03:57:38.980Z
Underwood, sorry.
Claris
CC BY-SA 4.0
2018-09-29T13:00:53.933Z
2018-09-29T13:00:53.933Z
Claris
<p>I know what it means. But I can't understand why Bitcoin decided to make such a model, where you have no balance, only unspent transaction outputs. And isn't the same thing as having the balance? I assume if you didn't spend coins, you have them in balance. What advantage does it have over a usual (non-UTXO) model? With comparison with other cryptocurrencies which has no UTXO, if possible, please.</p>

<transactions>
Why Bitcoin uses UTXO model?
D-Samp
# Why Bitcoin uses UTXO model?

(Asked by: username_0 on 2018-09-29)

I know what it means. But I can't understand why Bitcoin decided to make such a model, where you have no balance, only unspent transaction outputs. And isn't the same thing as having the balance? I assume if you didn't spend coins, you have them in balance. What advantage does it have over a usual (non-UTXO) model? With comparison with other cryptocurrencies which has no UTXO, if possible, please.

**Tags:** transactions


---

## 1 answers

### Answer by username_1 on 2018-09-29. Score: 2 | Accepted answer

Imagine we have a balance based blockchain, a transaction is produced which sends 1 BTC from Alice to Bob, this transaction is mined into a block and confirmed. Another block arrives which contains the same transaction again. This obviously isn't correct, however it's very difficult for us to create a system where this is not possible.

We either must:

* Store a list of all transactions that have happened, refer to it in real time, and exclude any which have already been acted on (the balance deduced, and increased in the ledger).
* Have a nonce for each address which increases every time it makes a transaction, and not allow a transaction with a lower nonce than we currently believe to be the case.

The latter, while being most sensible and the system used in Ethereum, is suboptimal. For every individual account as a consensus rule we must store all nonces for all eternity up to a maximum set by the consensus system. We can also not have out of order execution of transactions as they become exclusive actions (if 1 and 3 have happened, 2 can now never happen), this removes the possibility of storing pre-signed but un-broadcast transactions as is used in Bitcoin.

Instead, we store just a list of transaction outputs in the UTXO which have never been spent, and strike them from the database when they have been spent. Replay of an already existing transaction can not happen because it will spend an output that does not exist. This is ultimately the most scalable as spent transactions leave no fingerprint on the nodes storage, and allows for validity checks to happen in milliseconds.

Using a UTXO causes transactions to be atomic, and automatically not re-playable.

> **Comments:**
> **username_2**: you should copy your answer to the question this post was marked duplicate of. The answer on the past is good, but I think yours is a nice explanation, and it approaches the answer in a different way.  
> **username_1**: Look at the time stamps.  
> **username_2**: Ah sorry, I made a confusing typo on my first comment, it should say *"The answer on that post is good,..."*. I know you answered here before it was marked duplicate, I just meant to say if that other question is the target for duplicates, you should copy your answer to it. I think it is a helpful answer, and it will get more views if you copy it there (since this question is now marked duplicate).  
> **username_1**: Underwood, sorry.  

---

