Why do outputs need to be spent entirely?

Question

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?

Answer 1

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.

Answer 2

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?

Answer 3

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.

Answer 4

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?