Date: Sat, 05 Sep 2020 02:29:18 +0000
To: Antoine Riard <antoine.riard@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <HY0TQs10f6EP6tpw4gaY4W68m1vmn7zGY2EYa_jqMEN3ofSvyQgBGGIDotcAPmRNPg7oFteTugWFOwI9avdtLN0YVOZNiF9HrxnKtycVPG0=@protonmail.com>
In-Reply-To: <CALZpt+F0LDTERsPv7nZuuc34oyCPN-gMPspfxTM5kKqz4mSJqg@mail.gmail.com>
References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net>
 <CALZpt+GxKDEDAGUH3Jb3rcZdh_jy_depLRE5KzGTpkZOLVH+QA@mail.gmail.com>
 <VpsctPiYOV704v9wZiSROdRggid7uRv2mZVnCIILEPL4_VmwKhMVdNMPBj9XaF73-39jFLl3cq1o2tSk8h45tMuWM9W_i4_MQHKoJdYh9ew=@protonmail.com>
 <CALZpt+F0LDTERsPv7nZuuc34oyCPN-gMPspfxTM5kKqz4mSJqg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Detailed protocol design for routed
	multi-transaction CoinSwap
Precedence: list

Good morning Antoine,


> > This can be arranged by having one side offer partial signatures for th=
e 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-signe=
d form
>
> I don't think that's different from the current model where you have eith=
er 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 contrac=
t 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, fo=
r 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 eve=
n after taking the swapped coin on the other side of the swap.


Chris recently described a different technique, which has different contrac=
t txes, with the contract tx held by the offerrer of the HTLC (who can othe=
rwise later annoy the acceptor of the HTLC once the HTLC has been hash-reso=
lved) 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 c=
ompletes, 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. Bu=
t 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 onch=
ain before initiating the whole routing and you will pay more in service fe=
es or b) you only lock them step by step but you increase risk of next hop =
default and thus latency. Roughly.
> =C2=A0
> 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 wi=
th 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