[bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

[ZmnSCPxj]

Good morning yet again Chris,

> > For the avoidance of theft, it is probably better for Bob to wait for Alice-side funding tx to confirm, probably deeply because reorgs suck.

I realized that the *other* improvement I proposed in the [CoinSwapCS issue](https://github.com/AdamISZ/CoinSwapCS/issues/53) would help with this.
Specifically, `nLockTime`-protected Backouts.

Suppose we have an S6 route as so, with Alice as taker and Bob1 and Bob2 as makers:

    Alice -> Bob1 -> Bob2 -> Alice

We assume here that Bob1 and Bob2 directly talk to Alice and that if Bob1 wants to talk to Bob2 it is done via Alice, so in the below if we say "Bob1 sends to Bob2" we imply that this is done via Alice.

1.  Alice solicits fresh pubkeys from Bob1 and Bob2.
2.  Alice gives timeouts L1 and L2 to Bob1, and L2 and L3 to Bob2, such that L1 > L2 > L3, as well as negotiated amount, fees, etc.
3.  Alice creates (but does NOT sign) a funding tx paying to Alice && Bob1 and gives the txid to Bob1.
4.  Bob1 creates and signs a tx spending from the Alice funding tx and paying to Alice, with `nLockTime = L1`, and gives the signature to Alice.
5.  Bob1 creates (but does NOT sign) a funding tx paying to Bob1 && Bob2 and gives the txid to Bob2.
6.  Bob2 creates and signs a tx spending from the Bob1 funding tx and paying to Bob1, with `nLockTime = L2`, and gives the signature to Bob1.
7.  Bob2 creates (but does NOT sign) a funding tx paying to Bob2 && Alice and gives the txid to Alice.
8.  Alice creates and signs a tx spending from the Bob2 funding tx and paying to Bob2, with `nLockTime = L3`, and gives the signature to Bob2.
9.  Alice signals everyone to sign their respecting funding txes and broadcast them.

The rest of the CoinSwap protocol executes as normal once the funding txes are deeply confirmed.
The only thing that Bob1 (resp. Bob2) needs to wait for is that the signatures for the incoming HTLC / PTLC have been received before forwarding to the next hop.
This allows all funding txes to be confirmed in the same block, or even in some suitable random order (by having Alice send the signal out at different times/blocks to different makers).

The `nLockTime`d backout transactions are sufficient to allow everyone to recover their funds unilaterally in case one of the other funding txes do not confirm.

A similar technique can be done for SAS as well, but this removes the lack of encumbrance in the LTC-side output of SAS, which removes the advantage of having an otherwise unencumbered output.

In effect, the above creates Spilman unidirectional payment channels along the route, bringing the fiddly timing details offchain where it is less visible to observers.

--

However, note that this still allows a form of griefing attack.
Basically, Alice can induce Bob1 and Bob2 to lock their funds for some time, by completing the above ritual, but not signing and broadcasting its own funding tx.
Bob1 and Bob2 will have been induced to lock their funds for L2 and L3, respectively, while Alice only has to RBF away its own funding tx.

Alice might do this if it is actually another maker and it wants to take out its competitors Bob1 and Bob2, reducing their available liquidity for a time and cornering the SwapMarket.


This can be mitigated by replacing step 9 with:

9.  Alice gives its signed funding tx to Bob1.
10.  Bob1 gives its signed funding tx to Bob2.
11.  Bob2 gives its signed funding tx to Alice.
12.  Alice signals everyone to broadcast their funding txes.

Then Bob1 (resp. Bob2) can monitor the mempool/blockchain and check as well if its outgoing funding tx has been broadcast/confirmed, and if so broadcast the incoming funding tx.
Or better, if Bob1 (resp. Bob2) does not receive the Alice signal fast enough, it will broadcast its incoming funding tx anyway.

This is only a mitigation: Alice could have pre-prepared a replacement to the funding tx that it broadcasts near miners just before it signals Bob1 and Bob2 to broadcast all transactions.

For full protection against griefing attacks, Bob1 (resp. Bob2) have to wait for the incoming funding tx to be confirmed deeply before broadcasting its outgoing funding tx as well.

Regards,
ZmnSCPxj