Differencing between different types of 0-conf double-spends

I've noticed a disturbing trend in the discussion around 0-conf security, the risk of double-spending them and how pre-consensus would solve them. There's a bunch of hand-waving and people leaving out details in discussions, making us all confused. That's why I'd like to clarify some things.

There are different types of 0-conf double-spends you can attempt, with different types of risks and mitigations. In order to understand this I've categorized 0-conf double spends into three major categories:

• Fast double-spends

• Delayed double-spends

• Miner assisted double-spends

Although variations exist, I think these covers the different types of 0-conf double-spends as they can be derived from these three categories.

Important to remember is that it's impossible to solve 0-conf completely. Even transactions with one or several confirmations can be reversed and double-spent, so the best we can do is increase 0-conf security, but never make them truly safe.

The only thing that matters is if merchants get cheated. It does us no good to try to look at the network and decide how many successful 0-conf double-spends there are. For one these statistics come from a single node that's observing the network, but what's to say that the timestamps that particular node sees are correct? It cannot.

Fast double-spends

A fast double-spend is when you pay a merchant and then very quickly, within seconds, try to double-spend that transaction. There are different ways you can do this, like setting a very low and a very high fee on the transactions or connecting directly to miners and giving them the double-spend, but the main idea is the same; show the merchant one transaction but try to make the network propagate another.

This is something that double-spend proofs help mitigate. The idea is to give the merchant a quick notification that a double-spend, and thus an attempt at fraud, has occurred.

ALERT Scam attempt detected! ALERT

With Avalanche a double-spend can be resolved in 3 seconds or so, and it might look like Avalanche would help prevent fast double-spends. But what actually happens when it does so?

• If a scammer successfully double-spend a merchant, the best you can do is give the same "scam detected" alert, and hope that the merchant takes appropriate action.

• If a scammer tries to double-spend, but is unsuccessful, Avalanche simply gives you the option to ignore the alert.

This is a very marginal benefit. If you catch a shoplifter, you don't send them away and wish them a good day. You call the police and charge them for shoplifting.

Why then would you you choose to ignore a failed double-spend, which is proof of a scam attempt? It doesn't make sense to me.

Therefore Avalanche is not an improvement over double-spend proofs in this case. Storm is also too slow for this case.

0-conf forfeits is a better solution, but it has the drawback of having to commit a larger amount as insurance, which you'd forfeit if you attempt a double-spend.

Delayed double-spends

A delayed double-spend is similar, but instead of double-spending directly you wait until the purchase is completed. Maybe you'll double-spend after you walk out the store.

This is more difficult to pull off, since the risk of a miner already including the transaction in a block increases. It's also more difficult to get your double-spend propagated through the network, as nodes may reject it using the first-seen rule. Of course this depends on node settings, and they're free to ignore this as they please, which is one of the main arguments for pre-consensus.

Avalanche would indeed help here, assuming it's run directly for every transaction. If it's only run when a double-spend is detected, then the merchant doesn't know if the transaction he sees will be confirmed until much later, when the scammer initiates a double-spend.

Other proposals such as weak blocks, or "delta blocks" in the Storm proposal, would be fast enough (< 1 min) to mitigate this scenario. 0-conf forfeits would also be helpful.

Miner assisted double-spends

The final, and arguably most difficult, type of 0-conf double-spend is a miner assisted one. So instead of propagating the double-spend to the network, a miner holds on to the double-spend privately and includes that one in the block instead of the original payment. The scammer might be in collusion with the miner or a miner could setup a "double-spend as a service".

The success rate depends on the total hash-rate of the miner and the only risk for the miner is a slightly increased orphan risk if the miner does this with many transactions.

This is where pre-consensus truly shine.

Storm would heavily discourage miners from doing this, as weak blocks are backed by proof-of-work and use the same incentives that make Bitcoin work in the first place.

Assuming Avalanche is allowed to orphan blocks, miners would be discouraged as they wouldn't want their blocks orphaned. Here again Avalanche would have to be run for every transaction, otherwise we don't know if the transaction included in the block should be orphaned or not. (It's annoying to make these assumptions, but as there's no specification we can only make educated guesses here).