<p>In UTXO model, each transaction spends output from previous transactions and creates new output that can be spent by transactions later on operated by full nodes. Your wallet maintains a list of UTXOs associated with all addresses owned by the user, and the balance of the wallet is calculated as the sum of these unspent transactions. Take a look at this example : </p>

<p>A has 2.5 btc i.e. one UTXO of 2.5 btc. A wish to send B 1.0 btc. A uses 2.5 btc as input to the trxn and sends 1.0 bitcoin to B, 1.5 btc sent back to A as a new UTXO with new address. So If  B has 1 btc then total is 2 btc (sent by A) and having two UTXOs: one already of 1 btc and other one is of 1 btc by A.</p>

<p>Bitcoin blockchain uses this model, there is another model which is being used by Ethereum blockchain i.e. Account Model which is quite simpler than the previous model. Lets see the example :</p>

<p>A has 2 ethers, A wish to send B 1 ether, so the network will reduce 1 ether from A i.e. A has 1 ether now and network adds 1 ether to B. If B has 2 ethers already then total is 3 ethers.</p>

<p>Both models has different pros and cons.</p>

<p>Every transaction in account model make one output which leads to space savings. Any space savings is a benefit. As the network full nodes are meant to be operated by individuals rather then data centers the lower the data requirements the more potential participants.</p>

<p>But UTXO provides a higher level of privacy as the users use new addresses for each transaction and will be difficult to link accounts to each other.</p>

CC BY-SA 4.0
2019-06-30T13:56:02.207Z
2019-06-30T13:56:02.207Z
Rajesh Prajapati
<p>The choice between the UTXO model and the balance model is primarily one between privacy incentives and apparent intuitiveness.</p>

<p>If one follows the standard advice of not reusing addresses/outputs/scripts, as to not gratuitously reveal which coins belong to the sender and which belong to the receiver, the two models are actually equivalent. In this case balances would be single use anyway, and there would be as many balances as there would otherwise be UTXOs, removing both the apparent size advantage and convenience.</p>

<p>However, the balance model effectively incentivizes reuse. As the cost to the system (possibly in fees, but certainly in node operation costs) for a balance update is lower than the creation of a new balance, such a system inherently incentives revelation of transaction sources.</p>

<p>And even though balances are more intuitive, they do complicate reasoning about the security of the system. One issue is the problem of replay attacks. Assume X paid Y, and Y pays Z. Now W pays Y again. In a naive implementation, Z can rebroadcast his earlier transaction from Y, and could take the money from W's payment to Y. One solution is by putting sequence numbers on balances, and requiring transactions to list the sequence number of the transactions they take money of. Unfortunately, this requires maintaining the sequence number even for balances that went to zero, meaning that the balance database needs to maintain some data for every balance that was ever nonzero; a result that's far less scalable than the UTXO model was in the first place (which can forget outputs as soon as they're spent).</p>

<p>In short, my view is that the balance model reduces the fungibility of the currency as a whole for a short term gain that disappears.</p>

CC BY-SA 3.0
2018-04-30T20:20:42.420Z
The balance database doesn't need to maintain the sequence number for balances that went to zero. Among other solutions, you can assign an account a pseudo-random sequence number when it's created that has to go in each transaction. There are other solutions to this problem too.
David Schwartz
CC BY-SA 3.0
2018-04-30T20:52:29.520Z
That's fair; I was only explaining how the account model introduces additional complications - several solutions are possible to it. The primary issue in my view is how accounts inherently encourage revealing linkage of transactions, which IMHO is a no-go for any currency that aims for fungibility.
Pieter Wuille
CC BY-SA 4.0
2018-05-26T23:39:58.140Z
@DavidSchwartz could you please explain a little more details of how "assign an account a pseudo-random sequence number" would prevent replay attacks?
Helin Wang
CC BY-SA 4.0
2018-05-27T08:25:23.980Z
If the account is re-created, it will have a new sequence number. This will make every previous transaction invalid for that account since the sequence number won't match.
David Schwartz
CC BY-SA 4.0
2018-06-13T18:00:35.253Z
This is a highly biased answer. Not that it's bad, but I'd encourage people to also read the reason Ethereum went with their model: https://github.com/ethereum/wiki/wiki/Design-Rationale#accounts-and-not-utxos They also say UTXOs support more scaling paradigms, but I've yet to find any more info on that.
sudo
CC BY-SA 3.0
2016-11-25T18:53:54.437Z
2017-08-14T18:10:53.167Z
2017-08-14T18:10:53.167Z
Pieter Wuille
<p>I understand that Bitcoin uses unspent tx output and Ethereum account balance based. However, recently there are lots of discussions on that Bitcoin's UTXO database has become too big. Does this mean account balance based transactions are better in scaling than UTXO based?</p>

CC BY-SA 3.0
2016-11-25T08:49:21.173Z
I dont know so much about how Ethereums account balance works. But the set of UTXO in Bitcoin may be optimized, e.g. as Peter Todd describes here: https://petertodd.org/2016/delayed-txo-commitments
Bjarne Magnussen
<transactions><utxo><ethereum>
UTXO model vs. account/balance model
Yangrui
# UTXO model vs. account/balance model

(Asked by: username_0 on 2016-11-25)

I understand that Bitcoin uses unspent tx output and Ethereum account balance based. However, recently there are lots of discussions on that Bitcoin's UTXO database has become too big. Does this mean account balance based transactions are better in scaling than UTXO based?

**Tags:** transactions, utxo, ethereum

> **Comments:**
> **username_1**: I dont know so much about how Ethereums account balance works. But the set of UTXO in Bitcoin may be optimized, e.g. as Peter Todd describes here: https://petertodd.org/2016/delayed-txo-commitments  

---

## 2 answers

### Answer by username_3 on 2016-11-25. Score: 23 | Accepted answer

The choice between the UTXO model and the balance model is primarily one between privacy incentives and apparent intuitiveness.

If one follows the standard advice of not reusing addresses/outputs/scripts, as to not gratuitously reveal which coins belong to the sender and which belong to the receiver, the two models are actually equivalent. In this case balances would be single use anyway, and there would be as many balances as there would otherwise be UTXOs, removing both the apparent size advantage and convenience.

However, the balance model effectively incentivizes reuse. As the cost to the system (possibly in fees, but certainly in node operation costs) for a balance update is lower than the creation of a new balance, such a system inherently incentives revelation of transaction sources.

And even though balances are more intuitive, they do complicate reasoning about the security of the system. One issue is the problem of replay attacks. Assume X paid Y, and Y pays Z. Now W pays Y again. In a naive implementation, Z can rebroadcast his earlier transaction from Y, and could take the money from W's payment to Y. One solution is by putting sequence numbers on balances, and requiring transactions to list the sequence number of the transactions they take money of. Unfortunately, this requires maintaining the sequence number even for balances that went to zero, meaning that the balance database needs to maintain some data for every balance that was ever nonzero; a result that's far less scalable than the UTXO model was in the first place (which can forget outputs as soon as they're spent).

In short, my view is that the balance model reduces the fungibility of the currency as a whole for a short term gain that disappears.

> **Comments:**
> **username_4**: The balance database doesn't need to maintain the sequence number for balances that went to zero. Among other solutions, you can assign an account a pseudo-random sequence number when it's created that has to go in each transaction. There are other solutions to this problem too.  
> **username_3**: That's fair; I was only explaining how the account model introduces additional complications - several solutions are possible to it. The primary issue in my view is how accounts inherently encourage revealing linkage of transactions, which IMHO is a no-go for any currency that aims for fungibility.  
> **username_5**: @username_4 could you please explain a little more details of how "assign an account a pseudo-random sequence number" would prevent replay attacks?  
> **username_4**: If the account is re-created, it will have a new sequence number. This will make every previous transaction invalid for that account since the sequence number won't match.  
> **username_6**: This is a highly biased answer. Not that it's bad, but I'd encourage people to also read the reason Ethereum went with their model: https://github.com/ethereum/wiki/wiki/Design-Rationale#accounts-and-not-utxos They also say UTXOs support more scaling paradigms, but I've yet to find any more info on that.  

---

### Answer by username_2 on 2019-06-30. Score: 1

In UTXO model, each transaction spends output from previous transactions and creates new output that can be spent by transactions later on operated by full nodes. Your wallet maintains a list of UTXOs associated with all addresses owned by the user, and the balance of the wallet is calculated as the sum of these unspent transactions. Take a look at this example :

A has 2.5 btc i.e. one UTXO of 2.5 btc. A wish to send B 1.0 btc. A uses 2.5 btc as input to the trxn and sends 1.0 bitcoin to B, 1.5 btc sent back to A as a new UTXO with new address. So If B has 1 btc then total is 2 btc (sent by A) and having two UTXOs: one already of 1 btc and other one is of 1 btc by A.

Bitcoin blockchain uses this model, there is another model which is being used by Ethereum blockchain i.e. Account Model which is quite simpler than the previous model. Lets see the example :

A has 2 ethers, A wish to send B 1 ether, so the network will reduce 1 ether from A i.e. A has 1 ether now and network adds 1 ether to B. If B has 2 ethers already then total is 3 ethers.

Both models has different pros and cons.

Every transaction in account model make one output which leads to space savings. Any space savings is a benefit. As the network full nodes are meant to be operated by individuals rather then data centers the lower the data requirements the more potential participants.

But UTXO provides a higher level of privacy as the users use new addresses for each transaction and will be difficult to link accounts to each other.


---

