Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Correct issues with dust totaling near threshold #849
A problem was introduced with #518 when a utxo smaller than 10% of the threshold takes the total combined coins above the threshold, or when the total amount of dust is less than 10% above the threshold.
What occurs is two fold. First, the nTotalRewardsValue > nAutoCombineThreshold will break it out of the for loop; but the "safety margin" will split it up into two utxos, one within 10% of the threshold, and then the utxo for the change. When the wallet comes back through on it's dust collection, it can pick up those two utxos and repeat until the fees widdle the two combined transactions fall below the threshold.
If there is another utxo to add in order to get us far enough above the threshold that the 10% reduction is still above the threshold; then we're now good when accounting for the 10% in our check in the for loop. However there is still one other case that slips through. If the total amount being collected falls into the "within 10% of the threshold" situation, and the for loop can't make another pass... we exit the for loop normally, and find our way into the zero fee check. However the zero fee check sees we are over the threshold, but not that the transaction amount will be over the threshold. So we need to account for the 10% there as well, by using the actual amount (vsecSend.second) rather than nTotalRewardsValue to determine if we should continue only if free.