MIME-Version: 1.0
References: <CAPv7TjZGBbf6f1y49HLFD2eNiP5d4e+=dFGqiMFs6jaeYyH-NQ@mail.gmail.com>
 <CAH5Bsr1d57pzmNgakt=Q2M+Ey+PL9jUVUPeJ_aFj0L0TBAHzKw@mail.gmail.com>
 <CAH5Bsr1paP8dmo_z6VoEHYvB_SpD4Piw91LeLJBMgFph7Qrtfg@mail.gmail.com>
 <CAPv7TjYqC73zRQq2yQy9RpeHUUexjSS23uU9VwJvvoRr50p2vA@mail.gmail.com>
In-Reply-To: <CAPv7TjYqC73zRQq2yQy9RpeHUUexjSS23uU9VwJvvoRr50p2vA@mail.gmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Tue, 12 May 2020 13:34:17 +0200
Message-ID: <CAPv7TjaJk5gsyZsZBfbKmjDF5-ijqcONEMtkowb1Y=2D38vRow@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000aefa5505a571d83f"
Subject: Re: [bitcoin-dev] SAS: Succinct Atomic Swap
Precedence: list

--000000000000aefa5505a571d83f
Content-Type: text/plain; charset="UTF-8"

Hi Lloyd,

>In my opinion, this protocol is theoretical breakthrough as well as a
practical protocol. Well done!

Thanks for the kind praise, and for providing a summary of what you think
makes the protocol useful. Your different perspective is undoubtedly useful
for others who are trying to understand it.

>We might call this a "Forced Refund *TLC"

Good description, I like it.

>The advantages that Ruben's two tx protocol has over this is that
timelocks and monitoring is only needed on one of the chains.

Well put, and I agree with your point that the traditional 4 tx protocol
can also be turned into 2 tx with an online requirement. One minor thing to
add is that this would make the 4 tx protocol more clunky in the
non-cooperative case (a 4 tx timeout). In the SAS protocol it comes at no
cost.

Cheers,
Ruben

On Tue, May 12, 2020 at 1:30 PM Ruben Somsen <rsomsen@gmail.com> wrote:

> Hi ZmnSCPxj,
>
> >Would this not work?
>
> I considered and rejected that model for the following reason: there are
> moments where both Alice and Bob can claim the BTC. If they both attempt to
> do so, it also reveals both secrets, causing the LTC to also be claimable
> by both parties. This chaotic scenario is a failure mode that did not seem
> acceptable to me. The revoke transaction was specifically added to mitigate
> that issue (invalidating any attempt of Bob to claim the coins and reveal
> his secret). That said, it doesn't particularly seem in either party's
> interest wait until a moment where two timelocks become valid, so maybe it
> is not quite as bad as I thought. However, it still means that the
> incompetence/malevolence of one party can lead to losses for both parties.
> I have my doubts a gain in privacy in the uncooperative case is worth that
> risk.
>
> Of course it also reverts the protocol to 3 transactions, instead of 2,
> but regardless, not having to watch the chain is probably more practical in
> many cases. As an aside, if both chains support timelocks then we can
> ensure that the more expensive chain only receives one transaction.
>
> >if relative locktimes are used as often as absolute locktimes for
> block-sniping-prevention and a decent Scriptless Script system, then all
> protocol aborts should be doable with no information leaks
>
> I see your point, interesting observation.
>
> >A sidenote as well, that if Alice typically uses an HD wallet, the UTXO
> on the LTC side would not be in that HD, and if Alice wants to cold-store
> the LTC, it should move the money as well into an HD pubkey.
>
> Agreed, I had that listed as one of the disadvantages: "Access to money is
> contingent on remembering secrets (backup complexity)"
>
> Cheers,
> Ruben
>
>
> On Tue, May 12, 2020 at 8:50 AM Lloyd Fournier <lloyd.fourn@gmail.com>
> wrote:
>
>> A quick correction to my post:
>>
>>>
>>> Here's where the truly novel part comes in. Ruben solves this by
>>> extending the standard *TLC contract:
>>> 1. Bob redeem with secret
>>> 2. Alice refund after T1
>>> 3. Bob redeem without secret after T2
>>>
>>> This is actually:
>>
>> 1. Bob redeem with redeem secret
>> 2. Alice refund after T1 with refund secret
>> 3. Bob redeem without secret after T2
>>
>> The fact that Alice reveals a secret when she refunds is crucial.
>>
>> LL
>>
>

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

<div dir=3D"ltr"><div>Hi Lloyd,</div><div><br></div><div>&gt;In my opinion,=
 this protocol is theoretical breakthrough as well as a practical protocol.=
 Well done!<br></div><div><br></div><div>Thanks for the kind praise, and fo=
r providing a summary of what you think makes the protocol useful. Your dif=
ferent perspective is undoubtedly useful for others who are trying to under=
stand it.</div><div><br></div><div>&gt;We might call this a &quot;Forced Re=
fund *TLC&quot;</div><div><br></div><div>Good description, I like it.</div>=
<div><br></div><div>&gt;The advantages that Ruben&#39;s two tx protocol has=
 over this is that timelocks and monitoring is only needed on one of the ch=
ains.=C2=A0=C2=A0=C2=A0<br></div><div><br></div><div>Well put, and I agree =
with your point that the traditional 4 tx protocol can also be turned into =
2 tx with an online requirement. One minor thing to add is that this would =
make the 4 tx protocol more clunky in the non-cooperative case (a 4 tx time=
out). In the SAS protocol it comes at no cost.</div><div><br></div><div>Che=
ers,</div><div>Ruben</div></div><br><div class=3D"gmail_quote"><div dir=3D"=
ltr" class=3D"gmail_attr">On Tue, May 12, 2020 at 1:30 PM Ruben Somsen &lt;=
<a href=3D"mailto:rsomsen@gmail.com">rsomsen@gmail.com</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi Z=
mnSCPxj,<br><br>&gt;Would this not work?<br><br>I considered and rejected t=
hat model for the following reason: there are moments where both Alice and =
Bob can claim the BTC. If they both attempt to do so, it also reveals both =
secrets, causing the LTC to also be claimable by both parties. This chaotic=
 scenario is a failure mode that did not seem acceptable to me. The revoke =
transaction was specifically added to mitigate that issue (invalidating any=
 attempt of Bob to claim the coins and reveal his secret). That said, it do=
esn&#39;t particularly seem in either party&#39;s interest wait until a mom=
ent where two timelocks become valid, so maybe it is not quite as bad as I =
thought. However, it still means that the incompetence/malevolence of one p=
arty can lead to losses for both parties. I have my doubts a gain in privac=
y in the uncooperative case is worth that risk.<br><br>Of course it also re=
verts the protocol to 3 transactions, instead of 2, but regardless, not hav=
ing to watch the chain is probably more practical in many cases. As an asid=
e, if both chains support timelocks then we can ensure that the more expens=
ive chain only receives one transaction.<br><br>&gt;if relative locktimes a=
re used as often as absolute locktimes for block-sniping-prevention and a d=
ecent Scriptless Script system, then all protocol aborts should be doable w=
ith no information leaks<br><br>I see your point, interesting observation.<=
br><br>&gt;A sidenote as well, that if Alice typically uses an HD wallet, t=
he UTXO on the LTC side would not be in that HD, and if Alice wants to cold=
-store the LTC, it should move the money as well into an HD pubkey.<br><br>=
Agreed, I had that listed as one of the disadvantages: &quot;Access to mone=
y is contingent on remembering secrets (backup complexity)&quot;<div><br></=
div><div>Cheers,</div><div>Ruben</div></div><br><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 12, 2020 at 8:50 AM L=
loyd Fournier &lt;<a href=3D"mailto:lloyd.fourn@gmail.com" target=3D"_blank=
">lloyd.fourn@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">A quick correction=
 to my post:</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div><br></div><div>H=
ere&#39;s where the truly novel part comes in. Ruben solves this by extendi=
ng the standard *TLC contract:</div><div>1. Bob redeem with secret</div><di=
v>2. Alice refund after T1</div><div>3. Bob redeem without secret after T2<=
/div><div><br></div></div></div></blockquote><div>This is actually:</div><d=
iv><br></div><div>1. Bob redeem with redeem secret</div><div>2. Alice refun=
d after T1 with refund secret</div><div>3. Bob redeem without secret after =
T2</div><div><br></div><div>The fact that Alice reveals a secret when she r=
efunds is crucial.</div><div><br></div><div>LL=C2=A0</div></div></div>
</blockquote></div>
</blockquote></div>

--000000000000aefa5505a571d83f--