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

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to