path: root/b4/beb000e11ea0e96397c9f68f6618e0cb168f50

Return-Path: <rsomsen@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id BF000C016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 15 May 2020 19:47:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id A1A37204FF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 15 May 2020 19:47:51 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id EgnTzcBZln+X
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 15 May 2020 19:47:46 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com
 [209.85.208.41])
 by silver.osuosl.org (Postfix) with ESMTPS id 2F733204DE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 15 May 2020 19:47:46 +0000 (UTC)
Received: by mail-ed1-f41.google.com with SMTP id k19so3176939edv.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 15 May 2020 12:47:46 -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=3PrMEd0Or76eHT/WmtzTXWFHBNLqXnqfJTMoQlnlGj4=;
 b=sfLP6L8OcELbE4o9n85fPQfGc5wBOcmsfQP/jkTrGp/K6QrB17hHV7xpTZYHQZ6XWQ
 7T8KLiHq7Ck/RQmrvpXtgKn0d4PqwPNzkr1V3DdpQLxtOpg53pEkI+J0/v7fQx0Ujhzr
 /goPm5cGQJIqJ2mLDY4xz6WlMoQdfiS63P18GnbjBXK9d9zh1Q+Bkniv0jDzdysODelY
 avzw+HurE0D2nx2Ha2//7gdgKuqR+hde15l5jCeT2F0/3fHDwJhE3zMR6moV80oNv5po
 JaU79v1gGhNWlffm12OUrvbxQgrGs7LhOP0PbwbX7joSDIy2BA4yuRTYTjWn3A3DAEf0
 SmCw==
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=3PrMEd0Or76eHT/WmtzTXWFHBNLqXnqfJTMoQlnlGj4=;
 b=BdBgkC2GX47bqi7bupq9MOY12Lw8VM37IPJAAWO4b3+vXx2C+UlmQpNLz322lKkZbI
 X3+aF2eogM7ucAd9iI1b6ljQit58TqNkNyWZ5sw9c2OLwg9T2cRs7kh81UIFsaGLCLKJ
 fhIz9WD7H+2TWC2L/U/NRtWIZyxfFgk07DsrPPnrcZ5MK00J4LCKyfT1lRo7NuvvzAD4
 Rwcy4JiDiGjxLJxHW8yjbciI/AcM53fJ/TILg5BABmTH/XYa1mpzj+ZRRGauAh2WptZO
 Q5+0P8OYMAQ8X00g4uK5qhm5PjXv4nsviLcCYot0PwkX4+fnGyA0V8bSHe5vEfeDICC8
 H4Mw==
X-Gm-Message-State: AOAM533D7+qWnk6I6GT9hkKV0ApHUAf9V3s7cAvhbtGYExvtr127keMF
 B2oJnkRh2RN4UNWOzYBDpzrYVdBJ69JXEqE1ni4=
X-Google-Smtp-Source: ABdhPJw3IEMqKF/H59ipbk0AFDYuyxmLLFK8IiUn3caCCZEkv5uMrA+ik9FKTjIzRKolsYWv/xHAgHJruIpWl8lF+tU=
X-Received: by 2002:a05:6402:1bd9:: with SMTP id
 ch25mr4222139edb.15.1589572064588; 
 Fri, 15 May 2020 12:47:44 -0700 (PDT)
MIME-Version: 1.0
References: <CAPv7TjZGBbf6f1y49HLFD2eNiP5d4e+=dFGqiMFs6jaeYyH-NQ@mail.gmail.com>
 <CAPv7TjYqC73zRQq2yQy9RpeHUUexjSS23uU9VwJvvoRr50p2vA@mail.gmail.com>
 <Mpqd20ZM9-93dIIhe1yS4QEGKmzT-uuBrAn1e4omDbA1YJvXrEmZ3IZeoz90s5AHVLAdYwF0PhxgMZwqDdHxQ0UQw2eEEytngEXSsXeLM14=@protonmail.com>
 <CAPv7TjbfuV1YvgTS4pjr_56R_-=spb9DzPwqP1HFCBOZpSOq8Q@mail.gmail.com>
 <2-ZZw_6q-EBo5DmIK5PtzWCE9zd9FdNtYuhFf84FKxRHwmL7g7kA9YvYB9iqFFkGy_xoXARzRW8hiZa-ZcLPWeZ60PNMQc9yMdZLnTsp1yo=@protonmail.com>
 <CAPv7TjZAv_tVn=Wxf3LpfMmAzj8+mWiLr+7HMjjNArD7ThKO_A@mail.gmail.com>
 <CAPv7TjYewKe=Gt8io+uGNzeKmAq758vH9aB2OpFt=rGth8DZEg@mail.gmail.com>
 <oIiSWK9E-M53lQD3BxO8vQBHzZ7vUSISzDElSaA0v3BFS4_WeFAHNybHttJLstlAiz6Xem4VWy9Ktp6hgklsPqkvqnKVMOUAuA_aKpjOFLA=@protonmail.com>
 <CAPv7TjaG3jxCDv5PtSeLeXi3Emo1_hvgYP1KEQg8+LU41SUqqQ@mail.gmail.com>
 <Wi0Hnr40e1Zhe_F5SfprEkMgCNmcvhJsGAdlEpJDWO1kKsGIsg0hEHKA-YyeMt7NBYa7nMPiePpOEjefcO6epuLVfyuweXJjjX-YfRpw4DQ=@protonmail.com>
In-Reply-To: <Wi0Hnr40e1Zhe_F5SfprEkMgCNmcvhJsGAdlEpJDWO1kKsGIsg0hEHKA-YyeMt7NBYa7nMPiePpOEjefcO6epuLVfyuweXJjjX-YfRpw4DQ=@protonmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Fri, 15 May 2020 21:47:29 +0200
Message-ID: <CAPv7TjaLMiYMaP2nWkh-Q0itORYHQ1ah9cVR4oGu36d11Ts5Xg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000041381d05a5b51688"
X-Mailman-Approved-At: Fri, 15 May 2020 19:48:41 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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: Fri, 15 May 2020 19:47:51 -0000

--00000000000041381d05a5b51688
Content-Type: text/plain; charset="UTF-8"

Hi ZmnSCPxj,

>The proper response here is that Bob should broadcast success tx before
the refund tx #1 becomes valid.

That's right. And even if Bob neglects to do that, it still won't cause
chaos for Alice as long as she chooses the path for refund tx #2.

>at least part of the fund must be lost in fees and Bob can still suffer a
small loss

Yes, after protocol completion Alice can broadcast one more transaction
that is paid for by Bob, and Bob would have to respond with another
transaction of his own. As you said, bring-your-own-fees would be better
here (also see FAQ question "Can't Alice just publish the revoke_tx after
protocol completion?").

>the server should take Alice position and the client should take Bob
position [...] a client will want to make multiple CoinSwaps in sequence

I think this can be summarized as: whoever is planning to spend their UTXO
first should be Bob.

In your protocol it might make sense for the server and client to swap
roles depending on what the client plans to do. If they plan to swap again
soon, they can be Bob, if they don't, they're Alice.

But there's also another consideration: whoever is less likely to abort the
protocol should be Bob.

Clients can be unreliable. If clients are Bob, they can waste Alice's
resources by initiating the protocol and aborting (which imo is more severe
than the risk of the revoke tx getting published). Whereas if the client is
Alice, she'd be first to commit resources before the server commits
anything.

>ensure the txo is spent before refund tx #1 becoms valid

Yes, this is important. Luckily, pretty much all the options we discussed
could be applied here, including sighash_single + anyonecanpay. In your
specific example this seems preferable to adding a change output and making
multiple transactions with different RBF amounts, especially since this
only concerns a situation where the protocol stalls at a specific step
(after the success tx).

And I agree with your general assessment that three transactions are
required in order to pay a third party. This could be done from either side
of the swap, but of course it makes more sense to pay from the timelock
side and get rid of the online requirement.

Cheers,
Ruben

On Fri, May 15, 2020 at 6:39 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Ruben,
>
> > Hi ZmnSCPxj,
> >
> > >on completion of the protocol, if Bob lets the refund tx#1 become valid
> (i.e. does not spend the BTC txo) then Alice can broadcast it, putting both
> their funds into chaos
> >
> > You forget, refund tx #1 has a script (which btw won't be visible with
> taproot): "Alice & Bob OR Alice in +1 day" (relative) so if Alice
> broadcasts it after protocol completion, she is just giving Bob the key to
> her LTC (note: if she's wise she'd move the LTC beforehand), but Bob
> doesn't lose the BTC because he has both keys and can just react before the
> relative timelock expires. No chaos.
>
> Ah, that explains the existence of the Alice && Bob clause in that output
> then.
>
> The attack is now as follows:
>
> * Alice completes the protocol up to handing over `sigSuccessAlice` to Bob.
> * Bob returns the `secretBob`.
> * Alice stalls the protocol and never sends the `Alice` privkey, and waits
> for 1 day, then sneaks the refund tx #1 and spends the LTC via direct miner
> collusion.
>
> The proper response here is that Bob should broadcast success tx before
> the refund tx #1 becomes valid.
> (Which I think is the point: chaos can only occur if you let backouts
> become valid, and it is the best policy for Bob to just spend the BTC txo
> well before the timeout.
> Even if the protocol is completed, without a bring-your-own-fees that lets
> you malleate the tx (i.e. CPFP hooks still require the transction itself to
> reduce the fund by at least the minimum feerate), at least part of the fund
> must be lost in fees and Bob can still suffer a small loss of funds.)
>
> --
>
> Tangentially, I now think in the case of client-server CoinSwap, the
> server should take Alice position and the client should take Bob position.
>
> Suppose a client wants to do some mixing of its own received coins.
> It should not depend on only one server, as the server might secretly be a
> surveillor (or hacked by a surveillor) and recording swaps.
> Thus, a client will want to make multiple CoinSwaps in sequence, to
> obscure its history.
>
> (Do note the objections under "Directionality" in
> https://zmnscpxj.github.io/bitcoin/multiswap.html though; a counter to
> this objections is that the analysis there is only applicable if the
> surveillor already identified the CoinSwap sequence, but hopefully the
> increased steganography of CoinSwaps means they are not identifiable
> anyway.)
>
> Since Bob really should spend its received coin before a timeout, it is
> best for Bob to be the client; it is likely that the client will need to
> swap "soon" again, meaning it has to redirect the funds to a new 2-of-2
> anyway.
>
> For the final swap, the client can then spend the final coins to an HD
> wallet it controls, reducing the key backup load on the client to be the
> same as normal HD wallets.
> Presumably the server in this situation has greater ability to dynamically
> update its backups to include key backups for `secretAlice` keys.
>
> Further, if the client program has the policy that all spends out of the
> wallet must be done via a swap (similar to a rule imposed by JoinMarket
> where sendpayment.py always does 1 CoinJoin), then this still matches well
> with the requirement on Bob to spend the fund before the first timeout of
> refund tx #1.
>
> If the client needs to spend to a classic, address-using service, then
> nothing in the SAS protocol allows Alice to receive its funds directly into
> a specific third-party address.
> However, Bob can hand over a specific third-party address to use in the
> success tx.
> Indeed, the SAS protocol can be modified so that Bob can specify a set of
> address/value pairs to be put in the success tx instead of just Bob pubkey;
> for example, Bob might swap more than the amoutn that needs to be paid to
> the third-party service, in order to give some additional leeway later for
> RBF once Alice hands over the Alice privkey and Bob can remake the success
> tx (and more importantly, ensure the txo is spent before refund tx #1
> becoms valid).
>
>
> Regards,
> ZmnSCPxj
>

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

<div dir=3D"ltr">Hi ZmnSCPxj,<div><br></div><div>&gt;The proper response he=
re is that Bob should broadcast success tx before the refund tx #1 becomes =
valid.<br></div><div><br></div><div>That&#39;s right. And even if Bob negle=
cts to do that, it still won&#39;t cause chaos for Alice as long as she cho=
oses the path for refund tx #2.</div><div><br></div><div>&gt;at least part =
of the fund must be lost in fees and Bob can still suffer a small loss</div=
><div><br></div><div>Yes, after protocol completion Alice can broadcast one=
 more transaction that is paid for by Bob, and Bob would have to respond wi=
th another transaction of his own. As you said, bring-your-own-fees would b=
e better here (also see FAQ question &quot;Can&#39;t Alice just publish the=
 revoke_tx after protocol completion?&quot;).</div><div><br></div><div>&gt;=
the server should take Alice position and the client should take Bob positi=
on [...] a client will want to make multiple CoinSwaps in sequence<br></div=
><div><br></div><div>I think this can be summarized as: whoever is planning=
 to spend their UTXO first should be Bob.<br></div><div><br></div><div>In y=
our protocol it might make sense for the server and client to swap roles de=
pending on what the client plans to do. If they plan to swap again soon, th=
ey can be Bob, if they don&#39;t, they&#39;re Alice.</div><div><br></div><d=
iv>But there&#39;s also another consideration: whoever is less likely to ab=
ort the protocol should be Bob.</div><div><br></div><div>Clients can be unr=
eliable. If clients are Bob, they can waste Alice&#39;s resources by initia=
ting the protocol and aborting (which imo is more severe than the risk of t=
he revoke tx getting published). Whereas if the client is Alice, she&#39;d =
be first to commit resources before the server commits anything.</div><div>=
<br></div><div>&gt;ensure the txo is spent before refund tx #1 becoms valid=
</div><div><br></div><div>Yes, this is important. Luckily, pretty much all =
the options we discussed could be applied here, including sighash_single=C2=
=A0+ anyonecanpay. In your specific example this seems preferable to adding=
 a change output and making multiple transactions with different RBF amount=
s, especially since this only concerns a situation where the protocol stall=
s at a specific step (after the success tx).</div><div><br></div><div>And I=
 agree with your general assessment that three transactions are required in=
 order to pay a third party. This could be done from either side of the swa=
p, but of course it makes more sense to pay from the timelock side and get =
rid of the online requirement.</div><div><br></div><div>Cheers,</div><div>R=
uben</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gm=
ail_attr">On Fri, May 15, 2020 at 6:39 AM ZmnSCPxj &lt;<a href=3D"mailto:Zm=
nSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">Good morning Ruben,<br>
<br>
&gt; Hi ZmnSCPxj,<br>
&gt;<br>
&gt; &gt;on completion of the protocol, if Bob lets the refund tx#1 become =
valid (i.e. does not spend the BTC txo) then Alice can broadcast it, puttin=
g both their funds into chaos<br>
&gt;<br>
&gt; You forget, refund tx #1 has a script (which btw won&#39;t be visible =
with taproot): &quot;Alice &amp; Bob OR Alice in=C2=A0+1 day&quot; (relativ=
e) so if Alice broadcasts it after protocol completion, she is just giving =
Bob the key to her LTC (note: if she&#39;s wise she&#39;d move the LTC befo=
rehand), but Bob doesn&#39;t lose the BTC because he has both keys and can =
just react before the relative timelock expires. No chaos.<br>
<br>
Ah, that explains the existence of the Alice &amp;&amp; Bob clause in that =
output then.<br>
<br>
The attack is now as follows:<br>
<br>
* Alice completes the protocol up to handing over `sigSuccessAlice` to Bob.=
<br>
* Bob returns the `secretBob`.<br>
* Alice stalls the protocol and never sends the `Alice` privkey, and waits =
for 1 day, then sneaks the refund tx #1 and spends the LTC via direct miner=
 collusion.<br>
<br>
The proper response here is that Bob should broadcast success tx before the=
 refund tx #1 becomes valid.<br>
(Which I think is the point: chaos can only occur if you let backouts becom=
e valid, and it is the best policy for Bob to just spend the BTC txo well b=
efore the timeout.<br>
Even if the protocol is completed, without a bring-your-own-fees that lets =
you malleate the tx (i.e. CPFP hooks still require the transction itself to=
 reduce the fund by at least the minimum feerate), at least part of the fun=
d must be lost in fees and Bob can still suffer a small loss of funds.)<br>
<br>
--<br>
<br>
Tangentially, I now think in the case of client-server CoinSwap, the server=
 should take Alice position and the client should take Bob position.<br>
<br>
Suppose a client wants to do some mixing of its own received coins.<br>
It should not depend on only one server, as the server might secretly be a =
surveillor (or hacked by a surveillor) and recording swaps.<br>
Thus, a client will want to make multiple CoinSwaps in sequence, to obscure=
 its history.<br>
<br>
(Do note the objections under &quot;Directionality&quot; in <a href=3D"http=
s://zmnscpxj.github.io/bitcoin/multiswap.html" rel=3D"noreferrer" target=3D=
"_blank">https://zmnscpxj.github.io/bitcoin/multiswap.html</a> though; a co=
unter to this objections is that the analysis there is only applicable if t=
he surveillor already identified the CoinSwap sequence, but hopefully the i=
ncreased steganography of CoinSwaps means they are not identifiable anyway.=
)<br>
<br>
Since Bob really should spend its received coin before a timeout, it is bes=
t for Bob to be the client; it is likely that the client will need to swap =
&quot;soon&quot; again, meaning it has to redirect the funds to a new 2-of-=
2 anyway.<br>
<br>
For the final swap, the client can then spend the final coins to an HD wall=
et it controls, reducing the key backup load on the client to be the same a=
s normal HD wallets.<br>
Presumably the server in this situation has greater ability to dynamically =
update its backups to include key backups for `secretAlice` keys.<br>
<br>
Further, if the client program has the policy that all spends out of the wa=
llet must be done via a swap (similar to a rule imposed by JoinMarket where=
 sendpayment.py always does 1 CoinJoin), then this still matches well with =
the requirement on Bob to spend the fund before the first timeout of refund=
 tx #1.<br>
<br>
If the client needs to spend to a classic, address-using service, then noth=
ing in the SAS protocol allows Alice to receive its funds directly into a s=
pecific third-party address.<br>
However, Bob can hand over a specific third-party address to use in the suc=
cess tx.<br>
Indeed, the SAS protocol can be modified so that Bob can specify a set of a=
ddress/value pairs to be put in the success tx instead of just Bob pubkey; =
for example, Bob might swap more than the amoutn that needs to be paid to t=
he third-party service, in order to give some additional leeway later for R=
BF once Alice hands over the Alice privkey and Bob can remake the success t=
x (and more importantly, ensure the txo is spent before refund tx #1 becoms=
 valid).<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--00000000000041381d05a5b51688--