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

  • 1
    possible duplicate of Can Bitcoin-Qt be configured to trim the blockchain? – Nate Eldredge Jul 30 '14 at 16:31
  • @NateEldredge I'm not asking about blockchain trimming, I'm asking about the original decision to implement this type of database altogether – pinhead Jul 30 '14 at 17:16
  • 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 Mar 28 at 16:56

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.

  • 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 Jul 30 '14 at 17:25
  • 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? – sohrabsaran Jul 25 '18 at 12:58
  • @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". – Andrew Chow Jul 25 '18 at 14:26
  • This answer explains how bitcoin implemented an input/output system but not why it did so. – David Schwartz Feb 28 at 16:21

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.

  • 3
    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 Jul 30 '14 at 22:38
  • a bit of humor never hurts ;) – Jan Moritz Jul 30 '14 at 22:54
  • 1
    Humor?!? What's that! :) – Almo Jul 30 '14 at 23:12

A nice article from corda developer, which explain why corda give up simple “account/balance” ledger and use UTXO-like ledger.

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.

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.

  • 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 – sohrabsaran Jul 26 '18 at 6:22
  • 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 Jul 26 '18 at 15:22
  • 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. – sohrabsaran Jul 27 '18 at 18:26
  • 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 Jul 29 '18 at 0:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.