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


Good morning Antoine,


> Note, I think this is independent of picking up either relative or absolu=
te timelocks as what matters is the block delta between two links.

I believe it is quite dependent on relative locktimes.
Relative locktimes *require* a contract transaction to kick off the relativ=
e locktime period.
On the other hand, with Scriptless Script (which we know how to do with 2p-=
ECDSA only, i.e. doable pre-Taproot), absolute locktimes do not need a cont=
ract transaction.

With absolute locktimes + Scriptless SCript, in a single onchain PTLC, one =
participant holds a completely-signed timelock transaction while the other =
participant holds a completely-signed pointlock transaction.
This can be arranged by having one side offer partial signatures for the tr=
ansaction of the other, and once completing the signature, not sharing it w=
ith the other until we are ready to actually broadcast the transaction of o=
ur own volition.
There is no transaction that both participants hold in completely-signed fo=
rm.

This should remove most of the shenanigans possible, and makes the 30xRBF s=
afe for any range of fees.
I think.

Since for each PTLC a participant holds only its "own" transaction, it is p=
ossible for a participant to define its range of fees for the RBF versions =
of the transaction it owns, without negotiation with the other participant.
Since the fee involved is deducted from its own transaction, each participa=
nt can define this range of RBFed fees and impose it on the partial signatu=
res it gets from the other participant.

--

Private key turnover is still useful even in an absolute-timelock world.

If we need to bump up the block delta between links, it might be impractica=
l to have the total delta of a multi-hop swap be too long at the taker.

As a concrete example, suppose A is a taker who wants to route over makers =
B and C.
However, B and C require a CLTV delta of 1 week.

If A wants to route "directly" A->B->C->A, then if something bad happens, i=
t could be looking at having its funds locked for two weeks.

To reduce this risk, A can instead first swap A->B->A, then when that compl=
etes, A->C->A.
This limits its funding lockup to 1 week.

Private key turnover is useful since as soon as the A->B->A swap completes,=
 it can directly fund the A->C->A swap from the B-side funding transaction =
of the A->B->A swap.

         |   A->B->A         |    A->C->A           |
         :                   :                      :
      A -:->funding A&B--> B :                      :
         :                   :                      :
      B -:->funding A&B -----:--> funding A&C --> C :
         :                   :                      :
         :                   :C-> funding A&C ------:-> to-cold  A -->
         :                   :                      :

This increases the number of transactions by 1 per swap beyond the first, c=
ompared to a direct routing A->B->C->A, but this may be worth it for A if t=
he timelocks involved are too big for A.

With 2p-ECDSA, a funding A&C looks exactly the same as a to-cold A, so B is=
 unable to reliably determine if it is the last hop in the route.

Without private key turnover, A would have:

                      **NO** private key turnover!

         |   A->B->A         |    A->C->A                      |
         :                   :                                 :
      A -:->funding A&B--> B :                                 :
         :                   :                                 :
      B -:->funding A&B -----:--> claim A -> funding A&C --> C :
         :                   :                                 :
         :                   :           C-> funding A&C ------:-> to-cold =
 A -->
         :                   :                                 :

So if timelock-deltas are possibly-high (to reduce the probability of the M=
AD-HTLC argument, and other attacks, succeeding), takers might prefer to ro=
ute by completing one swap first before starting the next one, and private =
key turnover is useful by reducing blockspace required by each hop.

For reference, this is how it looks like with a single A->B->C->A swap with=
 private key turnover:

         |   A->B->C->A      |
         :                   :
      A -:->funding A&B--> B :
         :                   :
      B -:->funding B&C -> C :
         :                   :
      C -:->funding A&C -----:-> to-cold A -->
         :                   :

This is still smaller than in the A->B->A, A->C->A with private key turnove=
r, by one funding tx per hop.
However, A risks a much higher timelock (twice the timelock).
Thus, A might prefer a lower timelock in exchange for paying for an additio=
nal transaction.

Regards,
ZmnSCPxj