user3667: 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... 

user52021: 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.

user46748: 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.


user10621: Exactly the same question was asked to a Bitcoin developer (Peter Todd) during the Bitcoin 2013 Conference.
You can watch his answer here
For those who are too lazy to watch the video the short answer is that they are doing it for security reasons.

user5757: 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?).  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.

3667: <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>
 52021: <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>
 46748: <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="nofollow 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>
 10621: <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>
 5757: <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>
