Protection against dust attack utxos

[ManfredKarrer]

There is some discussion regaring some dust attacks where chainanalysis companies send out a lot of dust outputs to addresses with the intention to learn about other addresses of those address owners (coin merge reveal ownership).
See: https://twitter.com/manfred_karrer/status/1111435913744117760
https://twitter.com/manfred_karrer/status/1111707029327015938

One solution to that attack is to isolate those dust outputs. But they still would pollute utxo set and mempool. Better would be to spend them in an aggregated tx in a way that no coin merge happens.

As for paying the miner fee other utxos must be added it would only work in a tx which uses the dust utxos of other users. In Bisq we could send out those signed inputs (signed with sighash ANYONECANPAY) to a service which aggregate the utxos into a tx to some donation address once there are sufficient inputs to be efficient with the miner fee.

The dontation should be a project which is an active counterforce against those surveillance capitalistic companies. The Tor project would be a natural fit.....

The aggegator should run as Tor onion service with a simple HTTP API so that anyone beside Bisq users can use it. The aggregated funds should be small enough to not create incentives that the aggregator steals the funds. There should be some random delays to avoid analysis attempts to map all those users to the same wallet software / platform.

It is important that this service would be used by several wallets. Wasabi and Samurai Wallet would be natural fits, but other like Greenaddress or Electruum should be invited as well.
Only if there are sufficiently broad distribution of that feature the spies cannot assume that all those who gave their dust utxos are Bisq users.

Here is a rough idea how it could be implemented:

• Add radio buttons to preferences where the user can select of he wants to isolate the dust outputs or if he prefers to send it to a aggregator service. Third option would be to use it as normal outputs but we should display a warning popup about the privacy risks if the user choose that option.
• If user has activated the 'dust to aggregator service option' he signs the dust utxo with the ANYONECANPAY sighash and sends the signed input to a dedicated onion service (operated by a Bisq developer). The receiver address need to be defined at that point. The aggregator service will provide that.
• The aggregator service checks the current miner fee and the aggregated input values when receiving new dust utxos and if the balance hits a defined efficienty threshold it creates and broadcasts the tx to the donation address.

Anyone up for imlementing it?

[ManfredKarrer]

For wallets which do not have native Tor support the sending of the dust utxo to the aggregator service is an open problem. A simple solution could be to export the signed inputs to a hex string and paste in a input form at the aggregators service webpage (shoud be accessed over Tor browser). Getting native Tor support would be the better option though....

At least those wallets should offer the option to isolate such utxos (be default activated).

[ManfredKarrer]

Seems there is not much interest and support of other wallets on a more general solution with a service as described above. So we skip that idea for now as it would not make much sense if its only used by Bisq.

After discussion with @oscarguindzberg we decided to implemente following:

• Add non-dust threshold parameter to preferences. If user set it to 545 sat he gets displayed a warning with context info.
• Check in the Bisq coinselector that inputs must be above that non-dust threshold parameter. So dust utxos are not used for any spending tx
• Filter in the balance in the UI those utxos so that they are not included in the available balance.
• In the balance at the emergecny wallet window we do not filter those utxos.
• Optional: Mark graphically txs with a dust output either with a color (red) or an icon (warning with info popup).

[ManfredKarrer]