0$ bitcoind --version | head -n1
1Bitcoin Core Daemon version v0.18.0.0-gentoo
2
3$ bitcoin-cli estimatesmartfee 288 ECONOMICAL
4{
5 "feerate": 0.00001015,
6 "blocks": 288
7}
8
9$ bitcoin-cli sendtoaddress bc1… ##amount## '' '' true true 288 ECONOMICAL
1037############################################################3e
11
12$ bitcoin-cli gettransaction 37…3e | fgrep fee | head -n1
13 "fee": -0.00007924,
The redacted ##amount## above was the exact amount of a single unspent output in my wallet (shown by listunspent). The resulting transaction (37…3e) was 191 bytes in length (virtual size of 110 vbytes or 437 weight units — whatever that means).
So estimatesmartfee told me I should have paid a fee of 1.015 sat/byte for confirmation in 288 blocks, but then sendtoaddress went ahead and paid 41.487 sat/byte. Not surprisingly, the transaction confirmed in the very next block. I was aiming for it to confirm closer to 288 blocks later, to save on fees.
This is not the first time this has happened to me. My usual routine is that I check the fee needed for a given confirmation target with estimatesmartfee, observe that the fee is reasonable, then specify the same confirmation target to sendtoaddress. In this case and others, I end up paying an exorbitant fee for an immediate confirmation.
I am not certain whether this behavior always occurs with subtractfeefromamount=true or whether it ever occurs with subtractfeefromamount=false. I do know that I have almost never had BitcoinD choose a fee rate that has resulted in a confirmation time anywhere close to as long as I requested.
