We have designed a new protocol for Bitcoin and Ethereum that lets users bet on the outcome of a hardfork. Prior to the hardfork, two parties can deposit coins and commit to a wager; after the hard fork occurs, the coins are swapped on both forks. Our protocol is inspired by Loaded's challenge to Roger to swap 60k coins in the event of a Bitcoin Unlimited hardfork.
Satoshi Nakamoto's 1MB block size limit was activated on 12th September 2010 as an anti denial of service mechanism. Four months later, Satoshi Nakamoto left the community without removing the block size limit. His departure has led to the block size debate.
Over the years several projects have attempted and failed to adjust this block limit as changing Bitcoin's consensus rules appears to require significant support from miners, developers, exchanges, and validators.
Bitcoin Unlimited (BU) is one such proposal to adjust the block limit by a hardfork. Currently around 54% of mining power is signaling support for it. BU includes a new consensus rule called emergent consensus that allows miners to govern the block size amongst themselves.
As with any hard fork, the danger is that the blockchain could split in two upon activating the new consensus rule. One fork would follow the 1MB consensus rules; the other fork would follow the new emergent consensus rules.
It is worth highlighting that members of the Bitcoin community perceive that a blockchain split is highly probable if BU is successful. In fact, this perception has led to Loaded (a wealthy member of the Bitcoin community) challenging Roger Ver (a vocal advocate of Bitcoin Unlimited) to put his money where his mouth is and to swap at least 60k coins (i.e. a 1:1 trade) if the blockchain does indeed split into two distinct forks.
The best part of this story is that Roger responded within two days to signal his willingness to pursue the bet.
Of course before we can be excited about the bet... a single question remains:
What is the best technical approach for Loaded and Roger to pursue this bet?
Loaded stated that he would prefer if the trade could be performed as an atomic swap.
Anyone familiar with atomic swap protocols in Bitcoin will instinctively think of Tier Nolan's protocol after reading Loaded's post. In fact, I (Patrick McCorry) responded to Ethan Heilman on twitter to suggest that Loaded and Roger use TierNolan's protocol.
Ethan Heilman identified that the TierNolan protocol is not suitable for the bet since Roger and Loaded cannot use TierNolan to commit to the trade prior to the activation of Bitcoin Unlimited's hardfork. However Ethan's second reply about using replay protection to build a new atomic trade protocol led to an eureka moment.
Together we developed a new atomic trade protocol to allow Loaded and Roger to deposit coins prior to the hard fork's activation and perform the atomic swap after the blockchain splits. In fact, we propose a protocol for both Bitcoin and Ethereum.
A key design decision for the Bitcoin atomic trade protocol was to ensure it was compatible with Bitcoin as deployed today (i.e. in the absence of a fix for transaction malleability). The protocol has three stages:
Deposit coins. Both Roger and Loaded deposit coins into a single funding transaction.
Off-chain Setup. First, Roger signs a cancellation transaction to Loaded that allows him to cancel the atomic trade if the off-chain setup is not complete.
Next, Roger signs a trade transaction and sends it to Loaded. This transaction allows Loaded to claim both deposits in the non-Bitcoin Unlimited blockchain (i.e. old consensus rules) if Roger reveals the secret A of H(A).
Then, Loaded signs a trade transaction and sends it to Roger. It is worth mentioning that this trade transaction has replay protection to ensure it can only be accepted into Bitcoin Unlimited's blockchain. This transaction allows Roger to claim both deposits if he reveals the secret A of H(A).
Once both trade transactions are exchanged, Roger is required to sign two forfeit transactions and send them to Loaded. The purpose of the forfeit transactions is to lock Roger into the trade such that if he does not reveal the secret A, then Loaded can claim all coins in both blockchains when the trade expires.
Assuming the above steps are complete and Loaded has not canceled the trade, then Roger can broadcast a commit transaction that locks both parties into the trade (i.e. blocking Loaded's cancellation transaction).
Atomic Trade. Roger can broadcast his trade transaction into the Bitcoin Unlimited blockchain once the hardfork occurs. This also requires Roger to reveal the secret A in order to claim both deposits.
Assuming the blockchain does indeed split into two forks, then Loaded can use the secret A to also broadcast his trade transaction in the non-Bitcoin Unlimited blockchain.
Of course, if Roger decides to abort and not claim his coins, then the trade expires and Loaded can claim all coins in both blockchains.
The key insight of this protocol (and bitcoin contracts in general) is that it is difficult to achieve fair exchange in the absence of a transaction malleability fix. In the appendix of our paper we include a second atomic trade protocol for Bitcoin that assumes transaction malleability has been fixed. Not surprisingly the second protocol's design is vastly simpler and is similar to how a payment channel is established, i.e. both trade transactions are signed off-chain before signing and broadcasting the funding transaction.
As mentioned, we also designed a smart contract for Ethereum called 'Trade' to perform an atomic trade in the event of a hardfork. An interesting insight of this protocol is that a hardfork oracle can be realised to allow other contracts to detect whether it is in fork-1 (i.e. old consensus rules) or fork-2 (i.e. new consensus rules).
The protocol is straightforward:
Of course, the Trade contract communicates with the Hardfork Oracle contract to identify which blockchain it is in before authorising any withdrawal.
It is exciting that both Loaded and Roger may potentially swap their coins in the event that Bitcoin Unlimited is successful. Of course, our protocol is applicable not just to Bitcoin Unlimited, but any hardfork that includes replay protection. We hope the community have fun reading the paper and if anyone is willing to develop the protocol for use in any future hardfork then please let us know!
p.s. It is also worth mentioning that this paper is great example that using twitter is not always a waste of time... :)
Acknowledgements We want to thank Amy Castor for her constructive comments on an early draft of the blog post.