<p>Exactly the same question was asked to a Bitcoin developer (Peter Todd) during the Bitcoin 2013 Conference.</p>

<p>You can watch his answer <a href="https://youtu.be/yyrOgSN7i-U?t=19m26s" rel="nofollow noreferrer">here</a></p>

<p>For those who are too lazy to watch the video the short answer is that they are doing it for security reasons.</p>

CC BY-SA 3.0
2014-07-30T22:38:48.027Z
Video can't be skimmed for important bits like text can. So not wanting to watch video isn't laziness; it's disliking the delivery medium.
Almo
CC BY-SA 3.0
2014-07-30T22:54:22.030Z
a bit of humor never hurts ;)
Jan Moritz
CC BY-SA 3.0
2014-07-30T23:12:01.930Z
Humor?!? What's that! :)
Almo
CC BY-SA 3.0
2014-07-30T17:03:39.217Z
2018-03-09T09:02:22.583Z
2018-03-09T09:02:22.583Z
Jan Moritz
<p>A nice article from corda developer, which explain why corda give up simple “account/balance” ledger and use UTXO-like ledger.<br>
<a href="https://www.corda.net/2016/12/09/rationale-tradeoffs-adopting-utxo-style-model/" rel="noreferrer">https://www.corda.net/2016/12/09/rationale-tradeoffs-adopting-utxo-style-model/</a> </p>

<p>The UTXO model has these advantages:</p>

<ul>
<li>Immutable ledger entries gives the usual advantages that a more functional approach brings: it’s easy to do analysis on a static snapshot of the data and reason about the contents, even as it’s changing.</li>
<li>Because there are no accounts it’s very easy to apply transactions in parallel, even for high traffic legal entities, assuming sufficiently granular entries.</li>
<li>Transaction ordering becomes trivial: it is impossible to mis-order transactions due to the reliance on hash functions to identify previous states. There is no need for sequence numbers or other things that are hard to provide in a fully distributed system.</li>
<li>Conflict resolution boils down to the double spending problem, which places extremely minimal demands on consensus algorithms (as the variable you’re trying to reach consensus on is a set of booleans).</li>
<li>Smart contracts are simply boolean functions and do not directly mutate state themselves. There are thus no problems with state corruption due to things like unexpected re-entrancy, as was the case in The DAO attack witnessed by Ethereum earlier in the year.</li>
</ul>

CC BY-SA 3.0
2017-03-01T09:58:03.400Z
2017-03-01T09:58:03.400Z
Shawn Guo
<p>In short, the naive "account" approach is totally insecure. Fixing the insecurity without using a TXO model it seems people end up creating something which is more complex, less parallizable, and less flexible than the txout model.</p>

<p>For example, how do you prevent someone from just resending a transaction to duplicate a payment?  The naive fix of checking each new transaction against every tx in history has horrible performance and scalablity and isn't a realistic option.  Using a sequence number kills concurrency (e.g. if you make two transactions and someone hears the later one first, it needs to block the first; as well as concurrency in validation) and has the overhead of tracking sequence numbers.</p>

<p>Moreover, systems like Bitcoin were designed to use single use addresses for both privacy and efficient metadata-linking, like how do you know which invoice was paid?-- by seeing which of your addresses was paid.  If you don't reuse addresses any potential benefit of the account model goes away and all you get are the costs.</p>

CC BY-SA 4.0
2018-07-26T06:22:54.473Z
you ask: "For example, how do you prevent someone from just resending a transaction to duplicate a payment?", and go on to propose a sequence counter mechanism. Let's say that the counters of both the sender and the receiver are included in the digitally signed transaction packet broadcast to the network. Can you please elaborate on the concurrency concern? Surely each node can have some amount of memory where it can hold some transaction packets for some amount of time until the previous transaction packets arrive. This does not look too difficult to design and implement? If you
Sohrab Saran
CC BY-SA 4.0
2018-07-26T15:22:17.503Z
A counter prevents replay but if the system also tracks only the most recent counter it also kills concurrency: You can't transact again until your prior transaction is confirmed or otherwise it looks like a rollback.  Using a counter also means forever tracking a counter for each account, including accounts that are now empty. This makes the size of the working set unbounded even if spends of 0 are not allowed.
G. Maxwell
CC BY-SA 4.0
2018-07-27T18:26:59.053Z
If we have one counter per account and average of 5 transactions per account per day, then the concurrency concern is about delay or loss of previous transaction happening for some of several thousands of nodes. How in bitcoin/blockchain are the blocks created and propagated among several thousands of nodes? Surely the same problems and solutions apply? And why to track (check) counters of any accounts other than the ones associated with the transacction packets? Counter storage is less of an issue than storing all transactions.
Sohrab Saran
CC BY-SA 4.0
2018-07-29T00:05:05.283Z
sohansaran Concurrency in this case means that a new transaction can't be created until a prior one is irreversible without risk of blocking the prior one, for example in a reorg.
G. Maxwell
CC BY-SA 4.0
2018-07-25T19:13:36.487Z
2018-07-25T19:13:36.487Z
G. Maxwell
<p>In order to be sure that an address balance is correct, you need to check that all the transactions on that address are valid.  So in order to generate a list of addresses and balances that you trust, you must first download and verify the entire block chain.</p>

<p>Actually, the way Bitcoin works, what you actually need is a list of <em>unspent transaction outputs</em> (UTXOs).  When you create a new transaction to spend coins, you don't just debit an address; you have to reference one or more specific outputs from previous transactions that you are spending.  Those previous outputs then become unusable, so that you can't spend them again.</p>

<p>Bitcoin Core does actually generate an indexed database of all UTXOs, and refers to it when checking transactions for validity (since this is much faster than searching back through the block chain directly).  This is the closest analogy to the "ledger" you proposed.  </p>

<p>Once you've done this, you could delete the block chain itself and just keep the UTXO database; that is basically what the <code>-prune</code> option does (see <a href="https://bitcoin.stackexchange.com/questions/37496/how-can-i-run-bitcoind-in-pruning-mode">How can I run bitcoind in pruning mode?</a>).  However, remember that Bitcoin is a peer-to-peer system.  So you keep the block chain so that new users can download it from you.</p>

CC BY-SA 3.0
2014-07-30T17:25:12.370Z
Ah that's what I was overlooking: clients that haven't been running since the genesis block need proof that each account balance is accurate
pinhead
CC BY-SA 4.0
2018-07-25T12:58:42.017Z
The selected answer says 'In order to be sure that an address balance is correct, you need to check that all the transactions on that address are valid.'
But why? Why can't the address balance simply be decided by what the majority of the distributed ledgers show?
Sohrab Saran
CC BY-SA 4.0
2018-07-25T14:26:14.440Z
@sohrabsaran The ledger (blockchain) doesn't show address balances. Additionally, there is only one blockchain. There is no majority nor is anything done by majority or "vote".
Ava Chow
CC BY-SA 4.0
2019-02-28T16:21:59.317Z
This answer explains *how* bitcoin implemented an input/output system but not *why* it did so.
David Schwartz
CC BY-SA 3.0
2014-07-30T17:23:17.663Z
2017-09-05T14:11:53.403Z
2017-09-05T14:11:53.403Z
Nate Eldredge
<p>From what I can tell, the Ethereum blockchain just stores accounts and balances - why did the original Bitcoin developers choose the method of storing all transactions for validation instead of just account balances? It seems like that would reduce blockchain size on disk quite a bit... </p>

CC BY-SA 3.0
2014-07-30T16:31:06.923Z
possible duplicate of [Can Bitcoin-Qt be configured to trim the blockchain?](http://bitcoin.stackexchange.com/questions/20000/can-bitcoin-qt-be-configured-to-trim-the-blockchain)
Nate Eldredge
CC BY-SA 3.0
2014-07-30T17:16:08.030Z
@NateEldredge I'm not asking about blockchain trimming, I'm asking about the original decision to implement this type of database altogether
pinhead
CC BY-SA 4.0
2019-03-28T16:56:20.803Z
This is an excellent question and something I have been wondering myself. Banks don't store the serial numbers of the notes when they transfer money from one account to another - in fact no notes are transferred. So why does Bitcoin store data to this level of detail? It really seems unnecessary and a perf hit to maintain the database of UTXOs
morpheus
<blockchain><utxo>
Why does Bitcoin store all transaction inputs and outputs, instead of just an "account/balance" ledger?
pinhead
# Why does Bitcoin store all transaction inputs and outputs, instead of just an "account/balance" ledger?

(Asked by: username_0 on 2014-07-30)

From what I can tell, the Ethereum blockchain just stores accounts and balances - why did the original Bitcoin developers choose the method of storing all transactions for validation instead of just account balances? It seems like that would reduce blockchain size on disk quite a bit...

**Tags:** blockchain, utxo

> **Comments:**
> **username_1**: possible duplicate of [Can Bitcoin-Qt be configured to trim the blockchain?](http://bitcoin.stackexchange.com/questions/20000/can-bitcoin-qt-be-configured-to-trim-the-blockchain)  
> **username_0**: @username_1 I'm not asking about blockchain trimming, I'm asking about the original decision to implement this type of database altogether  
> **username_2**: This is an excellent question and something I have been wondering myself. Banks don't store the serial numbers of the notes when they transfer money from one account to another - in fact no notes are transferred. So why does Bitcoin store data to this level of detail? It really seems unnecessary and a perf hit to maintain the database of UTXOs  

---

## 4 answers

### Answer by username_1 on 2014-07-30. Score: 15 | Accepted answer

In order to be sure that an address balance is correct, you need to check that all the transactions on that address are valid. So in order to generate a list of addresses and balances that you trust, you must first download and verify the entire block chain.

Actually, the way Bitcoin works, what you actually need is a list of *unspent transaction outputs* (UTXOs). When you create a new transaction to spend coins, you don't just debit an address; you have to reference one or more specific outputs from previous transactions that you are spending. Those previous outputs then become unusable, so that you can't spend them again.

Bitcoin Core does actually generate an indexed database of all UTXOs, and refers to it when checking transactions for validity (since this is much faster than searching back through the block chain directly). This is the closest analogy to the "ledger" you proposed.

Once you've done this, you could delete the block chain itself and just keep the UTXO database; that is basically what the `-prune` option does (see [How can I run bitcoind in pruning mode?](https://bitcoin.stackexchange.com/questions/37496/how-can-i-run-bitcoind-in-pruning-mode)). However, remember that Bitcoin is a peer-to-peer system. So you keep the block chain so that new users can download it from you.

> **Comments:**
> **username_0**: Ah that's what I was overlooking: clients that haven't been running since the genesis block need proof that each account balance is accurate  
> **username_7**: The selected answer says 'In order to be sure that an address balance is correct, you need to check that all the transactions on that address are valid.' But why? Why can't the address balance simply be decided by what the majority of the distributed ledgers show?  
> **username_8**: @username_7 The ledger (blockchain) doesn't show address balances. Additionally, there is only one blockchain. There is no majority nor is anything done by majority or "vote".  
> **username_9**: This answer explains *how* bitcoin implemented an input/output system but not *why* it did so.  

---

### Answer by username_3 on 2014-07-30. Score: 6

Exactly the same question was asked to a Bitcoin developer (Peter Todd) during the Bitcoin 2013 Conference.

You can watch his answer [here](https://youtu.be/yyrOgSN7i-U?t=19m26s)

For those who are too lazy to watch the video the short answer is that they are doing it for security reasons.

> **Comments:**
> **username_4**: Video can't be skimmed for important bits like text can. So not wanting to watch video isn't laziness; it's disliking the delivery medium.  
> **username_3**: a bit of humor never hurts ;)  
> **username_4**: Humor?!? What's that! :)  

---

### Answer by username_5 on 2017-03-01. Score: 5

A nice article from corda developer, which explain why corda give up simple “account/balance” ledger and use UTXO-like ledger.  
<https://www.corda.net/2016/12/09/rationale-tradeoffs-adopting-utxo-style-model/>

The UTXO model has these advantages:

* Immutable ledger entries gives the usual advantages that a more functional approach brings: it’s easy to do analysis on a static snapshot of the data and reason about the contents, even as it’s changing.
* Because there are no accounts it’s very easy to apply transactions in parallel, even for high traffic legal entities, assuming sufficiently granular entries.
* Transaction ordering becomes trivial: it is impossible to mis-order transactions due to the reliance on hash functions to identify previous states. There is no need for sequence numbers or other things that are hard to provide in a fully distributed system.
* Conflict resolution boils down to the double spending problem, which places extremely minimal demands on consensus algorithms (as the variable you’re trying to reach consensus on is a set of booleans).
* Smart contracts are simply boolean functions and do not directly mutate state themselves. There are thus no problems with state corruption due to things like unexpected re-entrancy, as was the case in The DAO attack witnessed by Ethereum earlier in the year.


---

### Answer by username_6 on 2018-07-25. Score: 1

In short, the naive "account" approach is totally insecure. Fixing the insecurity without using a TXO model it seems people end up creating something which is more complex, less parallizable, and less flexible than the txout model.

For example, how do you prevent someone from just resending a transaction to duplicate a payment? The naive fix of checking each new transaction against every tx in history has horrible performance and scalablity and isn't a realistic option. Using a sequence number kills concurrency (e.g. if you make two transactions and someone hears the later one first, it needs to block the first; as well as concurrency in validation) and has the overhead of tracking sequence numbers.

Moreover, systems like Bitcoin were designed to use single use addresses for both privacy and efficient metadata-linking, like how do you know which invoice was paid?-- by seeing which of your addresses was paid. If you don't reuse addresses any potential benefit of the account model goes away and all you get are the costs.

> **Comments:**
> **username_7**: you ask: "For example, how do you prevent someone from just resending a transaction to duplicate a payment?", and go on to propose a sequence counter mechanism. Let's say that the counters of both the sender and the receiver are included in the digitally signed transaction packet broadcast to the network. Can you please elaborate on the concurrency concern? Surely each node can have some amount of memory where it can hold some transaction packets for some amount of time until the previous transaction packets arrive. This does not look too difficult to design and implement? If you  
> **username_6**: A counter prevents replay but if the system also tracks only the most recent counter it also kills concurrency: You can't transact again until your prior transaction is confirmed or otherwise it looks like a rollback.  Using a counter also means forever tracking a counter for each account, including accounts that are now empty. This makes the size of the working set unbounded even if spends of 0 are not allowed.  
> **username_7**: If we have one counter per account and average of 5 transactions per account per day, then the concurrency concern is about delay or loss of previous transaction happening for some of several thousands of nodes. How in bitcoin/blockchain are the blocks created and propagated among several thousands of nodes? Surely the same problems and solutions apply? And why to track (check) counters of any accounts other than the ones associated with the transacction packets? Counter storage is less of an issue than storing all transactions.  
> **username_6**: sohansaran Concurrency in this case means that a new transaction can't be created until a prior one is irreversible without risk of blocking the prior one, for example in a reorg.  

---

