<p>There are a lot of good answers, but I want to point out the most obvious answer.</p>
<p>Say you have 1 bitcoin and you send 0.2 bitcoin to me and the design leaves it so that you still have 0.8 bitcoin in the same place as the 1 bitcoin you had originally. What stops someone from simply processing that transaction again? You still have the funds.</p>
<p>Designing the system so that a transaction destroys its input totally and only creates new outputs ensures that any transaction that executes cannot be valid a second time because it destroyed something it needed in order to be valid.</p>
<p>There are other ways to do this. The XRP Ledger uses accounts with balances and it requires transactions to have a &quot;sequence number&quot; in them. An account with sequence 3 can only execute a transaction with sequence 3 and in the process, the sequence number is bumped to 4 to forever invalidate the transaction. Bitcoin's method is simple and elegant.</p>

CC BY-SA 4.0
2020-07-05T18:49:50.287Z
2020-07-05T18:49:50.287Z
David Schwartz
<blockquote>
<p>And if so, why don't you just send 0.4 BTC in the beginning?</p>
</blockquote>
<p>Bitcoin was designed to allow single-in multi-out or multi-in multi-out payments. In Ethereum, only one address fills the whole &quot;to&quot; field of transactions. (This doesn't apply to contracts. Does that mean, in Ethereum, users are 2nd class citizens?)</p>
<p>If you were Satoshi and you were to allow transactions with multiple inputs, how would you design transactions so that a change output is not need? I honestly don't know. Plus, currently &quot;in&quot; fields of transactions reference <code>txid:vout</code> where vout 0, 1, 2, ... refers to an output of the transaction.</p>

CC BY-SA 4.0
2020-07-04T17:57:12.140Z
2020-07-04T17:57:12.140Z
MCCCS
<p>There are some good answers here, but I'm surprised nobody has mentioned <strong>privacy</strong>.</p>
<p>Having coins sent to a new change address can improve your privacy in many ways. Consider this simple example: a one-input two-output transaction. Which output is change? If the transaction is carefully constructed, it may be difficult for a third party to tell.</p>
<p>There are more complicated ways you can build transactions to increase privacy as well, such as 'coinjoin', 'payjoin', or 'payswap' transactions. It is an active area of research.</p>
<p>Compare this to the account model, where the leftover 'change' just stays in the same account, making privacy much more difficult to attain.</p>

CC BY-SA 4.0
2020-07-06T14:28:40.250Z
While true, it's also not ridiculously hard to track change outputs over a large number of transactions - in fact, the more change outputs you have in a chain, the higher chance of a single bad payment deanonymizing many of them
Raghav Sood
CC BY-SA 4.0
2020-07-07T07:21:18.330Z
@RaghavSood very true, it requires careful transaction handling. But in any case, the UTXO model allows for this sort of plausible deniability, while the account model does not.
chytrik
CC BY-SA 4.0
2020-07-06T11:05:45.617Z
2020-07-06T11:05:45.617Z
chytrik
<blockquote>
<p>Is that right?</p>
</blockquote>
<p>Yes.</p>
<blockquote>
<p>why don't you just send 0.4 BTC in the beginning?</p>
</blockquote>
<p>Because you need to consume the last transaction (called &quot;input&quot; of your second transaction, in your example the 1 BTC) entirely <strong>(*)</strong>, or the delta will end up paid in fees.</p>
<p>The amount paid in fees to the miner including your transaction is the amount of the input(s) you unlock, minus the amount of the output(s) you lock back (&quot;send&quot;).<br />
Since you generally really don't want to pay 0.6BTC in fees, you add another output locking funds back to you.</p>
<hr />
<p><strong>(*)</strong> Simplified so you get the idea but technically the input of your transaction is any unspent-yet output (there can be several) of a precedent transaction.</p>

CC BY-SA 4.0
2020-07-04T17:26:05.623Z
2020-07-04T17:26:05.623Z
Antoine Poinsot
<p>One major advantage of this Unspent Transaction Output(UTXO) is that it simplifies handling of cheating.  Consider the case where I have $20, and then cheat to buy two things for $11 each with the same money.  The system has to reconcile this, figuring out who gets paid and who does not.  Now amplify this to a scale where I might make a thousand purchases, some intentionally fraudulent, and some not.  The untangling could be a nightmare.</p>
<p>If you consider how you and I usually resolve this, its a first-come-first-serve approach.  The first retailer gets their money, and the rest don't.  This lines up well with what <em>would</em> have happened if we used physical money.  It would have been impossible to give $11 to the second guy in the first place!</p>
<p>However, timing is a tricky subject for Bitcoin because it is a distributed network.  There is not a single node that can timestamp all money spent to resolve this issue.  If you happen to get one purchase into the block chain, it's easy, but you may have multiple pending purchases outstanding before a new block gets minted.</p>
<p>The solution is the UTXO approach.  By forcing all money from a bitcoin account to be spent all at once, returning the remainder as &quot;change&quot; into a new account, you create an ordering for these purchases.  The extra accounts automatically construct that ordering.</p>
<p>And, as such, we can untangle nasty situations where I may have made 4 valid purchases, then 2 fraudulent ones, and then 2 transactions on each of those fraudulent chains on top of that:</p>
<ul>
<li>Purchases A, B, C, and D</li>
<li>Double spent purchases E1 and E2</li>
<li>Normal purchases E1-F and E1-G (valid if E1 is valid)</li>
<li>Normal purchases E2-F and E2-G (valid if E2 is valid)</li>
</ul>
<p>This sort of thing could be a snarl.  It's the kind of thing which leads credit card companies to have humans do the arbitration. But thanks to the UTXO model, these transactions are very clearly ordered.  The system will tie-break between E1 and E2 based on which one gets into the blockchain first.  The result will be that either A, B, C, D, E1, E1-F, and E1-G are valid, or A, B, C, D, E2, E2-F, E2-G are valid.</p>
<p>Try to construct such a system without a centralized node to timestamp purchases, and without a human to arbitrate, and you quickly appreciate the choice.  Are there other ways to do this?  Certainly.  But one has to appreciate the simplicity and clarity.</p>

CC BY-SA 4.0
2020-07-06T10:38:43.127Z
How this would be solved by a real bank is that your balance is $-2 and you get a phone call or an angry letter
Criticize SE actions means ban
CC BY-SA 4.0
2020-07-06T10:39:10.250Z
Also the blockchain already constructs an ordering regardless of whether you use the UTXO model or the account model.
Criticize SE actions means ban
CC BY-SA 4.0
2020-07-06T15:49:54.817Z
@user253751 Yes, an angry phone call.  And then legal action if need be.  Lots of people are involved in the resolution of that case with a real bank.  If you want to see how it really happens, look at the process of bankruptcy, and how humans have to sort out which creditors get what.
Cort Ammon
CC BY-SA 4.0
2020-07-06T15:52:06.777Z
@user253751 And the block chain orders things to within 10 minutes.  However, you can spend bitcoins faster than once every 10 minutes.  To avoid needing humans in the loop, we order these rapidly spent coins as well.
Cort Ammon
CC BY-SA 4.0
2020-07-07T09:39:18.587Z
The UTXO model does not order rapidly unspent coins in case of attempted fraud. You can create two transactions with the same UTXO. Only one will be accepted into the blockchain, but you have to wait for several blocks to know that.
Criticize SE actions means ban
CC BY-SA 4.0
2020-07-07T16:18:40.593Z
@user253751 And, as I stated in my answer, it will properly order the transactions around it, and will resolve disputes in a very clear algorithmic manner.  A given transaction is valid if and only if all transactions which preceeded it in order are valid.
Cort Ammon
CC BY-SA 4.0
2020-07-07T17:08:24.477Z
If you have 1 bitcoin in an account, double spend 1 satoshi out of it, and then try to buy something from me for 1 bitcoin in the same block, I can look at the transaction history, build up the partial order of transactions I am dependent on and ask questions about how likely I am to get paid my 1 bitcoin, but I am certain I will either be paid or not paid.  There wont be a mediation (like might happen in a real bank), where I get 0.99999BtC.
Cort Ammon
CC BY-SA 4.0
2020-07-07T18:50:23.433Z
More like: I create two transactions which spend the same 1 bitcoin and send them both simultaneously to different peers. 40% of the network sees the second transaction first and rejects the first one and 60% of the network sees the first transaction first and rejects the second one. Because you stupidly didn't wait for confirmation, you gave me real goods after seeing the first transaction (which pays out to you), didn't see the second one because your node rejected it, and by a 40% chance, the second one got into a block.
Criticize SE actions means ban
CC BY-SA 4.0
2020-07-07T19:23:53.913Z
@user253751 You seem to be approaching it from a human point of view, where "stupidly" plays a part.  From an algorithmic point of view, this algorithm defines a very exacting rule for how transactions will be sorted out in the less-than-ideal cases which would otherwise be more ambiguous.
Cort Ammon
CC BY-SA 4.0
2020-07-07T19:51:11.480Z
Yes and the algorithm is "wait for a certain number of blocks". Your algorithm is "wait for no blocks" and it's broken.
Criticize SE actions means ban
CC BY-SA 4.0
2020-07-07T20:03:41.520Z
@user253751 That is a usage policy, not an algorithm.  The algorithm does not state how many blocks to wait.  The algorithm is responsible for keeping the ledger functioning and self-consistent.
Cort Ammon
CC BY-SA 4.0
2020-07-08T16:05:59.970Z
@user253751 I am not referring to a service.  You may freely read about the algorithm I am referring to in [this paper](https://bitcoin.org/bitcoin.pdf)
Cort Ammon
CC BY-SA 4.0
2020-07-08T18:38:26.333Z
@user253751 And how does it decide which transactions get into the block chain and which ones do not?
Cort Ammon
CC BY-SA 4.0
2020-07-05T18:35:32.917Z
2020-07-05T18:35:32.917Z
Cort Ammon
<p>Bitcoin follows a Unspent Transaction Output (utxo) model.</p>
<p>Our modern banking systems follow an account model - you're assigned a bank account number (similar to an address), and send and receive money from it. Any incoming funds increase your total account balance, and any outgoing funds decrease it. The bank does not keep track of which funds came from which deposit. It's just a single balance.</p>
<p>Bitcoin is closer to cash - Any funds in your Bitcoin wallet are the result of a previous incoming transaction, exactly how any notes in your physical wallet are the result of previous real life transactions you've made (whether an ATM/bank withdrawal, or received as change at a store).</p>
<p>Bitcoin tracks the output of each individual transaction, just like real life notes. When you receive 1 BTC, you receive an output (note) of exactly 1 BTC. This must be spend in its entirety, and cannot be split. So if you'd like to send 0.4 BTC, you put in the entire 1 BTC into the transaction, and send 0.6 BTC to one of your own addresses in the outputs.</p>
<p>This works much the same way as buying a $5 item with a $20 note - you must put in the entire $20 note, and you will get $15 back. You can't simply tear the $20 note into four equal pieces and create 4 $5 notes.</p>
<p>Of course, unlike real cash, in Bitcoin there is no risk of the recipient simply taking your BTC and refusing to return the change - the change is sent back to an address owned by you as part of the transaction building process. The recipient of the rest of the funds has no control over it.</p>
<p>A cleaner way to think about it is using the <a href="https://en.bitcoinwiki.org/wiki/Coin_analogy" rel="noreferrer">coin</a> (physical coins, not bitcoin) analogy mentioned by <a href="https://bitcoin.stackexchange.com/users/5273/abdussamad">Abdussamad</a> in the comments - You can treat each output in your wallet as a single, indivisible coin of a fixed value.</p>
<p>When you spend these coins, transactions act as a melting pot - you can add in multiple coins to create a pot with a value of the sum of all coins, and you can use the melted coins to mint new ones of the values you want - 1 coin for the payment you're making, and one coin for the change that you keep with you. This even accounts for transaction fees - every time you melt down some coins, the pot claims a small amount that sticks to it, resulting in a final output that is slightly lower than the input.</p>

CC BY-SA 4.0
2020-07-05T11:49:47.887Z
the coin analogy is probably better than the note analogy because of the differences cited in your last paragraph: https://en.bitcoinwiki.org/wiki/Coin_analogy
Abdussamad
CC BY-SA 4.0
2020-07-05T12:29:46.823Z
@Abdussamad Good point - I've expanded on it in an edit, thank you!
Raghav Sood
CC BY-SA 4.0
2020-07-07T14:05:24.833Z
Your description of the "modern banking systems" is *completely* wrong. They are based on  transactions very similar to how bitcoin works. Account balances are not generally stored, they are derived by adding up incoming and outgoing transactions. Look up "double-entry bookkeeping".
Michael Borgwardt
CC BY-SA 4.0
2020-07-07T14:16:57.237Z
@MichaelBorgwardt Sure, on an internal level - as a user, it is exposed via a single account balance. I doubt getting into banking implementation details is going to help explain bitcoin any better to folks
Raghav Sood
CC BY-SA 4.0
2020-07-05T08:32:46.480Z
2020-07-06T01:56:23.230Z
2020-07-06T01:56:23.230Z
Raghav Sood
<p>I have read about a change address and wondered why there even is the concept of change?</p>
<p>Let's say I received 1 BTC from some person <em>A</em> and I want to send 0.4 BTC to another person <em>B</em>, afterwards. From what I have understood, I have to send the 1 BTC, as a whole and then get 0.6 BTC as change.</p>
<p>Is that right? And if so, why don't you just send 0.4 BTC in the beginning?</p>

<transactions><utxo><change>
Why is there "Change" in Bitcoins?
André Kuhlmann
# Why is there "Change" in Bitcoins?

(Asked by: username_0 on 2020-07-04)

I have read about a change address and wondered why there even is the concept of change?

Let's say I received 1 BTC from some person *A* and I want to send 0.4 BTC to another person *B*, afterwards. From what I have understood, I have to send the 1 BTC, as a whole and then get 0.6 BTC as change.

Is that right? And if so, why don't you just send 0.4 BTC in the beginning?

**Tags:** transactions, utxo, change


---

## 6 answers

### Answer by username_4 on 2020-07-05. Score: 23 | Accepted answer

Bitcoin follows a Unspent Transaction Output (utxo) model.

Our modern banking systems follow an account model - you're assigned a bank account number (similar to an address), and send and receive money from it. Any incoming funds increase your total account balance, and any outgoing funds decrease it. The bank does not keep track of which funds came from which deposit. It's just a single balance.

Bitcoin is closer to cash - Any funds in your Bitcoin wallet are the result of a previous incoming transaction, exactly how any notes in your physical wallet are the result of previous real life transactions you've made (whether an ATM/bank withdrawal, or received as change at a store).

Bitcoin tracks the output of each individual transaction, just like real life notes. When you receive 1 BTC, you receive an output (note) of exactly 1 BTC. This must be spend in its entirety, and cannot be split. So if you'd like to send 0.4 BTC, you put in the entire 1 BTC into the transaction, and send 0.6 BTC to one of your own addresses in the outputs.

This works much the same way as buying a $5 item with a $20 note - you must put in the entire $20 note, and you will get $15 back. You can't simply tear the $20 note into four equal pieces and create 4 $5 notes.

Of course, unlike real cash, in Bitcoin there is no risk of the recipient simply taking your BTC and refusing to return the change - the change is sent back to an address owned by you as part of the transaction building process. The recipient of the rest of the funds has no control over it.

A cleaner way to think about it is using the [coin](https://en.bitcoinwiki.org/wiki/Coin_analogy) (physical coins, not bitcoin) analogy mentioned by [username_8](https://bitcoin.stackexchange.com/users/5273/username_8) in the comments - You can treat each output in your wallet as a single, indivisible coin of a fixed value.

When you spend these coins, transactions act as a melting pot - you can add in multiple coins to create a pot with a value of the sum of all coins, and you can use the melted coins to mint new ones of the values you want - 1 coin for the payment you're making, and one coin for the change that you keep with you. This even accounts for transaction fees - every time you melt down some coins, the pot claims a small amount that sticks to it, resulting in a final output that is slightly lower than the input.

> **Comments:**
> **username_8**: the coin analogy is probably better than the note analogy because of the differences cited in your last paragraph: https://en.bitcoinwiki.org/wiki/Coin_analogy  
> **username_4**: @username_8 Good point - I've expanded on it in an edit, thank you!  
> **username_9**: Your description of the "modern banking systems" is *completely* wrong. They are based on  transactions very similar to how bitcoin works. Account balances are not generally stored, they are derived by adding up incoming and outgoing transactions. Look up "double-entry bookkeeping".  
> **username_4**: @username_9 Sure, on an internal level - as a user, it is exposed via a single account balance. I doubt getting into banking implementation details is going to help explain bitcoin any better to folks  

---

### Answer by username_1 on 2020-07-05. Score: 11

There are a lot of good answers, but I want to point out the most obvious answer.

Say you have 1 bitcoin and you send 0.2 bitcoin to me and the design leaves it so that you still have 0.8 bitcoin in the same place as the 1 bitcoin you had originally. What stops someone from simply processing that transaction again? You still have the funds.

Designing the system so that a transaction destroys its input totally and only creates new outputs ensures that any transaction that executes cannot be valid a second time because it destroyed something it needed in order to be valid.

There are other ways to do this. The XRP Ledger uses accounts with balances and it requires transactions to have a "sequence number" in them. An account with sequence 3 can only execute a transaction with sequence 3 and in the process, the sequence number is bumped to 4 to forever invalidate the transaction. Bitcoin's method is simple and elegant.


---

### Answer by username_2 on 2020-07-04. Score: 5

> And if so, why don't you just send 0.4 BTC in the beginning?

Bitcoin was designed to allow single-in multi-out or multi-in multi-out payments. In Ethereum, only one address fills the whole "to" field of transactions. (This doesn't apply to contracts. Does that mean, in Ethereum, users are 2nd class citizens?)

If you were Satoshi and you were to allow transactions with multiple inputs, how would you design transactions so that a change output is not need? I honestly don't know. Plus, currently "in" fields of transactions reference `txid:vout` where vout 0, 1, 2, ... refers to an output of the transaction.


---

### Answer by username_3 on 2020-07-06. Score: 4

There are some good answers here, but I'm surprised nobody has mentioned **privacy**.

Having coins sent to a new change address can improve your privacy in many ways. Consider this simple example: a one-input two-output transaction. Which output is change? If the transaction is carefully constructed, it may be difficult for a third party to tell.

There are more complicated ways you can build transactions to increase privacy as well, such as 'coinjoin', 'payjoin', or 'payswap' transactions. It is an active area of research.

Compare this to the account model, where the leftover 'change' just stays in the same account, making privacy much more difficult to attain.

> **Comments:**
> **username_4**: While true, it's also not ridiculously hard to track change outputs over a large number of transactions - in fact, the more change outputs you have in a chain, the higher chance of a single bad payment deanonymizing many of them  
> **username_3**: @username_4 very true, it requires careful transaction handling. But in any case, the UTXO model allows for this sort of plausible deniability, while the account model does not.  

---

### Answer by username_5 on 2020-07-04. Score: 2

> Is that right?

Yes.

> why don't you just send 0.4 BTC in the beginning?

Because you need to consume the last transaction (called "input" of your second transaction, in your example the 1 BTC) entirely **(\*)**, or the delta will end up paid in fees.

The amount paid in fees to the miner including your transaction is the amount of the input(s) you unlock, minus the amount of the output(s) you lock back ("send").  
Since you generally really don't want to pay 0.6BTC in fees, you add another output locking funds back to you.

---

**(\*)** Simplified so you get the idea but technically the input of your transaction is any unspent-yet output (there can be several) of a precedent transaction.


---

### Answer by username_6 on 2020-07-05. Score: 2

One major advantage of this Unspent Transaction Output(UTXO) is that it simplifies handling of cheating. Consider the case where I have $20, and then cheat to buy two things for $11 each with the same money. The system has to reconcile this, figuring out who gets paid and who does not. Now amplify this to a scale where I might make a thousand purchases, some intentionally fraudulent, and some not. The untangling could be a nightmare.

If you consider how you and I usually resolve this, its a first-come-first-serve approach. The first retailer gets their money, and the rest don't. This lines up well with what *would* have happened if we used physical money. It would have been impossible to give $11 to the second guy in the first place!

However, timing is a tricky subject for Bitcoin because it is a distributed network. There is not a single node that can timestamp all money spent to resolve this issue. If you happen to get one purchase into the block chain, it's easy, but you may have multiple pending purchases outstanding before a new block gets minted.

The solution is the UTXO approach. By forcing all money from a bitcoin account to be spent all at once, returning the remainder as "change" into a new account, you create an ordering for these purchases. The extra accounts automatically construct that ordering.

And, as such, we can untangle nasty situations where I may have made 4 valid purchases, then 2 fraudulent ones, and then 2 transactions on each of those fraudulent chains on top of that:

* Purchases A, B, C, and D
* Double spent purchases E1 and E2
* Normal purchases E1-F and E1-G (valid if E1 is valid)
* Normal purchases E2-F and E2-G (valid if E2 is valid)

This sort of thing could be a snarl. It's the kind of thing which leads credit card companies to have humans do the arbitration. But thanks to the UTXO model, these transactions are very clearly ordered. The system will tie-break between E1 and E2 based on which one gets into the blockchain first. The result will be that either A, B, C, D, E1, E1-F, and E1-G are valid, or A, B, C, D, E2, E2-F, E2-G are valid.

Try to construct such a system without a centralized node to timestamp purchases, and without a human to arbitrate, and you quickly appreciate the choice. Are there other ways to do this? Certainly. But one has to appreciate the simplicity and clarity.

> **Comments:**
> **username_7**: How this would be solved by a real bank is that your balance is $-2 and you get a phone call or an angry letter  
> **username_7**: Also the blockchain already constructs an ordering regardless of whether you use the UTXO model or the account model.  
> **username_6**: @user253751 Yes, an angry phone call.  And then legal action if need be.  Lots of people are involved in the resolution of that case with a real bank.  If you want to see how it really happens, look at the process of bankruptcy, and how humans have to sort out which creditors get what.  
> **username_6**: @user253751 And the block chain orders things to within 10 minutes.  However, you can spend bitcoins faster than once every 10 minutes.  To avoid needing humans in the loop, we order these rapidly spent coins as well.  
> **username_7**: The UTXO model does not order rapidly unspent coins in case of attempted fraud. You can create two transactions with the same UTXO. Only one will be accepted into the blockchain, but you have to wait for several blocks to know that.  
> **username_6**: @user253751 And, as I stated in my answer, it will properly order the transactions around it, and will resolve disputes in a very clear algorithmic manner.  A given transaction is valid if and only if all transactions which preceeded it in order are valid.  
> **username_6**: If you have 1 bitcoin in an account, double spend 1 satoshi out of it, and then try to buy something from me for 1 bitcoin in the same block, I can look at the transaction history, build up the partial order of transactions I am dependent on and ask questions about how likely I am to get paid my 1 bitcoin, but I am certain I will either be paid or not paid.  There wont be a mediation (like might happen in a real bank), where I get 0.99999BtC.  
> **username_7**: More like: I create two transactions which spend the same 1 bitcoin and send them both simultaneously to different peers. 40% of the network sees the second transaction first and rejects the first one and 60% of the network sees the first transaction first and rejects the second one. Because you stupidly didn't wait for confirmation, you gave me real goods after seeing the first transaction (which pays out to you), didn't see the second one because your node rejected it, and by a 40% chance, the second one got into a block.  
> **username_6**: @user253751 You seem to be approaching it from a human point of view, where "stupidly" plays a part.  From an algorithmic point of view, this algorithm defines a very exacting rule for how transactions will be sorted out in the less-than-ideal cases which would otherwise be more ambiguous.  
> **username_7**: Yes and the algorithm is "wait for a certain number of blocks". Your algorithm is "wait for no blocks" and it's broken.  
> **username_6**: @user253751 That is a usage policy, not an algorithm.  The algorithm does not state how many blocks to wait.  The algorithm is responsible for keeping the ledger functioning and self-consistent.  
> **username_6**: @user253751 I am not referring to a service.  You may freely read about the algorithm I am referring to in [this paper](https://bitcoin.org/bitcoin.pdf)  
> **username_6**: @user253751 And how does it decide which transactions get into the block chain and which ones do not?  

---

