ee362132ee008223eda8a15c85be3579cb99c4
1 Return-Path: <ZmnSCPxj@protonmail.com> 2 Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) 3 by lists.linuxfoundation.org (Postfix) with ESMTP id 23E72C016F 4 for <bitcoin-dev@lists.linuxfoundation.org>; 5 Fri, 12 Jun 2020 08:39:47 +0000 (UTC) 6 Received: from localhost (localhost [127.0.0.1]) 7 by hemlock.osuosl.org (Postfix) with ESMTP id 199118943A 8 for <bitcoin-dev@lists.linuxfoundation.org>; 9 Fri, 12 Jun 2020 08:39:47 +0000 (UTC) 10 X-Virus-Scanned: amavisd-new at osuosl.org 11 Received: from hemlock.osuosl.org ([127.0.0.1]) 12 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) 13 with ESMTP id F-WbgtR9rpYe 14 for <bitcoin-dev@lists.linuxfoundation.org>; 15 Fri, 12 Jun 2020 08:39:45 +0000 (UTC) 16 X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 17 Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch 18 [185.70.40.138]) 19 by hemlock.osuosl.org (Postfix) with ESMTPS id 2F472893B9 20 for <bitcoin-dev@lists.linuxfoundation.org>; 21 Fri, 12 Jun 2020 08:39:45 +0000 (UTC) 22 Date: Fri, 12 Jun 2020 08:39:35 +0000 23 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; 24 s=protonmail; t=1591951182; 25 bh=Jtpv+5F2PArLWO5cH4wDZH8u7IFWstHpvaZUIFLZHUY=; 26 h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; 27 b=iI6mbWj4KdbMbsuMWWjwMjsbiP3WJHCgsyicbyBeoJE4apQIGUSxtkxkwBg5QcNQI 28 lFgpOwJbcmUIMwuCtrC1wdNFoW7z/oWccVu/WuReSp0rn5S3xAP0H4yuprTsCingpe 29 LqB2l1aI1O3e9V7QvGbt7SImXL6doySJv4wYCazs= 30 To: Antoine Riard <antoine.riard@gmail.com>, 31 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> 32 From: ZmnSCPxj <ZmnSCPxj@protonmail.com> 33 Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> 34 Message-ID: <7cWQJzkWNEZCI2fYYrJCFxrmGfDGFAtsOyGpXRmB-g4Qhm2jzhyxLtuOIpJAr2CMJjAjri12lmR-h96ev3NWqaTgDtc_NN0yhyVxuIlBuzU=@protonmail.com> 35 In-Reply-To: <CALZpt+FqAWCAqCLF2HsajL84sOvst_X9_34bb_tvUxLFw=HTAA@mail.gmail.com> 36 References: <CALZpt+FqAWCAqCLF2HsajL84sOvst_X9_34bb_tvUxLFw=HTAA@mail.gmail.com> 37 MIME-Version: 1.0 38 Content-Type: text/plain; charset=utf-8 39 Content-Transfer-Encoding: quoted-printable 40 Subject: Re: [bitcoin-dev] CoinPool, 41 exploring generic payment pools for Fun and Privacy 42 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org 43 X-Mailman-Version: 2.1.15 44 Precedence: list 45 List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> 46 List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 47 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> 48 List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> 49 List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> 50 List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> 51 List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 52 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> 53 X-List-Received-Date: Fri, 12 Jun 2020 08:39:47 -0000 54 55 Good morning Antoine and Gleb, 56 57 I have not studied the proposal in close detail yet, but anyway, my main ta= 58 keaway roughly is: 59 60 * The core of CoinPool is some kind of multiparticipant (N > 2) offchain up= 61 date mechanism (Decker-Wattenhofer or Decker-Russell-Osuntokun). 62 * The output at each state of the update mechanism is some kind of splitt= 63 ing construction (which I have not studied in detail). 64 * At each update of the state, all participants must sign off on the new = 65 state. 66 67 It seems to me that it would be possible to use a [WabiSabi protocol](https= 68 ://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017969.html) d= 69 uring negotiation of a new state. 70 71 Now, WabiSabi is a client-server protocol. 72 As all participants in the CoinPool are needed in order to ratify each new = 73 state anyway, they can simply elect one of their number by drawing lots, to= 74 act as server for a particular state update. 75 76 Then the participants can operate as WabiSabi clients. 77 Each participant registers the outputs they currently own in the current st= 78 ate, getting credentials that sum up to the correct value. 79 Then, during the WabiSabi run, they can exchange credentials among the part= 80 icipants in order to perform value transfers inside the WabiSabi constructi= 81 on. 82 Then, at output registration, they register new outputs to put in the next = 83 state of the CoinPool. 84 85 In order to hide transfers from the elected WabiSabi server, participants c= 86 an maintain two coins in every state, and move coins randomly across the tw= 87 o coins they own at each state update, in order to hide "real" transfers fr= 88 om the elected server. 89 90 Then, after output registration, the participants ratify the new state by s= 91 igning off on the new state and revoking the previous state, using the upda= 92 te mechanism. 93 94 Of course, we should note that one desired feature for CoinPool in the orig= 95 inal proposal is that a participant can exit, and the CoinPool would still = 96 remain valid, but only for the remaining participants. 97 98 This is arguably a mild privacy leak: every other participant now knows how= 99 much that particular participant took out from the CoinPool. 100 Indeed, from what I can understand, in order to properly set up the splitti= 101 ng transactions in the first place, at each state every participant needs t= 102 o know how much each other participant actually owns in the CoinPool at tha= 103 t point in time. 104 105 To hide how much each participant owns in the CoinPool from other participa= 106 nts, we would have to make unilateral closes expose all the current outputs= 107 , without trying to identify *which* participant exited the CoinPool, and t= 108 hus preventing anyone else from figuring out exactly how much each *other* = 109 participant actually owns in the CoinPool on exit. 110 That way, output addresses can be to fresh pseudonyms of the participant, r= 111 emoving all linkages of participant to amount they own, and each participan= 112 t can maintain multiple outputs per state for their own purposes and to mil= 113 dly obscure exactly how much they own in total. 114 115 If we drop that feature (of being able to exit a participant without closin= 116 g the *entire* CoinPool), of course, we need to mildly disincentivize a par= 117 ticipant closing unilaterally for trivial reasons. 118 We can do this by using `SIGHASH_ANYPREVOUT` to force whoever performs a un= 119 ilateral close of the CoinPool to pay the onchain fees involved, so that it= 120 would have to be a good reason indeed to perform a unilateral close. 121 122 123 Regards, 124 ZmnSCPxj 125