I understand what change is and how it works (and it's analogous to physical money change), but what I don't understand is why this is needed in the first place.

Given that this is all computer based, I thought that money could be sent just by saying “I will give you 0.5 BTC” and verifying that your addresses in fact contain more than 0.5 BTC, and then substracting the spent amount.

So, my question is, why does the protocol define that outputs must be spent entirely? Where's the benefit of doing that instead of just sending the fraction that is needed?

  • possible duplicate of How does change work in a bitcoin transaction?
    – aland
    Commented Jan 15, 2014 at 18:18
  • In short, there are simply no "accounts". There are only unspent transactions that you have means to spent. And the system do not allow to spent transaction partially. Probably, to simplify internal logic (when verifying new transaction, you have to only check whether its inputs are valid, not go over whole blockchain looking for all transactions which spend money from every input).
    – aland
    Commented Jan 15, 2014 at 18:26
  • 4
    I don't really consider it as a duplicate. Commented Jan 15, 2014 at 19:28
  • 4
    My question is more about why, not how. Commented Jan 15, 2014 at 21:50

4 Answers 4


It's in fact a little more advanced than you imagine it. (So expect this answer to be a bit more in-depth.)

There is no such thing as an accounts "balance". It only exists implicitly.

When people make transactions, they actually create outputs for a certain amount of bitcoins. Using a special script language, the person making the transaction can specify the requirement for spending that output. There's a whole range of options you have to specify this.

The most common output script is something that holds the following condition "to spend this transaction, the spender must sign this hash with the private key from this address". So this basically means that the owner of that address can spend it. This are the type of outputs that you will probably generate when you "send money to an address". They are called pay-to-pubkey-hash transactions.

Other possible output scripts can be stupid things like "anyone can spend this" to very complex things like "at least 3 of the private keys of the following 5 addresses must sign this hash", which is a so-called m-of-n transaction.

This brings us back to balances. When your wallet app says you have a balance of X btc, it just searches all unspent outputs that you are able to spend with your private keys; this are all pay-to-pubkey-hash transactions with one of your addresses in them.

Now, when you want to spend some of the money from your "balance" and send it to an address, you will need to make a transaction. The way transactions are created is as follows:

  • Take a number of unspent outputs from previous transactions and use them as inputs.
  • Make a new output of which the output amount is equal or less than the sum of all input values. Your wallet will most probably make this output a pay-to-pubkey-hash output to the address you wanted to send money to.
  • Because probably the inputs will not exactly match, you will add another output so that the sum of all new outputs is equal to the sum of the inputs. This output will also be a pay-to-pubkey-hash output to a new change address or to the same address as you are spending from (different wallet apps do this differently).
  • Note that if the total output amount is less than the total input amount, the difference is considered the transaction fee and this will go to the miner of the block your transaction will appear in.
  • Then lastly the wallet app has to prove it has the right to spend the inputs you used in the transaction. It can do this to provide an input script (technically it's called a scriptSig). For the common pay-to-pubkey-hash, this script will contain your public key and the signature you made with your private key. This input script is used by miners to verify if you have the right to make this transaction.
  • The transaction is then broadcast to the Bitcoin network.

After this transaction has been received by other clients and is verified by a miner, all clients will remove the outputs used in the transaction from their collection of "unspent outputs". So if you would try to spend it again, that won't be possible because miners will not accept it because the output you want to spend does not exist.

I hope you can understand that using this methodology, it is not possible to do a thing like "subtract the amount from person A's balance and add it to person B's balance". When making transactions, you basically destroy some outputs to generate new ones.

  • 1
    OK, so if I understand correctly, the script conditions are the ones requiring the whole output to be spent, right? Commented Jan 15, 2014 at 21:54
  • 1
    Well, not really. But it would just be very hard to allow partial spends. The current model only supports "spending a transaction" which implies that it's gone and can't be spend again. You could try to mimic partial spending by just adding a new output with the exact same script but a lower amount. Commented Jan 16, 2014 at 11:30
  • 2
    I see. Thanks for the very detailed answer. It's been very helpful. Commented Jan 16, 2014 at 16:22
  • 1
    Incredibly helpful - thank you for the clear explanation. Commented Dec 27, 2017 at 3:54
  • 1
    @David Schwartz: OK I open a new question. There is one quite similar question, but he/she asks not as generic as I do, so I think it's no duplicate and therefore ok. I'm looking forward to read your answer. bitcoin.stackexchange.com/questions/74551/utxo-vs-account-model
    – Ini
    Commented Apr 30, 2018 at 19:03

The original paper has this line, which I believe gets at why you have to spend outputs entirely.

It should be noted that fan-out, where a transaction depends on several transactions, and those transactions depend on many more, is not a problem here. There is never the need to extract a complete standalone copy of a transaction's history

If you didn't have to spend an output entirely, you would need to check every other transaction that also includes that output and make sure the sum wasn't more than it contained.

I'm not 100% certain why inputs and outputs were used rather than keeping balances directly. Ethereum and Ripple keep track of balances directly in the ledger. I suspect there are implementation pros and cons. The following answers list advantages to inputs/outputs. I'd be curious to hear an Ethereum dev's counterarguments to these.

Why does Bitcoin use the input/output system?

Why does Bitcoin store all transaction inputs and outputs, instead of just an "account/balance" ledger?

  • What does he mean with problem? Problem in regards to what?
    – Ini
    Commented Apr 30, 2018 at 13:59
  • @Invader: as in one does not need to worry about quasi-geometric growth (hence 'fan-out') in complexity of verifying transactions through a deep inspection of their history
    – obataku
    Commented Jun 22, 2018 at 12:00
  • As one of the people who made the decision to implement the XRP Ledger using accounts and balances, I can tell you that those answers explain how bitcoin implemented an input/output system but not why. I strongly suspect the reason bitcoin did so is that it's slightly simpler and there didn't seem to be any need for the significantly improved functionality that an account/balance system can provide. However, systems like ethereum and the XRP Ledger that use an account/balance system can do important things input/output systems really can't do.such as account management and delegation. Commented Feb 28, 2019 at 16:24

Outputs cannot be changed. They can only be created and spent. Since it is unlikely that you'll have the exact matching amount available when sending funds to a recipient, most transactions therefore need to send back change to the sender.
This ties into how transaction fees work: Miners can collect the difference between the input value and the output value as transaction fees. Thus, any funds not explicitly sent back to the sender become transaction fees.

Outputs are explicitly created by transactions and can then be uniquely tracked by means of their outpoint. The outpoint consists of txid:vout, i.e. the transaction hash of the transaction that created an output, concatenated by a colon with the position of the output in that transaction's output list.
Tracking outputs explicitly, e.g.

  • mitigates replay attacks and double-spend attacks (after confirmation)
  • makes it possible for multiple transactions from the same wallet to confirm in various orders, allowing for transactions to signal different priorities
  • allows updating of transactions
  • facilitates chaining transactions explicitly to each other (e.g. used for Lightning Network)
  • require little information for thin-clients to know about spendable funds
  • supports use of many unrelated addresses for better privacy

The main disadvantages of the UTXO-based design are that it is somewhat counter-intuitive compared to account-based designs, and that it requires more data to identify the spent funds.

  • That does not answer the question
    – Ini
    Commented Apr 30, 2018 at 14:01
  • @Invader: I don't understand why you think that. Since Bitcoin balances are stored in Unspent Transaction Outputs, and those can only be created and destroyed, but not changed, you can only spend UTXO in their entirety. I believe that my answer explains that (although I could probably explain it better by now).
    – Murch
    Commented May 1, 2018 at 3:06
  • The question is about the WHY. So the reason why it is designed that way. I guess to answer such a question somebody would have to point out pros and cons of different approaches.
    – Ini
    Commented May 1, 2018 at 11:35
  • 1
    @Invader: Thank you for your feedback. I've tried to improve my answer. What do you think?
    – Murch
    Commented May 1, 2018 at 18:40
  • I mean your answer is good, but I guess there is no real answer to this question, because we already have two approaches (UTXO and the account-model) and both seem to work. Maybe you can diviate slightly from UTXO and create another approach etc.. There are pros and cons to each method and Satoshi chose the UTXO design.
    – Ini
    Commented May 2, 2018 at 13:09

I'm not sure if this is true, but I want to help and so far I've seen no real answer to this question so far (the question is WHY) besides people say it is more beautiful this way.

- spv

By downloading the txs + merkleproofs + block-headers you know how much funds you have in case the full-node delivers you all your txs + merkleproofs + block-headers and of course given that you receive this from the longest chain.

When you would update the balance of an output in the memory of the node like this (somehow similar to an account-approach): balance_begin and balance_now (after the output was partly spend). The spv proof to know your balance would be much bigger, because it also needs to provide the txs + merkleproofs + block-headers that have spent parts of the output.

- privacy

Nobody knows if you spend the other output to pay for something else or if it is your change.

Can somebody confirm this or is what I'm writing simply not true?

  • You cannot update the balance of an output. Balances are only an abstraction to make Bitcoin wallet's easier to read for humans.
    – Murch
    Commented May 1, 2018 at 3:07
  • I did not say that UTXOs work this way. I brought an example with another approach to point of the benefits of the UTXO approach.
    – Ini
    Commented May 1, 2018 at 11:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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