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
⇒ 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.
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.
Labels
Wallet