inconsistent fee calculation

[03:20:09] <kuzetsa> there's STILL a bug where bitcoin-qt / bitcoind likes to claim "blah blah not enough after sending the 0.0???" fee and then when the fee is actually applied, it uses a different value
[03:23:07] <kuzetsa> SendCoinsDialog::on_sendButton_clicked() ... on the line with tr("The total exceeds your balance when the %1 transaction fee is included."). it's being passed a different value than the actual fee that is used
[04:41:03] <kuzetsa> so I've been trying to ask about this bug for nearly a year now... I just tried again about an hour ago or something
[04:41:15] <kuzetsa> the value in these two lines of code (for the fee does not match:
[04:42:39] <kuzetsa> tr("This transaction is over the size limit. You can still send it for a fee of %1, which goes to the nodes that process your transaction and helps to support the network. Do you want to pay the fee?").arg(BitcoinUnits::formatWithUnit(BitcoinUnits::BTC, nFeeRequired));
[04:42:43] <kuzetsa> tr("The total exceeds your balance when the %1 transaction fee is included.").
[04:44:18] <kuzetsa> one was in sendcoinsdialog, the other was in the bitcoingui.cpp file
[04:45:32] <kuzetsa> they appear to be using an inconsistent method to calculate the fee ammount to use and it's really annoying when you're trying to sweep your wallet (roll all the inputs into a single, larger transaction ID so you can better predict your fees at a later date)
[04:46:12] <kuzetsa> warren: the two lines in question (one from sendcoinsdialog, the other was in the bitcoingui.cpp)
[04:46:54] <kuzetsa> one of the lines in the bitcoin-qt gui source code calculates the fee one way, the other from a different file of the source uses a different (inconsistent) method

Hmmm I really wish bitcoin-qt let me view the raw (technically, the output from "decode raw transaction" would be more helpful) transactions before I get any vague popups. Knowing what exactly is happening at the moment I click send / which inputs were being used...

Like basically, my problem might've been something like "different number of inputs being used after subtracting the fee" so possibly same behavior observed with this issue on github:

https://github.com/bitcoin/bitcoin/issues/1570

Quote from: gmaxwell

By lowering it more than you needed to you left an input out, making the transaction smaller... thus needing less fee. I don't see any way of solving that directly.

What I think would help would be options to "take any fee out of the amount being sent" which would remove that problem since the coin selection wouldn't change, and would do exactly what you wanted for the 'send all my coins case'. Also, an option to "round sent amount up, up to X btc", useful when sending to another account of yours, would also tend to reduce fees fairly considerably... but I don't know how UI for that stuff could be done in a non-confusing way.

I'm still helpless to debug this / tired of having no way of knowing what's happening when I get this glitch

... Why is there still no way using RPC / API or the provided bitcoin-qt interface to see what all inputs are being used and what the size is for a transaction before you send it?

We really need "coin control" or at least being able to tell which inputs are being spent and/or what the transaction size is, and we need it like last year Sad

Having more visibility / discoverability for "how much kilobyte size is in a transaction" will likely result in more awareness of what the fee structure is, and what the spending / transaction / usage behavior is doing to the network overall. Bitcoin users will likely tend to create smaller-kb sized transaction to reduce or avoid fees, and in doing so, create less blockchain bloat...

The reason I do wallet sweeps (spending smaller inputs, rolling them together into a larger payment to myself) from time to time... in doing so, it means that I'm getting rid of unspent dust / small inputs so that at a later date I won't need to think about unpredictable transaction size / fees as much (occasionally I've needed to spend most of my wallet, only to realize that so many of the inputs were dust / small, the resulting transaction size ended up resulting in a fee which made me unable to afford sending the amount of bitcoin I thought I had available in my wallet. This is something I prefer to avoid.)