Core should never source uneconomical outputs #11278

I've noticed a big uptick in the last couple weeks of transactions I believe are created for the purpose of tracking.

A recent example is this: https://blockchain.info/tx/ea4491d4335572e3b4aa37d5760dcc1aa718832442cd435c804c2609b12ba8ef

Sending 649 satoshis to my address. In this particular case it's a change-address of mine. I suspect the intention of the transaction is to find out information on tracking service is interested in information about the transaction "ae0d2736eacd78d97f8328cac4e4b9a8c7517b01c9df8c9a4628ac9cc21e25b9" or "d75534aff5b21aa279a6410594661bfd0ceb5711df005827f25ddd97510e25da" and hoping I spend-link their dust.

I believe there should be a comprehensive solution to prevent this "forcible address reuse" problem (and would be happy to throw a bitcoin or so to sponsoring its development) but a quick-fix to making this harder is for core to simply stop ever spending uneconomical outputs.

Pros:

• Makes tracking significantly more expensive to do reliably (and thus stopping a lot of it)
• Makes sure users don't lose money when sending

Cons:

• Not great for bitcoins utxo :'(

I'd say there should be a 'fungibility' tag here too..

But probably the most convincing reason this is a good idea is the giant attack vector it closes. Currently if you know someone's bitcoin address you can send them spam at incredibly cheap prices. An output is ~34 bytes so using a low fee rate (since you don't care it confirms) that's about 34 satoshis in fees and say you burn another 650 satoshis if you want to make your transaction standard (which you don't even necessarily have to do). Let's round up and call it 700 satoshis per output.

Right now there's not much fee pressure, so you can send relatively cheaply at 136 satoshi per byte. Sourcing one of these unspent is around 148 bytes so that's going to run you 20128 satoshis to spend!

So deducting the 650 satoshis they sent you, this attack costs the bitcoin-core-user about 28x what it costs the attacker! And the situation can (and often is) worse with fee rates double that.

And it's not even theoretical. I'm aware of at least one case of one service that was using core and spammed in this manner, and ended up burning through >1 bitcoin in transaction fees before they realized what was wrong.

With regard to the privacy issue: I think as long as it is economic to spend a tracking output, the default behaviour should be to spend it.

Is it in any way possible to make it cost more for the attacker than the recipient of this attack?

@rebroad Not without very fundamental changes to the protocol. Spending outputs just happens to take more space than creating them.

In general, this issue should be fixed by changes like #17331 I believe.

The BnB and SRD algorithms use only positive effective value outputs. The only algorithm that may spend dust outputs is Knapsack. Since we now use the waste metric to determine which of the 3 solutions to use, uneconomical outputs should rarely be spent now.