Disposing of "dust attack" UTXOs

The main reason we should avoid adding mechanics that would reveal public keys prematurely is there will be significant urgency to move funds with exposed keys to a PQC (or even non-exposed) address if a CRQC ever materializes, and it seems counter-productive to add to this rush unnecessarily. Granted, this would really only matter in certain scenarios - specifically those where only “slow-clock” CRQCs are available, where the time required to break a key would be on the order of a few days to a couple of weeks, meaning there is little danger of a key being broken in the window between broadcast and mining.

There is another and (in my experience) more common reason to dust an existing UTXO: attempting to trick users into sending funds to an attacker’s address, specifically by leveraging weaknesses in certain UIs combined with poor user practices of copying addresses from previous transactions. Such transactions will generally be sent from or have additional outputs to intermediate addresses that have been brute-forced to be superficially similar to the target address, say by starting and ending with the same four characters. These attacks will inevitably target addresses holding unspent UTXOs.

You may not want to do that in certain situations, since to the potential “taint” can negatively affect KYC/AML source-of-funds type processes, especially since those are increasingly handled by AI. Whenever that is a concern, you would want to leave the dust UTXO behind and dispose of it in a separate transaction, just to avoid the headache of trying to explain to a machine that someone you don’t know sent it to you.

2 Likes