An atomic swap is a way of atomically exchanging cryptocurrencies based on different blockchains without involving trusted third-party intermediaries such as an exchange. While various technical methods are being studied, the representative approach is an implementation using the nLockTime parameter of smart contracts.
This article examines how standard trading in atomic swap works.
Standard trading
Algorithm
Let’s assume that Alice(“A”) and Bob(“B”) want to exchange each other’s cryptocurrency(“coin”), and both A and B have wallets for coin a and coin b respectively. (Public key hereinafter referred to as “Aa”, “Ab”, “Ba”, “Bb”)
[Phase 1]
A picks a random number x and keeps it to himself only
i. A creates a transaction in chain a(“TX1”) (not yet broadcasted to the chain)
- Contract: Pay <target amount of coin a, owned by A> to Ba if the condition below is satisfied
- Condition: x for H(x) is known and signed by B, or signed by both A and B (Multisig)
ii. A creates another transaction(“TX2”) in chain a that is necessary for canceling the trade (not broadcasted to the chain)
- Contract: Pay <target amount of coin a, owned by A> to Aa when 48 hours have passed since the output coin of TX1(=coin owned by Ba) had been generated, and signed by A
iii. A sends TX2 to B (* Via methods unrelated to the chain, including emails or messengers)
iv. B signs TX2 and sends it back to A (=A enabled to broadcast to chain a)
[Phase 2]
A broadcasts TX1 to chain a
i. B creates a transaction in chain b(“TX3”) (not yet broadcasted to the chain)
- Contract: Pay <target amount of coin b, owned by B> to Ab if the condition below is satisfied
- Condition: x for H(x) is known and signed by A, or signed by both A and B
ii. B creates another transaction(“TX4”) in chain b that is necessary for canceling the trade (not broadcasted to the chain)
- Contract: Pay <target amount of coin b, owned by B> to Bb when 24 hours have passed since the output coin of TX3(=coin owned by Ab) had been generated, and signed by B
iii. B sends TX4 to A
iv. A signs TX4 and sends it back to B
[Phase 3]
B broadcasts TX3 to chain b
[Phase 4]
A spends TX3 (=x is revealed because it needs to be entered in the parameter)
[Phase 5]
B spends TX1 using the revealed x in phase 4
Situations when the trading is halted
When the trading is halted, funds involved in trading are refunded.
- Before phase 2: no transaction has been broadcasted to the network(chain), so simply canceled
- Between phase 2 and 3: A can get his money back after 72 hours(24 hours of initial waiting period + 48 hours of lock time by TX2) by broadcasting TX2 to chain a
- Between phase 3 and 4: B can get his money back after 24 hours by broadcasting TX4 to chain b (A can get his refund later by broadcasting TX2)
- After phase 4: cancellation is not possible as the trading contract already had been broadcasted
– A must spend TX3 within 24 hours(=restriction time of TX3) (or else, B can claim his refund after the restriction time)
– B must spend TX1 within 72 hours (or else, A can claim his refund after the restriction time)
Limitations
- Requires a long time (72 hours) to recover the fund, when the trading fails
- Each of the trading party must use two transactions
- Fund recovery process involves a transaction replacement mechanism that may not be considered standard under the current bitcoin protocol rules
Trading by using specialized altcoin
This approach uses specialized coin devised for atomic swap, and only a single standard payment transaction on bitcoin exists. (no lock time, no multisig, no special contract script involved)
Algorithm
Assume that A is AltChain, and B is Bitcoin.
[Phase 1]
i. B creates and signs a transaction as usual and computes its txid in advance
ii. B sends A the incomplete txid and transaction body with input script and signature blanked
[Phase 2]
i. A computes the hash of the incomplete body (“bhash”)
ii. A constructs a transaction by using the bitcointxid(bhash, txid) opcode provided by altchain and broadcasts the transaction to the chain
[Phase 3]
i. B waits for the transaction to be confirmed and verified
ii. B sends the original transaction so that A can broadcast it to the chain (at the same time, the altchain transaction is also validated)
iii. B sends to A after he confirms that the transaction is sufficiently fixed so that the altchain will not reorganize its transactions
Special features related to altchain
- Bitcointx opcode: evaluates to true if txid are seen confirmed in the bitcoin blockchain (altcoin must refer to bitcoin for this), outputs are spendable, and bhash is equal to tx body
- It should be possible to validly broadcast bitcointx transaction to altchain even if there is no matching txid/bhash in bitcoin
- Transaction output is not spendable until the bitcoin txid confirmation is finalized, and inputs also cannot be spent by another tx
- Optionally there could be block# parameter that indicates the point where fixing the transaction occurred on the bitcoin side
- Inputs are mentioned multiple times -> can be used as transaction inputs, but only the transaction that was first to be fixed can be used and the other transactions become invalid
Reference source: https://en.bitcoin.it/wiki/Atomic_swap
