Avalanche Pre-Consensus: Making Zeroconf Secure

The Problem

At present zeroconf payments are insecure on Bitcoin, Bitcoin Cash, Bitcoin SV and most other cryptocurrencies. They are insecure because an attacker can successfully get a double spend to confirm a non-trivial percentage of the time, meaning any merchant that accepts zeroconf payments runs an above normal risk of being defrauded.


Fast Respends
As I said above fast respends are the easiest class of attacks to defend against. Much of our focus at the last Bitcoin Cash developer retreat was focused around devising a double spend notification scheme that would relay cryptographic proofs that a double spend has taken place on the network allowing merchants to receive that proof and decline the payment.

  • The merchant’s point of sale terminal serves a BIP70 payment request to the buyer.
  • The buyer’s wallet creates a transaction and sends it directly back to the merchant. The merchant’s node inspects the transaction and makes sure it fulfills all the criteria for a zeroconf payment (it is not possible to create double spend proofs for all types of transactions, hence we need to restrict the set of acceptable transactions for zeroconf).
  • The merchant broadcasts the transaction to the network.
  • The merchant’s wallet then listens on the network for double spend notifications for the next 3–5 seconds.
  • If no double spend notification comes off the wire during this period the POS terminal accepts the payment.
  • If a double spend notification does come over the wire the POS terminal declines the payment and the cashier asks for another form of payment.
  • If the payment was rejected but it still confirms the wallet sends the refund back to the buyer’s refund address provided with the BIP70 payment.

Enter Avalanche

Avalanche is a new consensus protocol that was first introduced earlier this year. It provides a novel way for nodes on a network to choose between two conflicting transactions and come to a consensus about which one should be included in the next block.

  • Proof-of-work is used as the anti-sybil mechanism. The miners of the last 100 blocks form the consensus group and participate in avalanche. This is a rolling membership group. Each new block a new miner is added to the group and the miner who mined block n-100 gets booted.
  • If there are no double spends on the network, then Bitcoin Cash functions identically to how it currently functions. Miners receive transactions into their mempool, select which transactions to put into blocks, and broadcast solved blocks to the network. No avalanche messages are even sent between miners. To an outside observer, you wouldn’t even know avalanche is active.
  • When a double spend makes it into the miner’s mempools, it triggers the avalanche process. Miners start sending avalanche queries to each other and perform n number of rounds. Eventually all miners will decide that either transaction A is valid and B is invalid or A is invalid and B is valid.
  • If A is determined by avalanche to be valid and B invalid, miners are not required mine transaction A. Just like today, miners can still decide not to mine any given transaction. However, they are not allowed to mine transaction B. If a block is mined containing B it gets orphaned. Blocks that contain previously unannounced double spends must still go through avalanche before being accepted.
  • Non-mining nodes don’t need to know anything about avalanche and any full node software that is not used for mining doesn’t need to support it. From the standpoint of non-mining nodes, avalanche is a softfork. The worst case scenario is a miner mines a block containing a transaction that was determined by avalanche to be a double spend. The other miners reject the block and continue building on the previous block, but full nodes don’t know that it has been rejected. Eventually the rest of the miners will extend chain beyond the orphan block and full nodes will experience a one block reorg. In practice we wouldn’t expect this to happen as all miners would use avalanche to avoid getting orphaned and losing money.
  • Merchants would still need double spend detection to protect against fast respends but they could rest easy knowing that as long as they wait long enough for the payment to propagate to miner’s mempools (3–5 seconds) without detecting a double spend, that miners will not mine a later double spend even if it pays a bribe.


A solution to the zeroconf problem has been ten years in the making and we’re finally standing on cusp of making it happen. This is really the byproduct of lots of research, testing, and experimentation by a lot of talented people. It’s a much more rigorous and much more well thought out solution to the problem than Craig Wright’s haphazard “Just query the mempool of miners and have miners independently orphan blocks and then sue people when things go wrong”.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store