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 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 ...
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 ...
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.
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 ...
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 ...
But at some point the sum of the amounts of the ouputs will grow bigger than the one input I added at first and I'll need to add another input. If I have relatively big ouputs to spend this is probably ok, but if I only have small outputs and/or I'm adding relatively big amounts in the outputs at some point adding one more output could need to add one or ...
Yes, Schnorr signatures are generally slightly smaller than ECDSA signatures. This is due to their more efficient encoding that takes only 64 bytes instead of 72 bytes.
A comprehensive Coin Selection algorithm should therefore e.g. prefer an input with a Schnorr signature at high feerates and should prioritize using up non-Schnorr inputs at lower feerates to ...
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. ...