path: root/52/f9bd41ea06bcd40f86a5666155153241e0c982

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 25BA6C0176
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  1 Jun 2020 10:19:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id 1F36122DC7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  1 Jun 2020 10:19:54 +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 U0T3+zz9f3KI
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  1 Jun 2020 10:19:53 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com
 [209.85.208.44])
 by silver.osuosl.org (Postfix) with ESMTPS id C806B22795
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  1 Jun 2020 10:19:52 +0000 (UTC)
Received: by mail-ed1-f44.google.com with SMTP id g9so6824400edw.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 01 Jun 2020 03:19:52 -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=bEH3Ggxd12bMP6DNyLvKEBB80netoEJ+YTIs4cbwjhY=;
 b=C4JGsU9JTgc4A89vc8Ex8IB5NzmFDfJ4bYTDxp2nbGO+vJJewWgJSYARxSMXJ5jZxj
 0aZUOZl2WSIlIDWUJFVEgqYFSiay8x0rNJ0apbOV6PuP21Q+OhKTjgR84pcr9XMeEOX2
 oheHhr0dLn4NydFPa37bJveUjiW3+Fo0MnT3sjPTpnSVCxAX4EN+eKbnbLIegjtq+1CU
 MTSVh7X4NvO6SHBcQDHl09GXfq3IaWFL8IFxXBwT5X0qdGV3dJXIOLHZ1LisDSpk8Hb3
 CL9GrdhNY5q8ZylJ2qMRcPBvzlQcxRmz5ivVvNrSfZOHNuhX4VBbQFV+NJGVJLAbSSo4
 g9rw==
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=bEH3Ggxd12bMP6DNyLvKEBB80netoEJ+YTIs4cbwjhY=;
 b=n03iMgZqcQ+/KF6YHY17eUUu7DgINnquPtggNKWbEReiMGNqecyC+bClVK8GkcFl4C
 BI8tbY23okc6Q8FVeI/DsxGlA0bjtiMkyWAEqAhtYDCwwbgoo3pflq7AKNWgJTGhYLqd
 b0hvSX2XccrI0Ina7mqc8wLlnT3FH5G6Sjc+yU24/5fUQQPSBCA/eu4Cq8VoFaf1yZF5
 tjNwbdV9lU4alHBTCAMvoPdhrYP1m9zqG1hqWGxdI4+JnHhA7MMXlzD5dPfePYxTu8GU
 MtUTHlu8nGrEk0yusmeXy9Li83EtMka0vBgwor4MoLei6RsA+MLfXvAQ92A4XtAgdRzf
 TDuQ==
X-Gm-Message-State: AOAM531Q0WjmlrNEAMS5TLBvqL9ZmJyELKzQvcvpUNYz8C+yRrerC0bR
 V32gTTBC1H2K6PXip681tZCVrWBnk/rN1V+8iyk=
X-Google-Smtp-Source: ABdhPJxpFDp2CL9AkCnjz9af+o5ZOS9YS0SdZFIVgEOnwi5/3zRtz2QMTGqFjzR1dH8HveFt3YqFXrsjIfe7cN+lrMI=
X-Received: by 2002:a05:6402:19a9:: with SMTP id
 o9mr19880160edz.205.1591006791105; 
 Mon, 01 Jun 2020 03:19:51 -0700 (PDT)
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"
X-Mailman-Approved-At: Mon, 01 Jun 2020 10:23:13 +0000
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
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: Mon, 01 Jun 2020 10:19:54 -0000

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