I have a weird issue that I thought was fixed a few years back with Bitcoin wallet to reduce fees. I guess not, or I am missing something...

My wallet received a transaction for the amount of 0.54530200 BTC, yet when I went and sent 0.51986042 BTC out using bitcoin-cli sendtomany to 16 outputs, the wallet used 856 inputs to send the amount that was available and cleared with at least 400+ confirmations in the first address.

The above TX cost me 0.03600705 BTC to send when it should have cost me a fraction of the amount had it used the address that contained the closest amount to the amount it's sending out...

Bitcoint-cli version 0.19.1

Any ideas what I could be doing wrong or what I could be missing?

  • Does the resulting transaction only have recipient outputs and no change outputs?
    – Andrew Chow
    Dec 8 '20 at 0:37
  • It has 1 change output and 15 recipient outputs. Dec 8 '20 at 0:58
  • Created an issue in GitHub repository for Bitcoin Core: github.com/bitcoin/bitcoin/issues/20598
    – Prayank
    Dec 8 '20 at 9:24
  • Hi Duetschpire, I am wondering how many unspents this wallet roughly had when you were building the transaction.
    – Murch
    Dec 9 '20 at 19:47
  • Nevermind, I'm looking at the issue on Github now.
    – Murch
    Dec 9 '20 at 19:54


I am not sure why coin selection algorithm didn't work or if you manually added some inputs or could have manually added inputs to avoid this. However, you could have still avoided paying more fees.

The transaction had virtual size of 78213 VByte You had used fee rate: 46 sat/vByte

Since this transaction involved lot of inputs and bigger size, you could have used a lower fee rate when mempool had less than 5 MB of transactions.

Assuming you had used 5 sat/vByte fee rate for this transaction, the total fees paid for the transaction would have been 0.0039 BTC which is 90% less than the fees you paid.

Looking at the mempool history, the transaction would have confirmed yesterday:


UTXO consolidation is normally done when mempool is clear or you have lots of time so that 1-5 sat/vByte can be used for such transactions.

Consolidation of 4 Million UTXOs at Xapo: https://bitcoinops.org/en/xapo-utxo-consolidation/

  • 1
    Thanks for the detailed explanation, the answer to your questions is: 1- This is scripted into the site, we send to 100s of addresses a day, we never manually select inputs. 2- We calculate the sat/byte on a 20h confirmation window depending on the mempool size. These tx are our customers' and waiting days for a tx to confirm is not ideal. Dec 8 '20 at 5:01
  • Do you have a test website where we can try to reproduce this issue using testnet bitcoin? Maybe debug.log file might also have some useful information. I was assuming this is a personal transaction, in future I am not sure how will people manage fees if nodes do not allow fee rate less than 1 sat/vByte. Some businesses have started integrating layer 2 solutions like LN and Liquid for quick confirmation and less fees. Also this: i.imgur.com/aD2CVo4.png
    – Prayank
    Dec 8 '20 at 5:31
  • While this is not something that happens often, it's also not uncommon. The site does not receive large transactions, but when it does this happens. I have a feeling that coin control favours more inputs with less combined "change" over less inputs with more combined change. In this case the change address (3BF5VhQgnabWMsB8QhVrBoWD6is2XMKuQs) received 0.00008051 BTC, where the input with the closest full amount amount would have resulted in (0.02544158 - tx fee) in change. Dec 8 '20 at 5:48
  • I will experiment and try few things on my local machine using bitcoin core v 0.20.0 (testnet) today. Will share the details here and also create an issue in GitHub repository if required: github.com/bitcoin/bitcoin/issues
    – Prayank
    Dec 8 '20 at 5:54
  • @Duetschpire I was able to reproduce the issue and think we can improve this. Let me document everything and see what can be changes in coin selection algorithm to fix this issue.
    – Prayank
    Dec 8 '20 at 8:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.