<p>That would not work because the way the system is designed, accounts do not have a pile of coins to spend. Spendable coins exist in the form of transaction outputs that have not yet been used as the input of a subsequent transaction. To form a valid transaction, you must pull in coins from specific transaction outputs, not from specific accounts.</p>

<p>One could imagine a Bitcoin-like system where accounts have balances. In such a system, you could simply report the new balance of an account in any block that modified that account's balance. Then a transaction could pull in from accounts rather than specific transaction outputs. But that system would not be Bitcoin.</p>

<p>Essentially, Bitcoin was not designed around accounts. Accounts are just a convenient way for human beings using Bitcoin to think about the set of transaction outputs that can be claimed with the same key. (Or to form transactions that we know can only be claimed by a particular person.)</p>

CC BY-SA 3.0
2012-08-08T21:36:37.797Z
2012-08-08T21:36:37.797Z
David Schwartz
<p>Technically, you should use a new address for each new incoming transaction to protect your anonymity. The standard client likewise sends the remaining balance after a transfer to a new keypair. This would make the transaction amount synonymous with the balance.</p>

<p>As for addresses that are used more than once - it would be first of all a bit wasteful (having to add an extra field for each transaction), and moreover - you don't need to claim all the inputs for a given address each time you send coins. Sometimes you don't want to claim each input - for example with low-confirmation transactions. Say you have a transaction that has 10 confirmations and one that has 1 - if you want to make sure your transfer will go through even if some blocks get overwritten, you would only use the 10 confirmation input and leave the 1 confirmation one to mature. Such operations would make the balances go wrong very quickly.</p>

CC BY-SA 3.0
2016-10-30T23:57:48.207Z
@ChrisMoore A very low price to pay in exchange for assuring that there is agreement on what those balances are.
David Schwartz
CC BY-SA 3.0
2012-08-08T23:06:45.210Z
I think you would have to add more than one field per transaction.  Every input and every output would change the balance of an address, so every input and every output would have to state the new balance for the address it touches.
Chris Moore
CC BY-SA 3.0
2012-08-08T10:06:40.313Z
2012-08-08T10:06:40.313Z
ThePiachu
<p>When you receive a payment, you could presumably find from the transaction which block an input came from, and then request a copy of just that block to verify the balance.  But without having all the blocks from that block to the latest one you wouldn't know whether the inputs had already been spent in another transaction.</p>

<p>Proposed schemes which do appear to be workable maintain a list of the balance of all addresses in a separate blockchain.</p>

CC BY-SA 3.0
2012-08-08T23:10:16.330Z
2012-08-08T23:10:16.330Z
Chris Moore
<p>Currently one needs to traverse the full blockchain to determine the balance of a certain address. Wouldn't it be much more efficient to include the new balance along with each transaction? That way clients wouldn't need the whole blockchain to verify a transaction, since miners already verified the balance.</p>

<transactions><blockchain><protocol><development><balance>
Why are balances not in the blockchain?
Maestro
# Why are balances not in the blockchain?

(Asked by: username_0 on 2012-08-08)

Currently one needs to traverse the full blockchain to determine the balance of a certain address. Wouldn't it be much more efficient to include the new balance along with each transaction? That way clients wouldn't need the whole blockchain to verify a transaction, since miners already verified the balance.

**Tags:** transactions, blockchain, protocol, development, balance


---

## 3 answers

### Answer by username_1 on 2012-08-08. Score: 3

That would not work because the way the system is designed, accounts do not have a pile of coins to spend. Spendable coins exist in the form of transaction outputs that have not yet been used as the input of a subsequent transaction. To form a valid transaction, you must pull in coins from specific transaction outputs, not from specific accounts.

One could imagine a Bitcoin-like system where accounts have balances. In such a system, you could simply report the new balance of an account in any block that modified that account's balance. Then a transaction could pull in from accounts rather than specific transaction outputs. But that system would not be Bitcoin.

Essentially, Bitcoin was not designed around accounts. Accounts are just a convenient way for human beings using Bitcoin to think about the set of transaction outputs that can be claimed with the same key. (Or to form transactions that we know can only be claimed by a particular person.)


---

### Answer by username_2 on 2012-08-08. Score: 1

Technically, you should use a new address for each new incoming transaction to protect your anonymity. The standard client likewise sends the remaining balance after a transfer to a new keypair. This would make the transaction amount synonymous with the balance.

As for addresses that are used more than once - it would be first of all a bit wasteful (having to add an extra field for each transaction), and moreover - you don't need to claim all the inputs for a given address each time you send coins. Sometimes you don't want to claim each input - for example with low-confirmation transactions. Say you have a transaction that has 10 confirmations and one that has 1 - if you want to make sure your transfer will go through even if some blocks get overwritten, you would only use the 10 confirmation input and leave the 1 confirmation one to mature. Such operations would make the balances go wrong very quickly.

> **Comments:**
> **username_3**: I think you would have to add more than one field per transaction.  Every input and every output would change the balance of an address, so every input and every output would have to state the new balance for the address it touches.  
> **username_1**: @username_3 A very low price to pay in exchange for assuring that there is agreement on what those balances are.  

---

### Answer by username_3 on 2012-08-08. Score: 0

When you receive a payment, you could presumably find from the transaction which block an input came from, and then request a copy of just that block to verify the balance. But without having all the blocks from that block to the latest one you wouldn't know whether the inputs had already been spent in another transaction.

Proposed schemes which do appear to be workable maintain a list of the balance of all addresses in a separate blockchain.


---

