Join and earn Bitcoin Cash for participation

Differencing between different types of 0-conf double-spends

8 153 boost
Avatar for noise
Written by   100
1 month ago

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).

4
$ 2.05
$ 0.50 from @Read.Cash
$ 0.50 from @JonathanSilverblood
$ 0.50 from @saddit42
+ 2
Avatar for noise
Written by   100
1 month ago
Enjoyed this article?  Earn Bitcoin Cash by sharing it! Explain
...and you will also help the author collect more tips.

Comments

The first seen rule is only policy, its not forced, so any miner now is able to include the second transaction and his block would be accepted. One miner with malicious intents, or only by greed or both could choose the second tx and then the probabability of success would depend on the hash power of this type of miners.

$ 0.00
1 month ago

This is amazing info.

$ 0.00
1 month ago

I think your considerations about delayed double-spends are wrong. The first seen rule is only policy, its not forced, so any miner now is able to include the second transaction and his block would be accepted. One miner with malicious intents, or only by greed or both could choose the second tx and then the probabability of success would depend on the hash power of this type of miners. In that scenario Avalanche would be a high improvement because the block of the malicious/greed miner would not be accepted.

I also think that's the most important attack for merchants and the one with most terrible results.

$ 0.00
1 month ago

Seriously I know am not supposed to be asking questions like this but please can you clarify me on what 0_conf double spending means

$ 0.00
1 month ago

Double spending a transaction means you'll use the same money twice. Once to pay the merchant and once to send to yourself. The goal is to trick the merchant into thinking he got money, but he did not.

0-conf means before a transaction has gotten included in the blockchain. This is what allows payments tobe registered in seconds.

More info here:

https://whycryptocurrencies.com/how_do_cryptocurrencies_work.html#copying-a-coin-&-double-spending

$ 0.00
1 month ago

Wow that is really cool. Thanks alot for the explanations. I now understand alot

$ 0.00
1 month ago

There are also reverse respend attacks as described here: https://www.youtube.com/watch?v=TIt96gFh4vw

I think avalanche would also help in that scenario in convincing the miner that accepts non-standard transactions to accept the 2nd seen transaction.

$ 0.00
1 month ago