MIME-Version: 1.0
References: <82d90d57-ad07-fc7d-4aca-2b227ac2068d@riseup.net>
 <CAPv7TjY9h8n-nK_CPiYCWYDcbXpT1gfRMQDgf9VUkcR532rxOw@mail.gmail.com>
 <VxL93WE7bDrK1riquTWTTEgJj9mDQ4W5CuhOgdnnDPeidw2ho6evVh4cLZLz0jEYMqejaD1tiLULVTXkNRbI5A7wSwV49qSwnXcTWCDJ96E=@protonmail.com>
 <CAPv7TjZn6+j10a_X_vCG3Qn1Fv19uidw50Cf38NNUvp8m+uh2w@mail.gmail.com>
 <WKC6zH0X8ad2bK_JwklQegyJBKf5rTp1Ub_fPPPkS_EeIkIoc_wcRd9k3a_aq6sFIZ3-gOtG9ubWq3gTPG5fZW5aA1s_2C8-emEsr67Qxjk=@protonmail.com>
In-Reply-To: <WKC6zH0X8ad2bK_JwklQegyJBKf5rTp1Ub_fPPPkS_EeIkIoc_wcRd9k3a_aq6sFIZ3-gOtG9ubWq3gTPG5fZW5aA1s_2C8-emEsr67Qxjk=@protonmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Mon, 1 Jun 2020 12:19:38 +0200
Message-ID: <CAPv7TjZf60VPKXL2s8bFXEF1kUGS-LMEpuURf4O4CPM3kFuyZQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000009e802305a70322c7"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Design for a CoinSwap implementation for
 massively improving Bitcoin privacy and fungibility
Precedence: list

--0000000000009e802305a70322c7
Content-Type: text/plain; charset="UTF-8"

Hi ZmnSCPxj,

>If Alice is paying to a non-SAS aware payee

Yeah, I agree that this use case is not possible without a third
transaction (preferably from the timelocked side, in the case of SAS). My
point was merely that you can swap and simultaneously merge some of your
outputs into the post-swap non-timelocked output, though perhaps that is
not very useful.

Cheers,
Ruben



On Mon, Jun 1, 2020 at 4:34 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Ruben,
>
>
> >
> > That assumes there will be a second transaction. With SAS I believe we
> can avoid that, and make it look like this:
> >
> >              +---+
> >     Alice ---|   |--- Bob
> >     Alice ---|   |
> >       Bob ---|   |
> >              +---+
>
> If Alice is paying to a non-SAS aware payee that just provides an onchain
> address (i.e. all current payees today), then the 2-of-2 output it gets
> from the swap (both of whose keys it learns at the end of the swap) is
> **not** the payee onchain address.
> And it cannot just hand over both private keys, because the payee will
> still want unambiguous ownership of the entire UTXO.
> So it needs a second transaction anyway.
> (with Schnorr then Alice and payee Carol can act as a single entity/taker
> to Bob, a la Lightning Nodelets using Composable MuSig, but that is a
> pretty big increase in protocol complexity)
>
> If Alice does not want to store the remote-generated privkey as well, and
> use only an HD key, then it also has to make the second transaction.
> Alice might want to provide the same assurances as current wallets that
> memorizing a 12-word or so mnemonic is sufficient backup for all the funds
> (other than funds currently being swapped), and so would not want to leave
> any funds in a 2-of-2.
>
> If Bob is operating as a maker, then it also cannot directly use the
> 2-of-2 output it gets from the swap, and has to make a new 2-of-2 output,
> for the *next* taker that arrives to request its services.
>
> So there is always going to be a second transaction in a SwapMarket
> system, I think.
>
>
> What SAS / private key turnover gets us is that there is not a *third*
> transaction to move from a 1-of-1 to the next address that makers and
> takers will be moving anyway, and that the protocol does not have to add
> communication provisions for special things like adding maker inputs or
> specifying all destination addresses for the second stage and so on,
> because those can be done unilaterally once the private key is turned over.
>
>
> > >A thing I have been trying to work out is whether SAS can be done with
> more than one participant, like in S6
> >
> > S6 requires timelocks for each output in order to function, so I doubt
> it can be made to work with SAS.
>
> Hmmm right right.
>
> Naively it seems both chaining SAS/private key turnover to multiple
> makers, and a multi-maker S6 augmented with private key turnover, would
> result in the same number of transactions onchain, but I probably have to
> go draw some diagrams or something first.
>
> But S6 has the mild advantage that all the funding transactions paying to
> 2-of-2s *can* appear on the same block, whereas chaining swaps will have a
> particular order of when the transactions appear onchain, which might be
> used to derive the order of swaps.
> On the other hand, funds claiming in S6 is also ordered in time, so
> someone paying attention to the mempool could guess as well the order of
> swaps.
>
>
> Regards,
> ZmnSCPxj
>

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

<div dir=3D"ltr">Hi ZmnSCPxj,<div><br></div><div>&gt;If Alice is paying to =
a non-SAS aware payee<br></div><div><br></div><div>Yeah, I agree that this =
use case is not possible without a third transaction (preferably from the t=
imelocked side, in the case of SAS). My point was merely that you can swap =
and simultaneously merge some of your outputs into the post-swap non-timelo=
cked output, though perhaps that is not very useful.</div><div><br></div><d=
iv>Cheers,</div><div>Ruben</div><div><br></div><div><br></div></div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jun 1=
, 2020 at 4:34 AM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">Z=
mnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">Good morning Ruben,<br>
<br>
<br>
&gt;<br>
&gt; That assumes there will be a second transaction. With SAS I believe we=
 can avoid that, and make it look like this:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---+<br>
&gt; =C2=A0 =C2=A0 Alice ---| =C2=A0 |--- Bob<br>
&gt; =C2=A0 =C2=A0 Alice ---| =C2=A0 |<br>
&gt; =C2=A0 =C2=A0 =C2=A0 Bob ---| =C2=A0 |<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---+<br>
<br>
If Alice is paying to a non-SAS aware payee that just provides an onchain a=
ddress (i.e. all current payees today), then the 2-of-2 output it gets from=
 the swap (both of whose keys it learns at the end of the swap) is **not** =
the payee onchain address.<br>
And it cannot just hand over both private keys, because the payee will stil=
l want unambiguous ownership of the entire UTXO.<br>
So it needs a second transaction anyway.<br>
(with Schnorr then Alice and payee Carol can act as a single entity/taker t=
o Bob, a la Lightning Nodelets using Composable MuSig, but that is a pretty=
 big increase in protocol complexity)<br>
<br>
If Alice does not want to store the remote-generated privkey as well, and u=
se only an HD key, then it also has to make the second transaction.<br>
Alice might want to provide the same assurances as current wallets that mem=
orizing a 12-word or so mnemonic is sufficient backup for all the funds (ot=
her than funds currently being swapped), and so would not want to leave any=
 funds in a 2-of-2.<br>
<br>
If Bob is operating as a maker, then it also cannot directly use the 2-of-2=
 output it gets from the swap, and has to make a new 2-of-2 output, for the=
 *next* taker that arrives to request its services.<br>
<br>
So there is always going to be a second transaction in a SwapMarket system,=
 I think.<br>
<br>
<br>
What SAS / private key turnover gets us is that there is not a *third* tran=
saction to move from a 1-of-1 to the next address that makers and takers wi=
ll be moving anyway, and that the protocol does not have to add communicati=
on provisions for special things like adding maker inputs or specifying all=
 destination addresses for the second stage and so on, because those can be=
 done unilaterally once the private key is turned over.<br>
<br>
<br>
&gt; &gt;A thing I have been trying to work out is whether SAS can be done =
with more than one participant, like in S6<br>
&gt;<br>
&gt; S6 requires timelocks for each output in order to function, so I doubt=
 it can be made to work with SAS.<br>
<br>
Hmmm right right.<br>
<br>
Naively it seems both chaining SAS/private key turnover to multiple makers,=
 and a multi-maker S6 augmented with private key turnover, would result in =
the same number of transactions onchain, but I probably have to go draw som=
e diagrams or something first.<br>
<br>
But S6 has the mild advantage that all the funding transactions paying to 2=
-of-2s *can* appear on the same block, whereas chaining swaps will have a p=
articular order of when the transactions appear onchain, which might be use=
d to derive the order of swaps.<br>
On the other hand, funds claiming in S6 is also ordered in time, so someone=
 paying attention to the mempool could guess as well the order of swaps.<br=
>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--0000000000009e802305a70322c7--