path: root/b9/5d482fe3ec86a45c840ab4e897de67da1072e7

Return-Path: <antoine.riard@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 16773C0052
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  5 Sep 2020 01:10:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 0161E86DE4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  5 Sep 2020 01:10:53 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id HQIc+4Aeb-Li
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  5 Sep 2020 01:10:51 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com
 [209.85.221.46])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 2AC87869CA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  5 Sep 2020 01:10:51 +0000 (UTC)
Received: by mail-wr1-f46.google.com with SMTP id j2so9155542wrx.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 04 Sep 2020 18:10:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=/b4zIuRGimEslQqZzz/Luc6+bLzkDgNNWOPb5jwr0is=;
 b=Xp1U352LZkonva8Rqn4WCQyAoyrdbGDZQJb4nyoGPLLAEayhvyApiZ+2i2SYxgaYx9
 /Q61WNx16iYa6g8iW+YPjsu/3A0KfGjShe6T+aOd2s0KWFP5Liym+1PNYvAbJ/JpKDX/
 xrmVRVYw81ynGJ87UsN6eqVJNBWa85JY50jdazZqRwj9m3QM2C8apup5wmhnWN+yy8A6
 mhdMEZtiJPNHQMBHEggNO/G4naXwcIFKbIsenVEoKSU9HF9FyjMj1Mbo4inZi2aK3Wx0
 1a73F5gP6kyXsTf2srHGmyCcyEnbWcgEbq0HftEe3hEmi/+Z+VAdfWV5dJGyNg6jx0AX
 TLoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=/b4zIuRGimEslQqZzz/Luc6+bLzkDgNNWOPb5jwr0is=;
 b=Hexc9ht2TDy59suT1upPUF5GGHX1Eei65igsI+QWW4fVo85rGevght2c99koWSulax
 oxxbCU//ons9zkYRDil0JOifHxJ700pXjmCBS26pH4n+86B+cnDnIQhG1GgKzKDCppRo
 M0gByuSmFQBXRjdgWqAfhyADeMyA0e6sVQm/Q7dQTDq21SXjRsHqEcf092yxjR7BDtVm
 5DciYN+fbOzA+Q5cuVpyd5sa6zdKRilpy/0L9CCCmsoWuXYmDtZe70DiWcwGDChGJHV9
 MWRddRCQAiSbF7m3bXs0NGp2VU+CTdZ2A7YIEDwdQtmifxCAqPH66UXhJUvBg4Qk7YbM
 bCYA==
X-Gm-Message-State: AOAM531O/pprAUjecwGSGH6/ZAaBq3lHeULdvxEAD+fur9g8dh5mlIs/
 QwBZlN3xqb94llVHtxkiwzBXx2KhxMtKffZDDYk=
X-Google-Smtp-Source: ABdhPJyH5Yvptu+Zq+MEGL20xrMPcfTqU/BHBzPV3dfBMwELAmVBWx7oPlVX1QauRPaCRXg5xNKcbOgO5F8Xt1hp7x0=
X-Received: by 2002:adf:f88b:: with SMTP id u11mr9689239wrp.376.1599268249613; 
 Fri, 04 Sep 2020 18:10:49 -0700 (PDT)
MIME-Version: 1.0
References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net>
 <CALZpt+GxKDEDAGUH3Jb3rcZdh_jy_depLRE5KzGTpkZOLVH+QA@mail.gmail.com>
 <VpsctPiYOV704v9wZiSROdRggid7uRv2mZVnCIILEPL4_VmwKhMVdNMPBj9XaF73-39jFLl3cq1o2tSk8h45tMuWM9W_i4_MQHKoJdYh9ew=@protonmail.com>
In-Reply-To: <VpsctPiYOV704v9wZiSROdRggid7uRv2mZVnCIILEPL4_VmwKhMVdNMPBj9XaF73-39jFLl3cq1o2tSk8h45tMuWM9W_i4_MQHKoJdYh9ew=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Fri, 4 Sep 2020 21:10:36 -0400
Message-ID: <CALZpt+F0LDTERsPv7nZuuc34oyCPN-gMPspfxTM5kKqz4mSJqg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000eb39cb05ae86a712"
X-Mailman-Approved-At: Sat, 05 Sep 2020 06:58:07 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Detailed protocol design for routed
 multi-transaction CoinSwap
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Sep 2020 01:10:53 -0000

--000000000000eb39cb05ae86a712
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Zeeman,

I think one of the general problems for any participant in an
interdependent chain of contracts like Lightning or CoinSwap is to avoid a
disequilibrium in its local HTLC ledger. Concretely sending forward more
than you receive backward. W.r.t, timelocks delta aim to enforce order of
events, namely that a forward contract must be terminated before any
backward contract to avoid a discrepancy in settlement. Order of events can
be enforced by a) absolute timelocks and thus linearized on the same scale
by blockchain ticks or b) by a counterparty to two relative-time locked
contracts which observe the broadcast of the backward transaction and thus
manually trigger the kickoff of forward timelock by broadcasting the
corresponding transaction.

With this rough model in mind, pinning an absolute or relative timelocked
transaction produce the same effect, i.e breaking contracts settlement
order.

> 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 ?

I see a theoretical issue with RBF-range, if you're likely to lose the
balance, you can broadcast your highest-RBF version thus incentivizing
miners to censor counterparty claim tx. Kind of a "nothing at stake" issue.
As of today, you have to take this fee out of your pocket if you want to
incentivize miners to act so, not promising a fee from an ongoing disputed
balance.

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

The way I understand the either-HTLC-or-private-key-turnover construction
in CoinSwap is for the HTLC to serve as a security backup in case the
cooperative key turnover fails. Lightning don't have this model as you
don't switch funding transaction ownership.

> 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.

Cheers,

Antoine

Le lun. 24 ao=C3=BBt 2020 =C3=A0 23:16, ZmnSCPxj <ZmnSCPxj@protonmail.com> =
a =C3=A9crit :

>
> Good morning Antoine,
>
>
> > Note, I think this is independent of picking up either relative or
> absolute 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
> relative 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
> contract transaction.
>
> With absolute locktimes + Scriptless SCript, in a single onchain PTLC, on=
e
> participant holds a completely-signed timelock transaction while the othe=
r
> participant holds a completely-signed pointlock transaction.
> 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 o=
f
> our own volition.
> There is no transaction that both participants hold in completely-signed
> form.
>
> This should remove most of the shenanigans possible, and makes the 30xRBF
> safe for any range of fees.
> I think.
>
> Since for each PTLC a participant holds only its "own" transaction, it is
> possible for a participant to define its range of fees for the RBF versio=
ns
> of the transaction it owns, without negotiation with the other participan=
t.
> Since the fee involved is deducted from its own transaction, each
> participant can define this range of RBFed fees and impose it on the
> partial signatures 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
> impractical to have the total delta of a multi-hop swap be too long at th=
e
> taker.
>
> As a concrete example, suppose A is a taker who wants to route over maker=
s
> 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,
> it 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
> completes, 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,
> compared to a direct routing A->B->C->A, but this may be worth it for A i=
f
> the 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
> MAD-HTLC argument, and other attacks, succeeding), takers might prefer to
> route by completing one swap first before starting the next one, and
> private key turnover is useful by reducing blockspace required by each ho=
p.
>
> 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
> turnover, 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
> additional transaction.
>
> Regards,
> ZmnSCPxj
>

--000000000000eb39cb05ae86a712
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Zeeman,<br><br>I think one of the general problems for =
any participant in an interdependent chain of contracts like Lightning or C=
oinSwap is to avoid a disequilibrium in its local HTLC ledger. Concretely s=
ending forward more than you receive backward. W.r.t, timelocks delta aim t=
o enforce order of events, namely that a forward contract must be terminate=
d before any backward contract to avoid a discrepancy in settlement. Order =
of events can be enforced by a) absolute timelocks and thus linearized on t=
he same scale by blockchain ticks or b) by a counterparty to two relative-t=
ime locked contracts which observe the broadcast of the backward transactio=
n and thus manually trigger the kickoff of forward timelock by broadcasting=
 the corresponding transaction.<br><br>With this rough model in mind, pinni=
ng an absolute or relative timelocked transaction produce the same effect, =
i.e breaking contracts settlement order.<br><br>&gt; This can be arranged b=
y 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.<br>&g=
t; There is no transaction that both participants hold in completely-signed=
 form<br><br>I don&#39;t think that&#39;s different from the current model =
where you have either a valid HTLC-timeout or HTLC-Sucess tx to solve a HTL=
C output but never full witness material to build both ?<br><br>I see a the=
oretical issue with RBF-range, if you&#39;re likely to lose the balance, yo=
u can broadcast your highest-RBF version thus incentivizing miners to censo=
r counterparty claim tx. Kind of a &quot;nothing at stake&quot; issue. As o=
f today, you have to take this fee out of your pocket if you want to incent=
ivize miners to act so, not promising a fee from an ongoing disputed balanc=
e.<br><br>&gt; Private key turnover is still useful even in an absolute-tim=
elock world.<br><br>The way I understand the either-HTLC-or-private-key-tur=
nover construction in CoinSwap is for the HTLC to serve as a security backu=
p in case the cooperative key turnover fails. Lightning don&#39;t have this=
 model as you don&#39;t switch funding transaction ownership.<br><br>&gt; T=
o reduce this risk, A can instead first swap A-&gt;B-&gt;A, then when that =
completes, A-&gt;C-&gt;A.<br>This limits its funding lockup to 1 week.<br><=
br>Okay I think I understand your point. So by intermediating the chain wit=
h the taker you ensure that in case of previous hop failure, taker funds ar=
e only timelocked for the delta of this faulting hop not the whole route. B=
ut still not anchoring onchain the next route segment means that any moment=
 the next maker can exit from the proposed position ?<br><br>That&#39;s int=
eresting, so a) you require all takers to lock their funds onchain before i=
nitiating 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.<br>=C2=A0<br>It might be an interesting construction=
 to explore on its own, minus the downside of producing weird spend pattern=
s due to next hop maker bidding with another party.<br><br>Cheers,<br><br>A=
ntoine<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gm=
ail_attr">Le=C2=A0lun. 24 ao=C3=BBt 2020 =C3=A0=C2=A023:16, ZmnSCPxj &lt;<a=
 href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; a =
=C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><br>
Good morning Antoine,<br>
<br>
<br>
&gt; Note, I think this is independent of picking up either relative or abs=
olute timelocks as what matters is the block delta between two links.<br>
<br>
I believe it is quite dependent on relative locktimes.<br>
Relative locktimes *require* a contract transaction to kick off the relativ=
e locktime period.<br>
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.<br>
<br>
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.<br>
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.<br>
There is no transaction that both participants hold in completely-signed fo=
rm.<br>
<br>
This should remove most of the shenanigans possible, and makes the 30xRBF s=
afe for any range of fees.<br>
I think.<br>
<br>
Since for each PTLC a participant holds only its &quot;own&quot; transactio=
n, it is possible for a participant to define its range of fees for the RBF=
 versions of the transaction it owns, without negotiation with the other pa=
rticipant.<br>
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.<br>
<br>
--<br>
<br>
Private key turnover is still useful even in an absolute-timelock world.<br=
>
<br>
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.<br>
<br>
As a concrete example, suppose A is a taker who wants to route over makers =
B and C.<br>
However, B and C require a CLTV delta of 1 week.<br>
<br>
If A wants to route &quot;directly&quot; A-&gt;B-&gt;C-&gt;A, then if somet=
hing bad happens, it could be looking at having its funds locked for two we=
eks.<br>
<br>
To reduce this risk, A can instead first swap A-&gt;B-&gt;A, then when that=
 completes, A-&gt;C-&gt;A.<br>
This limits its funding lockup to 1 week.<br>
<br>
Private key turnover is useful since as soon as the A-&gt;B-&gt;A swap comp=
letes, it can directly fund the A-&gt;C-&gt;A swap from the B-side funding =
transaction of the A-&gt;B-&gt;A swap.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0A-&gt;B-&gt;A=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 A-&gt;C-&gt;A=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :<br>
=C2=A0 =C2=A0 =C2=A0 A -:-&gt;funding A&amp;B--&gt; B :=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :<br>
=C2=A0 =C2=A0 =C2=A0 B -:-&gt;funding A&amp;B -----:--&gt; funding A&amp;C =
--&gt; C :<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:C-&gt; funding A&amp;C ------:-&gt; to-cold=
=C2=A0 A --&gt;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :<br>
<br>
This increases the number of transactions by 1 per swap beyond the first, c=
ompared to a direct routing A-&gt;B-&gt;C-&gt;A, but this may be worth it f=
or A if the timelocks involved are too big for A.<br>
<br>
With 2p-ECDSA, a funding A&amp;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.<br>
<br>
Without private key turnover, A would have:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 **NO** private key turnover!<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0A-&gt;B-&gt;A=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 A-&gt;C-&gt;A=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0:<br>
=C2=A0 =C2=A0 =C2=A0 A -:-&gt;funding A&amp;B--&gt; B :=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0:<br>
=C2=A0 =C2=A0 =C2=A0 B -:-&gt;funding A&amp;B -----:--&gt; claim A -&gt; fu=
nding A&amp;C --&gt; C :<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C-=
&gt; funding A&amp;C ------:-&gt; to-cold=C2=A0 A --&gt;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0:<br>
<br>
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.<br>
<br>
For reference, this is how it looks like with a single A-&gt;B-&gt;C-&gt;A =
swap with private key turnover:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0A-&gt;B-&gt;C-&gt;A=C2=A0 =
=C2=A0 =C2=A0 |<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:<br>
=C2=A0 =C2=A0 =C2=A0 A -:-&gt;funding A&amp;B--&gt; B :<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:<br>
=C2=A0 =C2=A0 =C2=A0 B -:-&gt;funding B&amp;C -&gt; C :<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:<br>
=C2=A0 =C2=A0 =C2=A0 C -:-&gt;funding A&amp;C -----:-&gt; to-cold A --&gt;<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:<br>
<br>
This is still smaller than in the A-&gt;B-&gt;A, A-&gt;C-&gt;A with private=
 key turnover, by one funding tx per hop.<br>
However, A risks a much higher timelock (twice the timelock).<br>
Thus, A might prefer a lower timelock in exchange for paying for an additio=
nal transaction.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--000000000000eb39cb05ae86a712--