A problem with the deployment of CLTV on Bitcoin is that many altcoins don't support it.
This protocol allows transfers to coins that use the oldest type of IsStandardChecks. Outputs have to use basic script or they won't be accepted.
0) Commit to paying fees
NEWBoth parties pick a random number and the trade_id = hash256(alice_random_number | bob_random_number)
Both parties should create a transaction which pays to
OP_1 <creators_public_key> <02, tradeId> OP_2 OP_CHECKMULTISIG
It must pay fees that are greater than 0.1% of the coins being exchanged. It is a one of two multisig. Since the 2nd public key is generated from the trade_id, nobody has the corresponding private key. This means that it is the same as having 1 key, but it allows committing the fee to the trade.
If <02, tradeId> is not a valid compressed key, then a new tradeId should be selected, until a valid compressed key can be created.
This step could be skipped when in "trusting" mode. If other parties tend to abort before step 1 ends, then the node could switch to untrusting mode.
Reputation systems could be deployed here.
1) Cut and choose
Bob generates 1000 keypairs and sends hash(bob_priv_n) and bob_pub_n to Alice for each n (1 to 1000).
Alice picks n from 1 to 1000 and Bob sends bob_priv_n for the 999 other n's.
If they are ok, then Alice assumes the pair she didn't see is valid.
Similarly, Alice generates 1000 key pairs and has Bob choose.
This gives the following public info.
hash(bob_priv_n) matches bob_pub_n
hash(alice_priv_m) matches alice_pub_m
There is a 0.1% chance of fraud for each attempt. This means that fees must be at least 0.1% of the transaction value. In that way, there is no incentive to cheat at the cut-and-choose.
2) Bob pays D to
OP_IF
<now + 2 days> OP_CLTV OP_DROP <alice_pub_1001> OP_CHECKSIG
OP_ELSE
OP_HASH160 <hash(bob_priv_n)> OP_EQUALVERIFY <bob_pub_1001> OP_CHECKSIG
OP_ENDIF
D should be more valuable than the value of the Bitcoins or altcoins.
This is a promise by Bob to release bob_priv_n within 2 days (or lose his deposit).
3) Alice pays a altcoins to
OP_2 <bob_pub_n> <alice_pub_m> OP_2 OP_CHECKMULTISIG
4) Bob pays b Bitcoins to
OP_IF
<now + 1 day> OP_CLTV OP_DROP <bob_pub_1002> OP_CHECKSIG
OP_ELSE
OP_HASH160 <hash(alice_priv_m)> OP_EQUALVERIFY <alice_pub_key_1001> OP_CHECKSIG
OP_ENDIF
Alice has 1 day to claim her output, but that means she must provide alice_priv_m.
5) Alice spends the output (and provides alice_priv_m).
6) Bob can spend the altcoin output (since he has both keys)
7) Bob reclaims his deposit
This is atomic and it is recoverable if either party refuses to complete a step.
1) Either party refuses to perform cut-and-choose.
Nothing has been sent to either chain, so no harm done.
2) Bob refuses to pay deposit.
Nothing has been sent to either chain, so no harm done.
3) Alice refuses to bail-in.
Bob reclaims his D after 2 days.
Releasing bob_priv_n has no effect since there was no bail-in by Alice, so the key is never used.
4) Bob refuses to bail-in
If Bob reclaims his deposit, then Alice will have both private keys and can reclaim her bail-in.
If Bob fails to claim his deposit, then Alice gets that as compensation instead of her bail-in. In that case, Bob loses his deposit and can't claim the altcoins. This means he should reclaim his output.
5) Alice refuses to claim her Bitcoins
1 day later Bob can reclaim his Bitcoins
Alice gets her altcoins back or she gets D instead (if Bob doesn't reclaim his deposit).
6) Bob refuses to claim his altcoins
He loses his altcoins when he reclaims his deposit. Alice already has his Bitcoins by this point.
He has an incentive to complete this step.
7) Bob refuses to claim his deposit
He loses his deposit and Alice gets it.
He has an incentive to complete this step.
For each step, there is either an incentive to complete the step or failure to complete the step causes the protocol to abort. In an abort, the incentives are to perform a clean abort.
