Atomically Trading with Roger: Gambling on the Success of a Hardfork

Abstract

We present atomic trade protocols for Bitcoin and Ethereum that can bind two parties to swap coins in the event that two blockchains emerge from a single “pre-fork” blockchain. This work is motivated by a bet between two members of the Bitcoin community, Loaded and Roger Ver, to trade 60,000 bitcoins in the event that Bitcoin Unlimited’s planned hardfork occurs and the blockchain splits into two distinct forks. Additionally we study several ways to provide replay protection in the event of hardfork alongside a novel mechanism called migration inputs. We provide a detailed survey and history of previous softforks and hardforks in Ethereum and Bitcoin.

Appendices

A TierNolan’s Atomic Cross-Chain Trading Protocol

Table 4 presents the protocol proposed by TierNolan in 2013. The TierNolan protocol allows two parties to atomically exchange coins across two blockchains. Such protocols are called Atomic Swaps because the two transactions happen atomically i.e., either swap occurs or it does not. It requires both parties to deposit coins in separate blockchains and for one of the parties to trigger the exchange.

Table 4. Atomic Cross-Chain Trading Protocol. This protocol allows two parties to atomically exchange coins across two distinct blockchains

Table 5. Bitcoin’s Hard Fork Atomic Cross-Chain Trade if transaction malleability is fixed. Both parties authorise the atomic trade transactions prior to signing and broadcasting the funding transaction $T^{Fund}$. Both trade transactions can be accepted into their respective blockchain after the hard-fork activation time $\varDelta _{FORK}$.

Brief overview. Consider two blockchains, the first blockchain we denote as $\textsc {Fork}\text {-}1$, the second blockchain we denote as $\textsc {Fork}\text {-}2$. Alice wants to trade her coins on blockchain $\textsc {Fork}\text {-}1$ for coins which Bob controls on blockchain $\textsc {Fork}\text {-}2$. First, Alice picks a random value $S_{A}$, hashes it to $H(S_{A})$ and deposits her coins into a transaction $T_{1}$ which is confirmed on $\textsc {Fork}\text {-}1$. Bob can claim the funds in $T_{1}$ if and only if he learns the value $S_{A}$. However if the coins in $T_{1}$ are still unspent by $\varDelta _{A}$ Alice can refund the coins in this transaction back to herself.

B Proposed Bitcoin Protocol if Transaction Malleability is fixed

Table 5 presents the Bitcoin hard-fork atomic cross-chain protocol if transaction malleability is fixed. It assumes that both parties can use replay protection to dictate if a transaction can be accepted into $\textsc {Fork}\text {-}1$ or $\textsc {Fork}\text {-}2$. As we will soon see this variation is significantly simpler compared to the protocol outlined in Sect. 3.

Briefly, both parties co-operatively create a Funding Transaction $T^{Fund}$ and the two trade transactions $T^{A \rightarrow B}_{FORK1} , T^{B \rightarrow A}_{FORK2}$. Next, both parties must exchange signatures for the trade transactions before signing and broadcasting the funding transaction. Finally, both parties wait until after the hard-fork activation time $\varDelta _{FORK}$ to claim both deposits in their respective blockchain.

Table 6. Bitcoin’s Hard Fork Atomic Cross-Chain Trade. Our proposed protocol commits both Alice and Both to the trade prior to the hardfork’s activation

This approach follows a similar style to payment protocols such as Duplex Micropayment Systems and Lightning as the off-chain’s transactions are signed prior to the funding transaction. The order of signing off-chain transactions does not necessarily matter as these transactions are only valid if the funding transaction is accepted into the blockchain. Furthermore, it is worth highlighting that this approach does not require one party (i.e. Alice) to reveal a pre-image $S_{A}$ or to sign cancel/forfeit transactions.