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 03B87C0176 for ; Mon, 1 Jun 2020 02:34:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id BDDC42042E for ; Mon, 1 Jun 2020 02:34:12 +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 z9uGekJ2S9Ns for ; Mon, 1 Jun 2020 02:34:10 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch [185.70.40.141]) by silver.osuosl.org (Postfix) with ESMTPS id 176E220343 for ; Mon, 1 Jun 2020 02:34:09 +0000 (UTC) Date: Mon, 01 Jun 2020 02:34:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1590978847; bh=F8Jn/oebJ8bhS+rpEGEq9sCJmxxIFSn6XuqBqfqTusM=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=V0utzoA4dPcTe4yw9dhmCAfF8Hc62Xmk4cLWT4IoUmCmfvboMklVS3ICSlpd5aCUd fOZiLrNvY6Z8FBcQ+FbGLqLVDz9thnIoKPO79jev0dd5FUJ/OyhKKIe+6aFRMw4/4w SZEu/VzZfC6uXWrJJnTEeDpRB30Uh+N/iUCaT/cw= To: Ruben Somsen From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <82d90d57-ad07-fc7d-4aca-2b227ac2068d@riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 02:34:13 -0000 Good morning Ruben, > > That assumes there will be a second transaction. With SAS I believe we ca= n 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 m= ore 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