From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 25BA6C0176 for ; 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 ; 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 ; 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 ; Mon, 1 Jun 2020 10:19:52 +0000 (UTC) Received: by mail-ed1-f44.google.com with SMTP id g9so6824400edw.10 for ; 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> In-Reply-To: From: Ruben Somsen Date: Mon, 1 Jun 2020 12:19:38 +0200 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="0000000000009e802305a70322c7" X-Mailman-Approved-At: Mon, 01 Jun 2020 10:23:13 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
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 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.

Cheers,
Ruben



On Mon, Jun 1= , 2020 at 4:34 AM ZmnSCPxj <Z= mnSCPxj@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:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---+
> =C2=A0 =C2=A0 Alice ---| =C2=A0 |--- Bob
> =C2=A0 =C2=A0 Alice ---| =C2=A0 |
> =C2=A0 =C2=A0 =C2=A0 Bob ---| =C2=A0 |
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---+

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.
And it cannot just hand over both private keys, because the payee will stil= l 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 t= o 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 u= se 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 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.

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


> >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 som= e 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 p= articular order of when the transactions appear onchain, which might be use= d 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--