Will the new dust rule 0.8.2 make it trivial to double spend 0-conf?

[apetersson]

lets assume the following scenario:

attacker connects to all miners directly.
constructs transaction with very healthy fee (0.01 btc) and 1 dust input + multiple fat inputs. outputs all back to him.
now he sends those directly to all miners. they may or may not relay it. but they will propably accept it to their memory pool to collect the fee on the next block.

now Mr. Attacker goes and pays at a merchant or digital download / vending machine.
-------
the merchants sees the 0-conf TX and thinks it is ok. but in fact the inputs are conflicting with the 1st transaction.
previously this fact would be known quite fast because the original transaction would have flooded the network already and all merchants would have rejected it instantly. but now, he has no way of knowing that the conflicting transaction is already sitting in all miners memorypools and on the next block he will have a bad surprise!

[1714058708]

1714058708

[1714058708]

1714058708

[1714058708]

1714058708

[1714058708]

1714058708

[1714058708]

1714058708

[gmaxwell]

No change from current behavior: We already have IsStandard and there are an infinitude of transactions which do not qualify as standard already.

[Mike Hearn]

The default code will not accept transactions into the memory pool if it would not relay them. So this is not an issue unless miners change how Bitcoin works en-masse, and yes obviously if all miners deliberately change their behaviour to make double-spending of unconfirmed transactions easier than people will stop relying on them and usage of Bitcoin will go down (along with its value, I'd imagine).

[apetersson]

in my understanding the fee/dust setting will be configurable by users and miners.
so from the outside it is not obvious if a miner will treat a transaction as nonstandard or not.

how exactly is a merchant supposed to find out about a TX that is non-standard to SOME nodes that may be conflicting with his freshly-received transaction? - this question applies to other forms of nonstandard tx as well.

if the transaction is non-standard to ALL nodes the problem is not as severe, because the probability of a miner including it in the next block is within manageable limits.

[Peter Todd]

Considered this scenario:

1) Get Bitcoin address for payment from double-spend vulnerable merchant

2) Broadcast payment, and a double spend, at the same time

3) ~50% of nodes get your payment, %50 get your double-spend, each thinking the other is the double spend

4) If merchant's node gets payment transaction, run with the goods; 50:50 chance you'll have wound up paying for them.


Blockchain.info's shared-send mixer guards against this because they have a huge network of nodes watching the network and can detect double-spends; the solution for your average merchant is to either not accept zero-conf (highly recommended) or get double-spend propagation so nodes propagate the first double-spend they see as well as the initial transaction implemented in the Bitcoin reference client.

tl;dr: Making dust outputs non-standard is just one of a huge variety of ways to pull off a zero-conf double-spend.

[kjj]

This is not a change.  Zero-confirmations means "not confirmed" today, just like it did yesterday.  Confirmations are what make transactions safe.  No confirmations, no safety.

Maybe this will finally wake people up.  People have been operating for too long under the delusion that their wishes for someone to confirm a transaction someday in the future were equivalent to having trillions of hashes already done in the past.

The sooner everyone accepts reality as it is, the better off we'll all be.

[gmaxwell]

in my understanding the fee/dust setting will be configurable by users and miners.

Nonstandardness enforcement has never been consistent.

so from the outside it is not obvious if a miner will treat a transaction as nonstandard or not.

Never has been.

how exactly is a merchant supposed to find out about a TX that is non-standard to SOME nodes that may be conflicting with his freshly-received transaction? - this question applies to other forms of nonstandard tx as well.

By seeing it get confirmations.

[Stephen Gornick]

We already have IsStandard and there are an infinitude of transactions which do not qualify as standard already.

I'ld like to see an entry added to the Double Spending article on the wiki for this category of attack.
 -  - http://en.bitcoin.it/wiki/Double_spending#Attack_vectors

I don't know that each specific tactic needs to be described, but something to the effect of how exploiting differences in the rules between versions (or from custom modifications) introduces an increased attack vector.   What would be a good name for this category?