CoinChooser is prone to create dust

[SomberNight]

The default (and currently only) coin selection policy is unlikely to spend small value coins.

This is due to strip_unneeded:

electrum/electrum/coinchooser.py

Lines 81 to 88 in 75e30dd

	def strip_unneeded(bkts, sufficient_funds):
	'''Remove buckets that are unnecessary in achieving the spend amount'''
	bkts = sorted(bkts, key = lambda bkt: bkt.value)
	for i in range(len(bkts)):
	if not sufficient_funds(bkts[i + 1:]):
	return bkts[i:]
	# none of the buckets are needed
	return []

There are (at least) three things to optimise for in a coin selection policy:

1. user's privacy
2. fee cost to the user
3. health of network (e.g. number of UTXOs)

This behaviour is good for the user's privacy in most cases, as selecting a few large value inputs links together fewer coins than selecting many small value inputs.
It is however bad for the network (there will be more UTXOs overall). Further, if feerates rise such that the effective value of the UTXO becomes negative, it will never be spent, making the pollution permanent.

---

We could have another coin selection policy which consolidates UTXOs. One nice but complex idea would be to monitor historical fee levels. During local minimums it's better to spend many small value inputs; and if fees are high, it's better to spend few high value ones. This would also be cheaper for the user.

[kyuupichan]

@SomberNight really, #3 is trivial and should be ignored

[Transisto]

We're having the same issue, a wallet with a forever increasing amount of small change.

Similar to "Enable output value rounding" Would it be a good idea to have a feature that find output that match the sent amount to more or less 1000 sat, (average to being fair)
and one that sends 0 to 1000 sat more, (Sender always pay the price)

[SomberNight]

Latest release should create really small change with lower probability than when this issue was opened, see e.g. e864fa5

electrum/RELEASE-NOTES

Lines 20 to 24 in 8c1adc2

	* CoinChooser improvements:
	- more likely to construct txs without change (when possible)
	- less likely to construct txs with really small change (e864fa5)
	- will now only spend negative effective value coins when
	beneficial for privacy (cb69aa8)

@Transisto could you please detail how you are using Electrum somewhat? Over what time and after roughly how many txns created do you now have a lot of small change outputs? How many is a lot; what kind of UTXO distribution do you have? During this time, have you used a version that had above commit (3.3.7+)?

[Transisto]

381 UTXO
We're not doing anything special, Bitcoin in bitcoin out, all amounts are supposed to be very random. We let the CoinChooser do it's thing.

Regardless of our use-case I'm pretty sure a setting for what we consider useless precision could help with finding loosely matching UTXO combination and eventually build some transactions without change.

When I read :

more likely to construct txs without change (when possible)

Does that mean it needs perfect to the satoshi matching UTXO to save change on a transactoin?
I can only think a 100-1000 sat of freedom could significantly increase the odds of reducing change generation.

[SomberNight]

Does that mean it needs perfect to the satoshi matching UTXO to save change on a transactoin?
I can only think a 100-1000 sat of freedom could significantly increase the odds of reducing change generation.

I believe the max it is willing to sacrifice is the dust threshold, applied after the privacy rounding.
The dust threshold by default is 546 satoshis.

[Transisto]

That'd be great news, Thanks for your answers.

[Transisto]

546 sat is 4 cents, it's not helping reducing dust and change creation (reduced privacy).

For comparison the dust threshold for Wasabi is 0.0001 (75 cents)