Adapting CoinSwap for a Fungibility Market

coinswap.txt

In the protocol all parties are assumed to have private communications channels.

Phase 0. Sets up the escrows and their timeout refunds.
Phase 1. Makes it so that if Bob gets paid there is no way for Alice to fail to get paid.
Phase 2. Just releases the escrows directly because everyone is happy that cheating isn't possible.

  Alice                           Bob
  =========================================================
0. Compute TX_0: A>2of2{A,B'} | Compute TX_1: B>2of2{B,A'} \
1. Send TX_0 TXID ------------>                             |
2.                <------------ Send TX_1 TXID              |
3. Compute TX_1 locked refund | Compute TX_0 locked refund  |  Phase 0
4.                <------------ Send TX_0_refund            |
5. Send TX_1_refund ---------->                             |
6. Announces TX_0 to network  | Announces TX_1 to network  /
8.     Network confirms TX_0: Alice >  2of2{A,B'}
9.     Network confirms TX_1: Bob   >  2of2{B,A'}
A. Selects secret value X     |                            \
E. Sign(TX_2: TX_0>B"+X, A')  |                             |
F. Send TX_2 template   ------------->                      |  Phase 1
G.                            | Sign(TX_3: TX_1>A"+X, B')   |
H.               <------------- Send TX_3 template         /
     from now on, Alice can defect (but reveal X)
J.                            | Computes TX_4: TX_1>A'     \
K.               <------------- Send TX_4                   |
L. Signs and announces TX_4   |                             |
M.     Network confirms TX_4: Bob > Alice via 2of2 {B,A'}   | Phase 2
N. Computes TX_5: TX_0 > B'   |                             |
O. Send TX_5      ------------>                             |
P.                            |Signs and announces TX_5     |
Q.     Network confirms TX_5: Alice > Bob via 2of2 {A,B'}  /
  =========================================================

gmaxwell's original notes:

Note that Alice could also pay the role of Bob, so that Bob doesn't have to take part in the protocol. She could then send on the freshly disconnected coins directly to Bob in the final release.

Also note that care related to mutability is required for the refunds until transaction mutability is solved.

Another key point is that Carol also receives unlinked coins (from Alice), and so in a P2P network a party could equally play the role of Alice or Carol, taking on whichever position was required.

TX_0_refund must have a further future locktime than TX_1_refund. Otherwise Bob can delay step (I.) in the protocol until the refunds become valid and then announce TX_3 while Alice announces TX_0_refund in order to try to cause Alice to get refunded while Bob still gets paid.

Line 23 suggests to me that Alice cares more about anonymity than Bob, and must pay a premium to compensate Bob for the risk that Alice doesn't actually care about anonymity, and is either attempting DoS (through forcing Bob to spend tx fees on failed swaps) or planning to reveal X, correlating the transactions.

original proposal

dealing with mutability via p2sh

p2sh propagation

Regarding malleability:

Without any changes to the protocol, either party could freeze the other's funds after Phase 0. However, both parties have the ability to freeze the other's funds, so this would be an expensive attack. Malleator Mallory is unable to freeze funds belonging to Amical Alice and Brotherly Bob, since they could exchange new refund transactions if the attack malleation is confirmed instead.

Malleability, continued:

Can we publish "fraud proofs" if the other party doesn't sign a malleated transaction? This will require covering the funding transaction with a bitcoin signature, and showing a malleation against the covered transaction; which requires a DMMS on the malleation (in the case of p2sh, also full script too?), and the original transaction (ditto?).

Could they publish fake fraud proofs by fooling makers to sign unbroadcast transactions, then broadcasting their malleation and bailing?

See also https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki

bip65 for op_checktimelockverify could obviously be used here as a better alternative to nLockTime refund transactions. With the current trouble with soft forking bip66 I wonder how long it will take to actually happen.

A downside of two-party coinswaps is the maker knows for sure where the taker's coins go. There might be a way to construct many coinswaps in a chain, so each individual liquidity provider somehow doesn't know if they're the first, second or third node. A little like tor onion routing.

I'm pretty sure (cached knowledge) that a multiparty coinswap is possible... but I think it's not that worth thinking about. Really I think for JM much of the utility for coinswaps is avoiding long time makers making the transactions identifiable in the way the bc.i shared send stuff has been in the past.

CLTV is a thing, but I think it would be preferable to not use it because it degrades the anonymity set, it's worth even considering using fake 2 of 3 instead of 2/2 if 2/3 is much more common on the network; ---- with lowS enforcement in place we're closer still to making the rest of the BIP62 like rules-possible other other contract malleability fixes. I think that 99.99% of the application doesn't change if no protection is used, BIP62 like, CLTV like, or normsighash type. So I think design and implementation could go ahead without worrying about that, and when the software is ready for use just use the best available anti-malleability.

One can certantly chain coinswaps... at that point starts getting similar to the lightning network.

Proposal by @AdamISZ with some discussion here