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

<blockquote>
  <p>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</p>
</blockquote>

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

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

<p><a href="https://bitcoin.stackexchange.com/questions/39177/why-does-bitcoin-use-the-input-output-system?rq=1">Why does Bitcoin use the input/output system?</a></p>

<p><a href="https://bitcoin.stackexchange.com/questions/29780/why-does-bitcoin-store-all-transaction-inputs-and-outputs-instead-of-just-an-a">Why does Bitcoin store all transaction inputs and outputs, instead of just an &quot;account/balance&quot; ledger?</a></p>

CC BY-SA 3.0
2018-04-30T13:59:39.183Z
What does he mean with problem? Problem in regards to what?
Ini
CC BY-SA 4.0
2018-06-22T12:00:30.813Z
@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
CC BY-SA 4.0
2019-02-28T16:24:33.403Z
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.
David Schwartz
CC BY-SA 3.0
2016-03-10T12:46:56.770Z
2016-03-10T12:46:56.770Z
2017-04-13T12:47:33.610Z
Scott Driscoll
<p><strong>Outputs cannot be changed</strong>. 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.<br>
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.</p>

<p>Outputs are explicitly created by transactions and can then be uniquely tracked by means of their <code>outpoint</code>. The <code>outpoint</code> consists of <code>txid:vout</code>, 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.<br>
Tracking outputs explicitly, e.g. </p>

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

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

CC BY-SA 3.0
2018-04-30T14:01:20.697Z
That does not answer the question
Ini
CC BY-SA 3.0
2018-05-01T03:06:23.930Z
@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
CC BY-SA 3.0
2018-05-01T11:35:48.433Z
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
CC BY-SA 3.0
2018-05-01T18:40:05.187Z
@Invader: Thank you for your feedback. I've tried to improve my answer. What do you think?
Murch
CC BY-SA 4.0
2018-05-02T13:09:36.477Z
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
CC BY-SA 3.0
2014-01-20T16:00:22.050Z
2018-05-01T18:46:37.103Z
2018-05-01T18:46:37.103Z
Murch
<p>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.</p>

<p><strong>- spv</strong> </p>

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

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

<p><strong>- privacy</strong></p>

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

<p>Can somebody confirm this or is what I'm writing simply not true?</p>

CC BY-SA 3.0
2018-05-01T03:07:37.373Z
You cannot update the balance of an output. Balances are only an abstraction to make Bitcoin wallet's easier to read for humans.
Murch
CC BY-SA 3.0
2018-05-01T11:33:15.993Z
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
CC BY-SA 3.0
2018-04-30T14:42:52.773Z
2018-04-30T14:52:00.313Z
2018-04-30T14:52:00.313Z
Ini
<p>It's in fact a little more advanced than you imagine it. (So expect this answer to be a bit more in-depth.)</p>

<p>There is no such thing as an accounts "balance". It only exists implicitly.</p>

<p>When people make transactions, they actually create outputs for a certain amount of bitcoins. Using a <a href="https://en.bitcoin.it/wiki/Script" rel="nofollow noreferrer">special script language</a>, 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.</p>

<p>The most common <em>output script</em> 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 <a href="https://en.bitcoin.it/wiki/Script#Standard_Transaction_to_Bitcoin_address_.28pay-to-pubkey-hash.29" rel="nofollow noreferrer">pay-to-pubkey-hash</a> transactions.</p>

<p>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 <a href="https://en.bitcoin.it/wiki/BIP_0011" rel="nofollow noreferrer">m-of-n transaction</a>.</p>

<p>This brings us back to balances. When your wallet app says you have a balance of X btc, it just searches all <em>unspent outputs</em> 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.</p>

<p>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:</p>

<ul>
<li>Take a number of unspent outputs from previous transactions and use them as inputs.</li>
<li>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 <em>pay-to-pubkey-hash</em> output to the address you wanted to send money to.</li>
<li>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 <em>pay-to-pubkey-hash</em> output to a new change address or to the same address as you are spending from (different wallet apps do this differently).</li>
<li>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.</li>
<li>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 <em>input script</em> (technically it's called a <a href="https://en.bitcoin.it/wiki/Transactions#Verification" rel="nofollow noreferrer"><em>scriptSig</em></a>). 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.</li>
<li>The transaction is then broadcast to the Bitcoin network.</li>
</ul>

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

<p>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 <em>destroy</em> some outputs to generate new ones.</p>

CC BY-SA 3.0
2014-01-15T21:54:45.007Z
OK, so if I understand correctly, the script conditions are the ones requiring the whole output to be spent, right?
Arturo Torres Sánchez
CC BY-SA 3.0
2014-01-16T11:30:18.143Z
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.
Steven Roose
CC BY-SA 3.0
2014-01-16T16:22:21.023Z
I see. Thanks for the very detailed answer. It's been very helpful.
Arturo Torres Sánchez
CC BY-SA 3.0
2017-12-27T03:54:32.707Z
Incredibly helpful - thank you for the clear explanation.
Dave Friedel
CC BY-SA 3.0
2018-04-27T13:00:46.313Z
@Invader well, I think the original question just didn't understand outputs in general.
Steven Roose
CC BY-SA 3.0
2018-04-30T14:09:37.107Z
To me it does also not explain the why. I mean why should it not be possible to update balance of the output? Is it just because it is more beatiful to do it like that or is there a real reason?
Ini
CC BY-SA 3.0
2018-04-30T17:35:34.723Z
@Invader There are two possible models, the UTXO model and the account model. Each has advantages and disadvantages. Bitcoin chose the UTXO model. XRP uses an account model. If you want, you can ask a separate question about the advantages and disadvantages of each model.
David Schwartz
CC BY-SA 3.0
2018-04-30T19:03:24.120Z
@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.
https://bitcoin.stackexchange.com/questions/74551/utxo-vs-account-model
Ini
CC BY-SA 3.0
2018-04-30T19:03:31.123Z
@David Schwartz: Do you know an answer to WHY in the UTXO model you have to spend the entire utxo / WHY it is conceptualized this way? Do you think my answer here is correct?
Ini
CC BY-SA 4.0
2018-05-03T06:07:03.993Z
@Invader That's how the UTXO model works. Transactions only consume UTXOs and create UTXOs. An UTXO either exists or it doesn't.
David Schwartz
CC BY-SA 4.0
2019-02-26T12:58:22.973Z
Minor correction. The input script technically is called `scriptSig` and not `scriptPubKey`. It is also known as `unlocking script` or `witness`. This should correspond to the locking condition of the input you are trying to spend which is technically called `scriptPubKey` or `locking script` or `witness script`.
thalisk
CC BY-SA 4.0
2019-02-27T14:13:35.340Z
Thanks for the correction, I just edited the post. This was written long before segregated witness existed, so there is of course no mentions of witnesses.
Steven Roose
CC BY-SA 4.0
2014-01-15T19:27:42.767Z
2019-02-27T14:12:39.430Z
2019-02-27T14:12:39.430Z
Steven Roose
<p>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.</p>

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

<p>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?</p>

CC BY-SA 3.0
2014-01-15T18:18:45.987Z
possible duplicate of [How does change work in a bitcoin transaction?](http://bitcoin.stackexchange.com/questions/736/how-does-change-work-in-a-bitcoin-transaction)
aland
CC BY-SA 3.0
2014-01-15T18:26:36.137Z
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
CC BY-SA 3.0
2014-01-15T19:28:37.930Z
I don't really consider it as a duplicate.
Steven Roose
CC BY-SA 3.0
2014-01-15T21:50:04.700Z
My question is more about why, not how.
Arturo Torres Sánchez
<transactions><utxo>
Why do outputs need to be spent entirely?
Arturo Torres Sánchez
# Why do outputs need to be spent entirely?

(Asked by: username_0 on 2014-01-15)

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?

**Tags:** transactions, utxo

> **Comments:**
> **username_1**: possible duplicate of [How does change work in a bitcoin transaction?](http://bitcoin.stackexchange.com/questions/736/how-does-change-work-in-a-bitcoin-transaction)  
> **username_1**: 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).  
> **username_2**: I don't really consider it as a duplicate.  
> **username_0**: My question is more about why, not how.  

---

## 4 answers

### Answer by username_2 on 2014-01-15. Score: 12 | Accepted answer

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](https://en.bitcoin.it/wiki/Script), 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](https://en.bitcoin.it/wiki/Script#Standard_Transaction_to_Bitcoin_address_.28pay-to-pubkey-hash.29) 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](https://en.bitcoin.it/wiki/BIP_0011).

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*](https://en.bitcoin.it/wiki/Transactions#Verification)). 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.

> **Comments:**
> **username_0**: OK, so if I understand correctly, the script conditions are the ones requiring the whole output to be spent, right?  
> **username_2**: 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.  
> **username_0**: I see. Thanks for the very detailed answer. It's been very helpful.  
> **username_8**: Incredibly helpful - thank you for the clear explanation.  
> **username_2**: @Invader well, I think the original question just didn't understand outputs in general.  
> **username_4**: To me it does also not explain the why. I mean why should it not be possible to update balance of the output? Is it just because it is more beatiful to do it like that or is there a real reason?  
> **username_6**: @Invader There are two possible models, the UTXO model and the account model. Each has advantages and disadvantages. Bitcoin chose the UTXO model. XRP uses an account model. If you want, you can ask a separate question about the advantages and disadvantages of each model.  
> **username_4**: @username_6: 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. https://bitcoin.stackexchange.com/questions/74551/utxo-vs-account-model  
> **username_4**: @username_6: Do you know an answer to WHY in the UTXO model you have to spend the entire utxo / WHY it is conceptualized this way? Do you think my answer here is correct?  
> **username_6**: @Invader That's how the UTXO model works. Transactions only consume UTXOs and create UTXOs. An UTXO either exists or it doesn't.  
> **username_9**: Minor correction. The input script technically is called `scriptSig` and not `scriptPubKey`. It is also known as `unlocking script` or `witness`. This should correspond to the locking condition of the input you are trying to spend which is technically called `scriptPubKey` or `locking script` or `witness script`.  
> **username_2**: Thanks for the correction, I just edited the post. This was written long before segregated witness existed, so there is of course no mentions of witnesses.  

---

### Answer by username_3 on 2016-03-10. Score: 4

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?](https://bitcoin.stackexchange.com/questions/39177/why-does-bitcoin-use-the-input-output-system?rq=1)

[Why does Bitcoin store all transaction inputs and outputs, instead of just an "account/balance" ledger?](https://bitcoin.stackexchange.com/questions/29780/why-does-bitcoin-store-all-transaction-inputs-and-outputs-instead-of-just-an-a)

> **Comments:**
> **username_4**: What does he mean with problem? Problem in regards to what?  
> **username_5**: @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  
> **username_6**: 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.  

---

### Answer by username_7 on 2014-01-20. Score: 2

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

> **Comments:**
> **username_4**: That does not answer the question  
> **username_7**: @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).  
> **username_4**: 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.  
> **username_7**: @Invader: Thank you for your feedback. I've tried to improve my answer. What do you think?  
> **username_4**: 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.  

---

### Answer by username_4 on 2018-04-30. Score: 1

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?

> **Comments:**
> **username_7**: You cannot update the balance of an output. Balances are only an abstraction to make Bitcoin wallet's easier to read for humans.  
> **username_4**: 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.  

---

