Mitigating Risk - How Exchanges Can Accept Zero Conf Transactions

Josh Ellithorpe - October 16th, 2018

@zquestz

A quick overview...

• What is zero-conf?
• Why do users care about zero-conf?
• The first seen policy.
• Types of double spend transactions.
• Current confirmation landscape for exchanges.
• How to protect from known double spend attack vectors.
• Key requirements to mitigate risk.
• Mitigating with double spend proofs.
• How to mitigate the remaining risk.

What is zero-conf?

Zero-conf is simply trusting that a transaction submitted into the mempool as valid and accepting those transactions before they are in a block, or in other words, trusting transactions broadcast to a node before proof of work is done.

Since zero-conf lives outside of consensus rules, there are many precautions that must be taken by businesses to accept them to prevent fraud.

Why do users care about zero-conf?

In a word, speed. Users want to send a transaction and get an instant approval that it reached the recipient. There are many cases where users do not want to wait for confirmations. For instance:

• Paying at a retail merchant.
• Sending money to an exchange to lock in the current exchange rate.
• Sending money to friends.
• Paying an online merchant.

The first seen policy.

While not part of the consensus rules, most nodes today will accept the first valid transaction it sees spending UTXOs as the valid transaction and disregard future conflicting transactions.

Some nodes like BU/XT will also relay double spend transactions, but this is not a majority of the network, and they will not keep a copy of the second transaction in the mempool.

Types of double spend transactions.

• Fast respend - sending two conflicting transactions to different geographic areas hoping that the receiver sees one transaction, but another gets mined.
• Miner bribe - sending a transaction, then sending a higher fee transaction later that sends to a different address hoping miners want to make slightly more profit.
• Reverse respend attacks - Sending a transaction with a very low fee, knowing it won't propagate. Then sending a normal transaction which the merchant or exchange sees, and hoping your low fee transaction is mined first!

The confirmation landscape for exchanges.

Exchanges when Bitcoin first came out used to accept zero-conf transactions. Later, arguments were made that zero-conf transactions were not safe and could be exploited.

This caused exchanges to be careful, and require numerous confirmations before they would consider a deposit as valid. Currently the most common number of confirmations is 6 in order to provide better security than zero-conf and avoid reorg attacks.

So how do we mitigate zero-conf risks?

Fast respend attacks.

These are by far the easiest to mitigate against. First, the attacker needs to know which nodes are being used to validate the transaction has made it to the mempool. Exchanges generally do not advertise this information.

Merely having nodes all over the world and checking multiple geographic locations can mitigate against this attack. If you confirm that all your geographically distributed nodes have the recently broadcast transaction then you can accept the transaction within seconds.

If you see a conflicting transaction, you can reimburse your customer via a chained transaction on the one they sent, and ban the user.

Miner bribes.

These are a bit tricker. If a miner accepts a higher fee transaction as valid and replaces it in the mempool, that can happen any time before a block is created. This gives the attacker an opportunity to defraud the receiver anytime before the next block is found. Therefore, just checking multiple nodes is not good enough.

That being said, most miners realize that doing this reduces confidence in the network, and could hurt the overall value of the chain they are mining. For small transactions it just isn't worth it. However, exchange transactions are generally not small, so this attack vector could still be relevant.

Miner bribes (cont).

There are a few ways to help mitigate these issues.

• Pre consensus systems being added to Bitcoin. This allows miners to try and agree on the valid transactions for the next block. Therefore if a small minority of miners gets greedy, but the majority are honest, then it is easy to find the miners being bribed and not accept their blocks.
• Since exchanges require KYC, double spends of this type can be reported to law enforcement and their account can be banned for fraud.
• Zero-conf transactions can be enabled only after a large volume of valid transactions have been done by the user and their credibility has been established.

Reverse respend attacks.

These are generally much lower risk. While someone can plant a low fee transaction below the propagation threshold, the nodes can still be queried for their current transactions.

Therefore for this to be feasible, the attacker would need to plant these in numerous locations to have enough hash power to actually have a reasonable chance of defrauding the exchange.

Much like the fast respend attack, the exchange would query as many nodes (theirs and others) as possible to guarantee that a majority of the network indeed has the valid transaction. Ideally pools would include a full node that could be queried!

Key requirements to mitigate risk.

Mitigating with Double Spend Proofs.

How to mitigate the remaining risk!

Thanks!

Let's make BCH the most secure zero-conf on the planet!