Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning Antoine,


> > This can be arranged by having one side offer partial signatures for the transaction of the other, and once completing the signature, not sharing it with the other until we are ready to actually broadcast the transaction of our own volition.
> > There is no transaction that both participants hold in completely-signed form
>
> I don't think that's different from the current model where you have either a valid HTLC-timeout or HTLC-Sucess tx to solve a HTLC output but never full witness material to build both ?

It is different in that the current (actually, now *previous*) model looks like this:


    funding out ->  contract tx -->  HTLC-timeout
                                         OR
                                     HTLC-success


Whereas what I am describing looks like this:

    funding out ->  HTLC-timeout
                        OR
                    HTLC-success

The attack being described has to do with the fact that, after private key turnover (i.e. after hash-lock resolution), the contract tx can be used to at least annoy the supposed new owner of the funding out, since the contract tx deducts fees from its input to pay for itself.
And at the end of the swap (after private key turnover) the one who funded the funding outpoint (and swapped its control for this outpoint already, for a different outpoint) can at least try to broadcast the contract tx for a *chance* that the HTLC-timeout becomes valid and it can steal the coin even after taking the swapped coin on the other side of the swap.


Chris recently described a different technique, which has different contract txes, with the contract tx held by the offerrer of the HTLC (who can otherwise later annoy the acceptor of the HTLC once the HTLC has been hash-resolved) costing the offerrer of the HTLC some coins if it is published after swap completion.


> > To reduce this risk, A can instead first swap A->B->A, then when that completes, A->C->A.
> This limits its funding lockup to 1 week.
>
> Okay I think I understand your point. So by intermediating the chain with the taker you ensure that in case of previous hop failure, taker funds are only timelocked for the delta of this faulting hop not the whole route. But still not anchoring onchain the next route segment means that any moment the next maker can exit from the proposed position ?
>
> That's interesting, so a) you require all takers to lock their funds onchain before initiating the whole routing and you will pay more in service fees or b) you only lock them step by step but you increase risk of next hop default and thus latency. Roughly.
>  
> It might be an interesting construction to explore on its own, minus the downside of producing weird spend patterns due to next hop maker bidding with another party.
>

Correct, a taker can pay higher fees for lots of smaller swaps that reduce its lockup risk, or pay less (with similar privacy bought) but with greater total lockup risk.

Regards,
ZmnSCPxj