I couldn't find the results of the Coin Selection written out anywhere, and just finished piecing it together from the code. It works as David mentioned, but here are more details.
The Coin Selection Algorithm logic to transfer Target amount
If any of your UTXO² matches the Target¹ it will be used.
If the "sum of all your UTXO smaller than the Target" ...
Yes! The trick is to count each input with its effective value rather than its nominal value.
Transactions are composed of three parts: the overhead, the inputs and the outputs.
The size of the output scripts is determined by the recipient addresses, so their size is given by the transaction instructions. We do not know whether we will need a ...
From the "Yet another Coin Control Release [CLOSED]" BitcoinTalk thread:
What is coin control?
When you send bitcoins to someone else, the bitcoin client chooses kinda randomly which of your addresses will send the coins. With coin control you can exactly choose, which of your addresses will be the sending addresses. And even more specific which of your ...
The challenge for picking a Coin Selection Algorithm is that there are multiple goals to optimize for:
The Coin Selection should reveal as little as possible about the user's wallet contents.
One wants to minimize the current transaction fee, but also the overall long-term transaction fees.
Non-dust change creation
It would be ...
By default, UTXOs are picked randomly.
You mean in Bitcoin Core's wallet? No, they're not picked randomly. There are a number of strategies, but in general the aim is to avoid change if possible, avoid transaction outputs with few confirms if possible, and otherwise create a match close to the amount intended to be sent.
My want to change this behaviour ...
What might be confusing you, and which is a common misconception, is that the addresses themselves somehow "hold" the bitcoin balances, and gain and lose the coins via transactions. In fact all the blockchain does is link up previous outputs to new inputs, and the keys make sure only the correct person is allowed to send the coins.
Your balance is just the ...
The inputs are chosen by the function SelectCoins() in CreateTransaction() and then added one by one (without shuffling) to the transaction.
The order is defined by the coin selection (CWallet::SelectCoinsMinConf) which does a random shuffle of the potential useful inputs and a stochastic approximation.
Mind also that Bitcoin-Core's coin selection could be ...
Bitcoin Core doesn't use an oldest-first selection but a more complex solver, it will probably end up spending outputs you don't want to in this particular case. You can do manual selection of the outputs you want to spend using the Coin Control section of the advanced GUI, which will let you ignore the dust if you don't want to spend it.
Kind of, but coin selection is hard in general. The idea is that inputs pay for themselves. It is easy to compute how much in fees you will need to pay for an input at a given fee rate. So when you do coin selection, instead of selecting on the actual value of the input, you use the value of the input minus the fees it will pay. This is known as the ...
Transactions explicitly refer to which UTXOs they are spending.
You can construct a transaction which only spends one of the two 5-BTC UTXOs, and sends 2 BTC to the destination and 3 BTC to a (possibly new) address of yourself.
You can also construct a transaction which spends both, and sends 8 BTC back to yourself. Or it could have multiple outputs that ...
Bitcoin Core will happily spend RBF marked inputs it doesn't avoid them much less prohibit them.
Perhaps you're being confused by the fact that it will not spend an unconfirmed input created by a third party? Or maybe you have spendzeroconfchange set off or only have long-chain unspents?
There are a lot of things that need to be considered when selecting coins. Just covering the amount that you want to send is not enough, you have not considered the transaction fees that you will be paying for your transaction. So even though you have UTXOs of 0.1 BTC in value, using just one of those means that you will not have enough value in the ...
Bitcoin Core uses a Branch and Bound algorithm to search for an input set that exactly matches the send request. To that end, it will deterministically search the combination space of all of its available utxos and pick the set that is the most efficient if there are multiple solutions. The Branch and Bound algorithm is briefly described in the sourcecode ...
Currently, best practices are to receive coins to an address only once - Any reasonably new wallet will generate a new receiving address for you if the previously displayed one has already received coins.
However, there are scenarios where an address might receive coins multiple times, such as being a saved address on an exchange, stored with an automatic ...
Segwit corrects this incentive mismatch.
Segwit only improves the ratio, but outputs are still cheaper than inputs even with segwit.
As sr-gi mentioned in his answer, the Branch and Bound algorithm was recently merged to the Bitcoin Core master branch.
The Branch and Bound algorithm searches the complete combination space of a wallet's UTXO pool to find ...
A transaction input means that the previous output it is spending can be removed from the expensive UTXO set. To incentivize making txin's (and hence reducing the UTXO size), Segregated witness includes a change to count the size of transaction input scripts as 1/4 the number of bytes that it actually consumes.
Transactions typically compete for block ...
Because Txouts are about 1/4th the size of TxIns, since signatures are that much bigger than a simple hash.
This means that in the old situation it was cheaper to split coins (increasing UTXO set size and creating more dust) than to merge them (decreasing UTXO set size).
With this discount, the playing field is leveled so that when the wallet has a choice, ...
Witnesses do not need to be stored once they have been verified and can be discarded. This effectively reduces the size of the UTXO. The discount is supposed to account for the reduced storage requirements and to encourage users to switch to segwit, benefiting the network as a whole.
Electrum appears to have two Coin Selection policies that users can select from.
selects oldest first
prunes any unneeded inputs starting from the smallest
randomly selects UTXO until sufficient
prunes any unneeded inputs starting from the smallest
attempts to create a change within 0.75 and 1.33 ...
Great question, I've always wondered this too. But im pretty sure that Electrum, by default, will send your oldest unspent outputs first. (Sorry if example is a little repetitive)
E.g. If you recieved 0.4 on address A 3 days ago, 0.2 on address B 2 days ago and 0.1 in address A again 1 day ago, it would send 0.4 from address A, then 0.2 from address B, then ...
Do the instructions to not reuse an address include change? That is, should I generate a new key pair for any transaction that needs to receive change, and then manually specify my change be sent to the newly generated address?
Wallet software will do this automatically for you. Whenever change is created, the wallet will construct a new keypair, compute ...
This occurs because Bitcoin Core's coin selection algorithm tries to have a minimum change of 0.01 BTC. Fees are subtracted from the change output so the result is that the change output has a lower value, but before fees, it will try to for the change output to be at least 0.01 BTC.
As we can see in your transaction, the change before fees is approximately ...
In this particular case, it is because Bitcoin Core prefers to make transactions which do not create change over anything else. Notice how this transaction does not have any change. If the Branch and Bound exact matching algorithm finds a solution, it is always used, regardless of other "optimality" as it considers "no change" to be an ...
When making a payment, Bitcoin Core will automatically pick an input set to fund the transaction. The Coin Control feature allows the user to perform the input selection manually instead. Explicitly selecting the input set can boost privacy by preventing undesired address linkage and allows simple UTXO management tasks.
Please don't use bitcoin cores accounting system anymore (especially for new projects). It has been deprecated (and might be removed in near future).
A way of solving your issue would be by calling getaddressesbyaccount (get addresses of a specific account) and then use listunspent with these addresses.
Then you could create your own coin selection and use ...
See these lines:
// We do not move dust-change to fees, because the sender would end up paying more than requested.
// This would be against the purpose of the all-inclusive feature.
// So instead we raise the change and deduct from the recipient.
if (nSubtractFeeFromAmount > 0 && newTxOut.IsDust(::minRelayTxFee))
CAmount nDust = newTxOut....
Many wallet implementations prefer spending confirmed inputs over unconfirmed inputs. There are multiple reasons for this preference:
Bitcoin Core (and perhaps other software as well) does not propagate chains of unconfirmed transactions beyond a certain depth. If you continuously reuse unconfirmed UTXOs, eventually your transactions will not be seen on the ...
It appears that Bitcoin Wallet for Android uses the DefaultCoinSelector from bitcoinj.
The DefaultCoinSelector sorts the available UTXO by diminishing age and value:
value [satoshi] * age [confirmations]
Should two UTXO compare as equal, larger value is preferred.
The CoinSelection then picks from the front until the target is reached.
Still trying to ...