Image for post
Image for post

On-chain Bitcoin Fork Futures

James Prestwich
Dec 4, 2017 · 7 min read

Taking advantage of replay protection

We can create an on-chain forward of a coin that doesn’t exist yet. We do this by leveraging the replay protection mechanism. Its details should be known well in advance of the fork. We can create and sign, months before the chain fork, a series of transactions that splits the coins. Then we broadcast them after the fork. As long as the timing of the fork and the replay protection mechanism remain unchanged, everything is safe and trustless.

Constructing the forward


  1. Alice and Bob each create, but do not sign, transactions sending pre-fork coins to the shared multisig’s P2SH address. We call Alice’s funding transaction tx1, and Bob’s funding transaction tx2.
  2. Alice and Bob create, but do not sign, transactions spending the outputs of their funding transactions as follows:
  3. tx3: A transaction spending tx1 and tx2’s outputs, sending them to Alice. This transaction includes replay protection, and is valid only on the BTC chain. Time locked until 2 weeks after the fork.
  4. tx4: A transaction spending tx1 and tx2’s outputs, sending them to Bob. This transaction does not require replay protection. This transaction is time locked until 3 weeks after the fork.
  5. tx5: A transaction refunding tx1 to Alice, no replay protection required, time locked until at least 4 weeks after the fork.
  6. Bob signs transactions 3 and 5, and sends them to Alice.
  7. Alice signs transaction 4, and sends it to Bob.
  8. Alice signs tx1, and broadcasts it to the network in advance of the fork.
  9. Bob signs tx2, and broadcasts it to the network in advance of the fork.
  10. If Bob does not sign and broadcast tx2, then tx3 and tx4 are invalid, and Alice may retrieve her coins via tx5 after the time lock.
  11. Both parties wait for the fork.
  12. After its time lock elapses (after the fork), Alice signs and broadcasts tx3. This transaction is valid only on BTC, due to the inclusion of replay protection. Alice receives the BTC.
  13. After tx4’s time lock elapses, Bob broadcasts tx4. This transaction is valid only on BT2, because its inputs have been spent on the BTC chain by tx4. Bob receives the BT2.
  14. Confirmation of tx3 and tx4 renders tx5 invalid on both chains. It may be discarded.

Timing issues?

This structure assumes that both chains progress at a reasonable rate. However, theft of funds is not allowed, even if block rates are significantly different between chains. Because tx3 is always valid on BTC before tx4 or tx5, Alice is guaranteed her BTC. Because tx3 is never valid on BT2, and tx4 is always valid on BT2 before tx5, Bob is guaranteed his BT2. The worst outcome is long delays for one party.

Strong replay protection

If the replay protection is strong, it provides additional protection for Alice if she has trouble getting tx3 confirmed on her chain. Using strong replay protection in tx3 and tx4 will prevent Bob from submitting tx4 to the wrong chain and stealing Alice’s coins. If strong replay protection is mandatory (as it should be), they’ll need to make two versions of tx5: one for each chain. These should be created in step 3, and signed by Bob in step 4.

Simplified setup

Instead of making tx1 and tx2, Alice and Bob could cooperate to make a joint funding tx. Other transactions would be modified to spend the single output from this transaction, rather than the two outputs from tx1 and tx2. This would simplify the setup process, and decrease on-chain complexity.

Failure cases

Assuming transactions are constructed properly and verified by both parties before funds are moved, there are few failure cases. These relate mostly to parties not broadcasting their transactions in a timely manner. The major exception is chain-split related failures, which are discussed below.

Chain-split related failures

This construction relies on knowledge about the timing of the chain split and its replay protection mechanism. We implement replay protection before the split, with time locks set after the split. Once we’ve set up a trade and both parties have funded the shared multisig any change to the chain split plans is dangerous.

Minimizing wait times

One major downside of this approach is that Bob is forced to wait longer than Alice to retrieve his coins. We can minimze Bob’s wait time while maintaining safety by adding an additional script and transaction. This ensures that Bob’s coins are accessible as soon as Alice retrieves hers.

  1. We modify the shared multisig script as follows: OP_IF OP_2 <Alice Pubkey> <Bob Pubkey> OP_2 OP_CHECKMULTISIGVERIFY OP_ELSE OP_HASH160 <H(k)> OP_EQUALVERIFY OP_DUP OP_HASH160 <Bob's pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG OP_ENDIF
  2. We modify tx3 to pay, instead of Alice, the following script, which we call Alice’s retrieval script:OP_IF OP_HASH160 <H(k)> OP_EQUALVERIFY OP_DUP OP_HASH160 <Alice's pubkeyhash> OP_ELSE <time> OP_CHECKSEQUENCEVERIFY OP_DROP OP_DUP OP_HASH160 <Bob's pubkeyhash> OP_ENDIF OP_EQUALVERIFY OP_CHECKSIG
  3. We create tx6, in which Alice uses knowledge of k to spend funds held by Alice’s retrieval script. Alice must broadcast tx3, wait for it to confirm, and then broadcast tx6 to gain access to the BTC. Alice has a limited time after tx3 confirms to broadcast tx6. If she does not broadcast tx6 in a timely manner, Bob can retrieve her coins.
  4. Seeing tx6, Bob may use knowledge of k to create tx7, which spends from the shared multisig via the OP_ELSE path.
  5. If Alice does not broadcast tx6, Bob may create and broadcast tx8, which takes Alice’s BTC. Bob would then wait for tx4 to become valid in order to retrieve his BT2.


Interoperability as a Service

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

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