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?
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 (physical coins, not bitcoin) analogy mentioned by Abdussamad 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.
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.
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.
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.
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.
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:
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.
