Prevent fee overpayment when nFeeNeeded decreases in CreateTransaction iterations #9466

1. 
   gmaxwell commented at 9:03 am on January 4, 2017: contributor

   When a pass of CreateTransaction fails to select enough bitcoin to meet the nFeeNeeded the next pass through may select a far smaller collection of inputs. Currently it will continue to use the old fee amount based on the larger set of inputs, which can cause a non-trivial over-payment.

   This may be the cause of the behavior reported here: https://www.reddit.com/r/Bitcoin/comments/5ltw5n/bitcoin_core_v0131_sends_enormously_high_fee/

   Long ago fixing this was tricky due to a catch-22 between signing the transaction and knowing how much fee was required. But after #9465 the whole algorithm will run using a dummy signature, so when there is already a change output fixing up the fee after finding a sufficient transaction should be a matter of a ~2 line change.

2. fanquake added the label TX fees and policy on Jan 4, 2017
3. MarcoFalke added the label Bug on Jan 4, 2017
4. 
   gmaxwell commented at 3:49 pm on January 4, 2017: contributor

   This is fixed by #9404.
5. 
   morcos commented at 6:47 pm on January 4, 2017: member

   @gmaxwell to be clear it’s not completely fixed… it’s just much less likely to happen.
6. 
   RHavar commented at 0:53 am on January 5, 2017: contributor

   Oh nice find! When I was going through my transactions, I noticed that occasionally it was paying absolutely ridiculous fee rates. I had assumed it was a problem with the fee estimation, but I’m guessing I was hit by this.
7. MarcoFalke added this to the milestone 0.14.0 on Jan 6, 2017
8. MarcoFalke added the label Priority High on Jan 6, 2017
9. sipa closed this on Jan 9, 2017

   ---

10. MarcoFalke locked this on Sep 8, 2021

Contributors
gmaxwell morcos RHavar

Labels
Bug TX fees and policy

Milestone
0.14.0