<p>Transaction outputs only have two states, spent and unspent, so spending part of one is not possible without the creation of another. With a boolean spent/unspent there is no state to have to store and recall, which allows for simpler states in wallets and makes scaling away from the block chain significantly easier. Imagine if we had a transaction spending a decrementing amount in an output, what's to stop that transaction just being repeated and debiting the amount again? Having atomic outputs means you don't need to worry about things like serial numbers, which alternate systems like Ethereum and NXT do, due to their lack of inherent replay protection. </p>

<p>There's additionally no purpose in stating the fee if it can be inferred, and doing so saves space in the transaction. </p>

CC BY-SA 3.0
2015-06-24T22:25:40.820Z
`Transaction outputs only have two states, spent and unspent`, I understand that. I don't understand the reason for designing the protocol that way. Why was this system chosen?
Akhil F
CC BY-SA 3.0
2015-06-25T07:15:53.467Z
@Bitcoin: [Comments are only meant for clarification and minor addendums](http://bitcoin.stackexchange.com/help/privileges/comment), please rather edit the answer to put additional information there. :)
Murch
CC BY-SA 3.0
2015-06-24T22:00:40.693Z
2015-06-25T20:16:14.833Z
2015-06-25T20:16:14.833Z
Claris
<p>I've looked into this before, and I've never been able to find an explicit rationale from Satoshi, but there are a couple of possible reasons.</p>
<h3>For: Simplifies SPV verification</h3>
<p>Imagine that rather than using the spent/unspent model, you track the balance of each address. You get a zero-confirmation transaction that pays to you from an address.</p>
<p>Now, to figure out what the balance of this address is, you need to get all of the deposits and withdrawals from it. If you miss one, you calculate the wrong balance.</p>
<p>You could fix that by forcing each transaction from an address to reference the last transaction by hash, but that eliminates an important property of Bitcoin - multiple deposits and withdrawals to and from the same address can be processed at the same time, without coordination between them.</p>
<h3>For: Improves transaction privacy in theory</h3>
<p>The change output (which you referenced as '8 BTC goes to Alice') is sent to an entirely new address, and in theory it is not possible to figure out which output is the change output. In practice, the real output is usually a nice round number, and the change output is something like 0.00019841.</p>
<h3>Against: Makes increasing the fee really complicated</h3>
<p>If you've used Bitcoin for long enough, you've probably run into a situation where someone sent you some Bitcoins, but didn't attach a fee.</p>
<p>If the change output were explicitly marked, the sender could just resend the transaction with a slightly smaller change output, and a slightly larger fee. Miners would know that they could safely accept the new transaction into their memory pool without helping anyone commit fraud. Then, we wouldn't need stuff like replace-by-fee or child-pays-for-parent.</p>
<h3>Against: Makes the UTXO set much larger</h3>
<p>If you have 50 outputs that make up your money, that means that you're taking up 50 times more space than you would if you had a single balance.</p>
<p>TL;DR: It could have been done differently, and there are some reasonably compelling arguments, but it's impossible to change now.</p>

CC BY-SA 3.0
2015-06-25T02:16:37.740Z
You should probably point out that concepts like the UTXO database didn't even exist up until Bitcoin Core 0.8, it confuses a lot of people when they go and read up about "pruning" and wonder why the system we use today seems completely foreign.
Claris
CC BY-SA 3.0
2015-06-25T02:23:34.733Z
@Bitcoin They didn't exist because the idea was that the average person would use an SPV wallet. The idea that the average consumer or merchant should run a full node is a relatively recent invention.
Nick ODell
CC BY-SA 3.0
2015-06-25T02:28:35.673Z
The UTXO didn't exist because it hadn't been written yet, instead the client used an unwieldy and poorly scaling BerkeleyDB database. The current implementations of SPV are atrocious from a scalability and privacy view, so it's pretty irresponsible to go suggesting them to anyone.
Claris
CC BY-SA 3.0
2015-06-25T17:01:44.987Z
@Bitcoin Maybe I should rephrase: the idea of having a database of transactions and marking them spent and unspent existed, but it wasn't considered important to optimize the size of the unspent output set, because you can't serve SPV clients with just a UTXO database. WRT to scalability and privacy... this is probably getting offtopic. Shall we take this discussion to Bitcoin Lounge?
Nick ODell
CC BY-SA 3.0
2015-06-27T22:24:26.787Z
"Against: Makes the UTXO set much larger" argument is only valid assuming that everyone uses only one address. Which means extremely bad privacy.
Jannes
CC BY-SA 3.0
2015-06-27T23:39:54.937Z
@Jannes: possibly, but I'm not convinced that it's particularly difficult to link sets of transactions together by who sent them. And there are many circumstances where people use the same address repeatedly anyway, despite it costing just as much in terms of space in the current system.
Nick ODell
CC BY-SA 3.0
2015-06-25T00:48:51.810Z
2015-06-25T00:48:51.810Z
2020-06-16T11:10:03.350Z
Nick ODell
<p>Imagine Alice owns 10 BTC and wants to send 1 BTC to bob, with a 1 BTC miners fee.</p>

<p>In the blockchain, the transaction is recorded as "Alice spent 10 bitcoins, 1 goes to Bob, 1 goes to the miner, and 8 goes to Alice".</p>

<p>That seems rather unintuitive. Why not just record the payment and miners fee explicitly?</p>

<protocol><utxo>
Why must UTXO be completely consumed?
Akhil F
# Why must UTXO be completely consumed?

(Asked by: username_0 on 2015-06-24)

Imagine Alice owns 10 BTC and wants to send 1 BTC to bob, with a 1 BTC miners fee.

In the blockchain, the transaction is recorded as "Alice spent 10 bitcoins, 1 goes to Bob, 1 goes to the miner, and 8 goes to Alice".

That seems rather unintuitive. Why not just record the payment and miners fee explicitly?

**Tags:** protocol, utxo


---

## 2 answers

### Answer by username_3 on 2015-06-25. Score: 6 | Accepted answer

I've looked into this before, and I've never been able to find an explicit rationale from Satoshi, but there are a couple of possible reasons.

### For: Simplifies SPV verification

Imagine that rather than using the spent/unspent model, you track the balance of each address. You get a zero-confirmation transaction that pays to you from an address.

Now, to figure out what the balance of this address is, you need to get all of the deposits and withdrawals from it. If you miss one, you calculate the wrong balance.

You could fix that by forcing each transaction from an address to reference the last transaction by hash, but that eliminates an important property of Bitcoin - multiple deposits and withdrawals to and from the same address can be processed at the same time, without coordination between them.

### For: Improves transaction privacy in theory

The change output (which you referenced as '8 BTC goes to Alice') is sent to an entirely new address, and in theory it is not possible to figure out which output is the change output. In practice, the real output is usually a nice round number, and the change output is something like 0.00019841.

### Against: Makes increasing the fee really complicated

If you've used Bitcoin for long enough, you've probably run into a situation where someone sent you some Bitcoins, but didn't attach a fee.

If the change output were explicitly marked, the sender could just resend the transaction with a slightly smaller change output, and a slightly larger fee. Miners would know that they could safely accept the new transaction into their memory pool without helping anyone commit fraud. Then, we wouldn't need stuff like replace-by-fee or child-pays-for-parent.

### Against: Makes the UTXO set much larger

If you have 50 outputs that make up your money, that means that you're taking up 50 times more space than you would if you had a single balance.

TL;DR: It could have been done differently, and there are some reasonably compelling arguments, but it's impossible to change now.

> **Comments:**
> **username_1**: You should probably point out that concepts like the UTXO database didn't even exist up until Bitcoin Core 0.8, it confuses a lot of people when they go and read up about "pruning" and wonder why the system we use today seems completely foreign.  
> **username_3**: @Bitcoin They didn't exist because the idea was that the average person would use an SPV wallet. The idea that the average consumer or merchant should run a full node is a relatively recent invention.  
> **username_1**: The UTXO didn't exist because it hadn't been written yet, instead the client used an unwieldy and poorly scaling BerkeleyDB database. The current implementations of SPV are atrocious from a scalability and privacy view, so it's pretty irresponsible to go suggesting them to anyone.  
> **username_3**: @Bitcoin Maybe I should rephrase: the idea of having a database of transactions and marking them spent and unspent existed, but it wasn't considered important to optimize the size of the unspent output set, because you can't serve SPV clients with just a UTXO database. WRT to scalability and privacy... this is probably getting offtopic. Shall we take this discussion to Bitcoin Lounge?  
> **username_4**: "Against: Makes the UTXO set much larger" argument is only valid assuming that everyone uses only one address. Which means extremely bad privacy.  
> **username_3**: @username_4: possibly, but I'm not convinced that it's particularly difficult to link sets of transactions together by who sent them. And there are many circumstances where people use the same address repeatedly anyway, despite it costing just as much in terms of space in the current system.  

---

### Answer by username_1 on 2015-06-24. Score: 3

Transaction outputs only have two states, spent and unspent, so spending part of one is not possible without the creation of another. With a boolean spent/unspent there is no state to have to store and recall, which allows for simpler states in wallets and makes scaling away from the block chain significantly easier. Imagine if we had a transaction spending a decrementing amount in an output, what's to stop that transaction just being repeated and debiting the amount again? Having atomic outputs means you don't need to worry about things like serial numbers, which alternate systems like Ethereum and NXT do, due to their lack of inherent replay protection.

There's additionally no purpose in stating the fee if it can be inferred, and doing so saves space in the transaction.

> **Comments:**
> **username_0**: `Transaction outputs only have two states, spent and unspent`, I understand that. I don't understand the reason for designing the protocol that way. Why was this system chosen?  
> **username_2**: @Bitcoin: [Comments are only meant for clarification and minor addendums](http://bitcoin.stackexchange.com/help/privileges/comment), please rather edit the answer to put additional information there. :)  

---

