Zero-conf escrow enabled for Bitcoin Cash on LocalCryptos

You asked for it, and we delivered. Starting today, users will be able to complete their Bitcoin Cash (BCH) trades at blistering speed with zero-conf transactions.

One of the key elements that made Local.Bitcoin.com so popular and loved by its users was the ability to complete Bitcoin Cash trades in less than 2 minutes. This was, in part, thanks to the possibility of depositing the BCH in escrow and advancing to the next phase of the trade without having to wait for a confirmation in the blockchain (which usually takes ~10 minutes).

This kind of transactions are known as “zero-conf transactions”, and while they were disabled after the migration to LocalCryptos, many of you have been asking us to re-enable them back.

But what exactly means a transaction is zero-conf, and what are the implications for the trader in general? Moreover, why did LocalCryptos disable it in the first place after the Bitcoin Cash P2P marketplace launched on LocalCryptos, and why are we re-enabling it for small amounts only? In this blog post, we will address these questions so you have a clear view on the matter.

Keep in mind that this article will talk about the implications of zero-conf transactions only for Bitcoin Cash, since we’re enabling this feature only for trades with this cryptocurrency. Other cryptos may be susceptible of the same risks to a greater or lesser extent, but zero-conf transactions for these coins are either unavailable or disabled in LocalCryptos, so you shouldn’t worry about it.

Zero-conf: Speed v. Immutability

First off, let’s expand a bit more on the concept of a zero-conf transaction. Zero-conf means that the transaction has still not received a confirmation in the blockchain, that is, it is still lingering around in some sort of waiting room — known as the ‘mempool’ — pending to be included in a mined block. And once this happens, it will receive a ‘confirmation’. Then, as new blocks are mined and added to the blockchain, the transaction will receive more and more confirmations, further reinforcing its immutability, that is, it is no longer be reversed (barring an unlikely 51% attack event).

In Bitcoin Cash, the average time it takes for a block to be mined and etched in the blockchain (so your transaction gets a confirmation) is 10 minutes — a pretty long time for, say, someone who might just want a cup of coffee in their nearest coffee shop. And since the underlying goal of BCH is to serve as electronic cash, the fact that a customer must wait this long to get what they just bought would make them not very viable payment options, at least for day-to-day purchases.

Now, a merchant who chooses to accept zero-conf transactions would only need for your transaction to be broadcast and appear in the mempool to consider it valid and hand over the product you purchased. This usually takes around 2-5 seconds — much faster than the aforementioned 10 minutes. The buyer leaves satisfied, and the merchant can move on with the next customer. After all, the transaction will eventually be confirmed in the blockchain, right?

But this is where you may wonder: if a zero-conf transaction means that it is still unconfirmed, what could happen during that moment before receiving a confirmation? Is there a way for a sender to “cancel” the pending transaction and walk away with both the coins and the purchased items? The answer, unfortunately, is yes, and that way is called a double-spend attack.

Double-Spend: the phantom menace

A double-spend attack means that someone has spent the same coin in two different transactions. You can picture this as if someone just paid you with a $10 bill, and then he proceeds to pay someone else with that same bill, or even keep it for himself. Crazy, isn’t it?

It’s obvious that you cannot do this with physical currency — you cannot just give two people the exact same $10 bill. But with cryptocurrencies, this is actually a real possibility.

There are several ways someone could pull off a double-spend attack. The most common would be by a race attack. A race attack involves the bad actor sending two transactions with the same coin, at the same time, but with different network fees — with the one meant for the merchant having a lower fee, and the other one (which most likely will be sent to an address of their own) having a higher fee, in hopes that miners will pick the latter over the former and confirm it. And since you cannot spend the same coin twice as per blockchain rules, the transaction that was not confirmed will be deemed invalid and discarded.

The end result: the merchant will be left without the coin and without the product.

Other ways for double-spending could involve:

  • A 51% attack - where the hacker would need to control more than half the hashrate of a cryptocurrency network in order to possibly alter its blockchain and perform double-spend attacks.
  • Finney attacks - which requires a miner to pre-mine a transaction into a block, send a second transaction from the same wallet as the pre-mined transaction and then, broadcast the pre-mined block. If successful, the second transaction — which would be meant for the merchant or victim that accepted it zero-conf — will be invalidated.

Not zero-risk, but pretty close to

Fortunately, the possibilities for any of these attacks happening to you are very, very low. A 51% attack requires having more than half of the miners on your side, which is extremely difficult to achieve for a network with such a high and diversified hashrate like Bitcoin Cash, and the costs of it will outweigh the benefits in almost all the cases. Similarly, a Finney attack requires a very unlikely sequence of events to take place for it to be successful, so it is a very impractical and costly attack as well.

That leaves us with the race attack, which doesn’t require any of the aforementioned conditions, it is much cheaper to execute in comparison and the benefits might actually be appealing enough to attempt it. However, the attack would require the second transaction to be seen by more nodes than the first one in order to get a chance of success, something that is also extremely difficult to achieve given that the first transaction will likely have a head start of at least 1 or 2 seconds, enough for spreading through the network faster and being seen by the majority of the nodes, thus lowering exponentially the chances of winning this race.

In addition, as soon as Bitcoin cash nodes recognize two transactions spending the same coin, they’ll rush to alert each other using the DSproof protocol. This alert will in turn be passed to the merchant, nearly instantaneously, so they can adjust their zero-conf risk tolerance or abort the transaction.

Further, Bitcoin Cash’s larger block capacity and lack of an intense fee market ensures that transactions don’t remain in the mempool for long, with most blocks cleaning out the entire mempool of pending transactions, reducing the time span for a successful race attack.

Although it is true that chances for any of these attacks happening to you are very small, at LocalCryptos we feel it is necessary that you are aware of what you are dealing with, which brings us to…

Implications for a LocalCryptos trader

Now that you know what a zero-conf transaction is and the risks that involves accepting it, there are some implications you need to keep in mind as a LocalCryptos trader exchanging Bitcoin Cash:

  1. The party at risk of a double-spending attack is the buyer, since they will be receiving the cryptos at the end of the trade.
  2. During a zero-conf trade, the “mark as paid” button will be available as soon as the deposit hits the non-custodial escrow, before a block confirmation.
  3. If the buyer prefers to play safe, they can just wait at least 1 confirmation before making the payment.
  4. Zero-conf trades are enabled only for small amounts, since they’re unlikely to be attacked due to how uneconomic it would be.

Why we disabled it, and why we are re-enabling it

The reason why this featured was switched off when migrating the Local.Bitcoin.com marketplace to LocalCryptos was purely out of concern for our users’ security. Even if the risks are lower than that of credit cards, we felt it was still enough to rule it out of our trade formula.

However, many users from the earlier platform had been working with zero-conf transactions ever since the feat was available for them, while not finding themselves in such dire situations a single time. They were used to a swift user experience that was reduced when the migration occurred. We heard your complaints and, after re-visiting the decision and taking some extra safety measures, we agree that the feature should come back.

So there you have it — zero-conf escrows are back for Bitcoin Cash traders, although only for trades valued under ~US$200. Anything above that will have to wait for at least 1 confirmation in the blockchain, depending on the amount of the trade.

Also, whenever a trade is zero-conf enabled, it will be notified to the parties before the trade is initiated, with a reminder after the seller has deposited the BCH in escrow.