Add SweepDust RPC Call about bitcoinclassic

[jtoomim]

This sounds like the start of a good idea, but it has the problem of broadcasting information about what public keys are in the wallet. Perhaps this could be done as part of a coinjoin transaction, so that e.g. 100 users could sweep dust out of 1000 addresses and put the change back in 100 addresses? That's more complicated, though.

[ahmedbodi]

Agreed it does, We could make it a config option or a compile time option to enable this RPC command so people are aware of the risks when using it. Or just add it and provide a warning in the help information

[jtoomim]

It might be worth checking dust generation first. Does the existing code avoid generating outputs that are smaller than minrelaytxfee? It might be good to make the code default to rounding up in fees when creating transactions.

In any case, this seems like a post-hardfork issue, so I suggest we don't talk too much about it now.

[dskloet]

What if a charity made a big anyone-can-pay transaction and people have an easy way to donate their dust outputs to it? Reduce the UTXO size for a good cause!

[ahmedbodi]

another good use there :)

[richiela]

As an exchange that has to manage large BTC wallets with 55k+ of dust inputs, this would be a hugely welcomed feature.

Broadcasting public keys is an acceptable risk. You can make sure that outputs are greater than minrelaytxfee by including an input that is, for example, 100x minrelaytxfee and then add a max number of txs, or until a tx is a certain size.

[gladoscc]

CoinJoin requires out of channel communication and organisation and is best suited for an alternate software (e.g. 'joinmarket'). I think the simple proposal of local SweepDust is a net benefit and useful feature.

Long term, the default fee policy can penalise transactions for creating UXTOs (e.g. assume each uxto is 200 kB for the purposes of fee calculations), and reward transactions for destroying UXTOs (e.g. each UXTO destroyed is -200 kB for the purposes of fee calcuations). This would mean typical payments would remain the same (pay 2 inputs, get 2 outputs) while incentivising the network to keep uxto bloat low.

[zander]

Following the consensus that github is not a great forum and we use other platforms for discussions and brainstorming, I'm going to close this idea.