Coupling MIN_CHANGE with the minimum relay fee (and thus dust) turns out to fix #6522.
Assuming that a user should be able to send a small amount even though their wallet consists of mostly small/dust inputs, I get
<img src="https://upload.wikimedia.org/math/5/e/a/5eaa9803b32f3f69f5489eae256545cb.png">
⇒ MIN_CHANGE = ((DEFAULT_MIN_RELAY_TX_FEE/1000.) * MAX_STANDARD_TX_SIZE / COIN) = 0.001
NACK I'm against any such hardcoding changes.
One time, it can happen that 0.001 BTC is half a million of dollars. Or half a penny. We should not hardcode such numbers.
@paveljanik I fail to see how my diff makes it any worse.
Still, I agree that the coupling should be done explicitly in the code but on the other hand it seems there is substantial refactoring of the policy code going on right now. So first, I'd like to make sure this is the right direction.
I think the right solution is replacing this variable with one that computes it dynamically from the relay feerate.
1726 | + // filled with small inputs: Small change avoidance would otherwise add 1727 | + // many unspents, such that the transaction exceeds the maximum allowed 1728 | + // size. 1729 | + // However, creating change too small would instead fragment the user's 1730 | + // wallet into small unspents over time. 1731 | + return ::minRelayTxFee.GetFee(MAX_STANDARD_TX_SIZE);
I think that using MAX_STANDARD_TX_SIZE is way too large (it would be around 1 mBTC on my node).
The choice here is whether to add change, or instead just turn it into fee immediately. Turning it into change adds an output (34 bytes) and then later spending that change adds an input (144 bytes), so as long as the fee we would pay for those 178 bytes is less than the amount we would turn into change, it is worth it. You probably want a small constant factor (at least 3, like the dust rule itself uses) above that number, though.
Coin selection needs a complete rework for 0.14 anyway. Closing for now.