|
|
|
@ -261,9 +261,6 @@ like currency notes, cannot be divided. If you purchase a $5 US dollar
|
|
|
|
|
item in a store but use a $20 dollar bill to pay for the item, you
|
|
|
|
|
expect to receive $15 dollars in change. The same concept applies to
|
|
|
|
|
bitcoin transaction inputs. If you purchased an item that costs 5
|
|
|
|
|
|
|
|
|
|
Different wallets may use different strategies when aggregating inputs
|
|
|
|
|
to make a payment requested by the user. They might aggregate many small
|
|
|
|
|
bitcoins but only had an input worth 20 bitcoins to use, you would send one
|
|
|
|
|
output of 5 bitcoins to the store owner and one output of 15 bitcoins back
|
|
|
|
|
to yourself as change (not counting your transaction fee).
|
|
|
|
@ -280,6 +277,13 @@ otherwise look identical, preventing any third party from determining
|
|
|
|
|
which outputs are change and which are payments. However, for
|
|
|
|
|
illustration purposes, we've added shading to the change outputs in
|
|
|
|
|
<<transaction-chain>>.
|
|
|
|
|
|
|
|
|
|
==== Coin selection
|
|
|
|
|
|
|
|
|
|
Different wallets use different strategies when choosing which
|
|
|
|
|
inputs to use to a payment, called _coin selection_.
|
|
|
|
|
|
|
|
|
|
They might aggregate many small
|
|
|
|
|
inputs, or use one that is equal to or larger than the desired payment.
|
|
|
|
|
Unless the wallet can aggregate inputs in such a way to exactly match
|
|
|
|
|
the desired payment plus transaction fees, the wallet will need to
|
|
|
|
|