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, that is exactly what the client does. It uses heuristics to do this, solving a subset/sum or knapsack problem.
It uses a multi-pass approach, first trying to use only coins with at least six confirmations. In the next two passes it relaxes these requirements. Within each pass, it tries to minimize the number of transaction outputs claimed and then the ...
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 longterm 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 ...
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.
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 ...
Currently this is not possible with the standard client, other than making separate wallets. There is a patch for coin selection on github, which was very promising. So this feature may make it into a future version.
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 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 ...
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 ...
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.
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 ...
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 ...
Yes, Schnorr signatures are generally slightly smaller than ECDSA signatures.
A comprehensive Coin Selection algorithm should therefore e.g. prefer an input with a Schnorr signature at high fee rates and should prioritize using up non-Schnorr input at lower fee rates to minimize costs.
In combination with the signature aggregation, we may generally see ...
If you spend zero conf transactions, the spend will not confirm until the transaction they source confirms. You can end up with a chain of transactions all waiting for the first one to confirm. Computers are ok with this, but people get confused. :)
Value in Bitcoin is not stored in "balances" but rather in unspent transaction outputs. UTXO behave like cheques, you get one each time you receive money, each is exactly for the amount that was signed over, and you can only spend from it once, in full.
When you create a transaction, your software will search a set of UTXO that can fund your transaction. ...
Depends on the software. You can construct a transaction that spends whichever utxos you want, so yes, you can send someone the exact amount of the sum of dust transactions. As for the transaction fee, the network may or may not relay, but even there, you may be able to get a friendly miner to mine it.
If you send 2.5 BTC to one address and 0.5 BTC to another wallet, that is a transaction with two recipients. Change addresses are new addresses in the same wallet.
If the 3BTC UTXO were selected, there would be no reason for the 2BTC UTXO to move. If you want to move all your money to the new wallet, send 2.5BTC to the recipient and the remaining money to ...