From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 23E72C016F for ; Fri, 12 Jun 2020 08:39:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 199118943A for ; Fri, 12 Jun 2020 08:39:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-WbgtR9rpYe for ; Fri, 12 Jun 2020 08:39:45 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch [185.70.40.138]) by hemlock.osuosl.org (Postfix) with ESMTPS id 2F472893B9 for ; Fri, 12 Jun 2020 08:39:45 +0000 (UTC) Date: Fri, 12 Jun 2020 08:39:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1591951182; bh=Jtpv+5F2PArLWO5cH4wDZH8u7IFWstHpvaZUIFLZHUY=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=iI6mbWj4KdbMbsuMWWjwMjsbiP3WJHCgsyicbyBeoJE4apQIGUSxtkxkwBg5QcNQI lFgpOwJbcmUIMwuCtrC1wdNFoW7z/oWccVu/WuReSp0rn5S3xAP0H4yuprTsCingpe LqB2l1aI1O3e9V7QvGbt7SImXL6doySJv4wYCazs= To: Antoine Riard , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <7cWQJzkWNEZCI2fYYrJCFxrmGfDGFAtsOyGpXRmB-g4Qhm2jzhyxLtuOIpJAr2CMJjAjri12lmR-h96ev3NWqaTgDtc_NN0yhyVxuIlBuzU=@protonmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy 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: Fri, 12 Jun 2020 08:39:47 -0000 Good morning Antoine and Gleb, I have not studied the proposal in close detail yet, but anyway, my main ta= keaway roughly is: * The core of CoinPool is some kind of multiparticipant (N > 2) offchain up= date mechanism (Decker-Wattenhofer or Decker-Russell-Osuntokun). * The output at each state of the update mechanism is some kind of splitt= ing construction (which I have not studied in detail). * At each update of the state, all participants must sign off on the new = state. It seems to me that it would be possible to use a [WabiSabi protocol](https= ://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017969.html) d= uring negotiation of a new state. Now, WabiSabi is a client-server protocol. As all participants in the CoinPool are needed in order to ratify each new = state anyway, they can simply elect one of their number by drawing lots, to= act as server for a particular state update. Then the participants can operate as WabiSabi clients. Each participant registers the outputs they currently own in the current st= ate, getting credentials that sum up to the correct value. Then, during the WabiSabi run, they can exchange credentials among the part= icipants in order to perform value transfers inside the WabiSabi constructi= on. Then, at output registration, they register new outputs to put in the next = state of the CoinPool. In order to hide transfers from the elected WabiSabi server, participants c= an maintain two coins in every state, and move coins randomly across the tw= o coins they own at each state update, in order to hide "real" transfers fr= om the elected server. Then, after output registration, the participants ratify the new state by s= igning off on the new state and revoking the previous state, using the upda= te mechanism. Of course, we should note that one desired feature for CoinPool in the orig= inal proposal is that a participant can exit, and the CoinPool would still = remain valid, but only for the remaining participants. This is arguably a mild privacy leak: every other participant now knows how= much that particular participant took out from the CoinPool. Indeed, from what I can understand, in order to properly set up the splitti= ng transactions in the first place, at each state every participant needs t= o know how much each other participant actually owns in the CoinPool at tha= t point in time. To hide how much each participant owns in the CoinPool from other participa= nts, we would have to make unilateral closes expose all the current outputs= , without trying to identify *which* participant exited the CoinPool, and t= hus preventing anyone else from figuring out exactly how much each *other* = participant actually owns in the CoinPool on exit. That way, output addresses can be to fresh pseudonyms of the participant, r= emoving all linkages of participant to amount they own, and each participan= t can maintain multiple outputs per state for their own purposes and to mil= dly obscure exactly how much they own in total. If we drop that feature (of being able to exit a participant without closin= g the *entire* CoinPool), of course, we need to mildly disincentivize a par= ticipant closing unilaterally for trivial reasons. We can do this by using `SIGHASH_ANYPREVOUT` to force whoever performs a un= ilateral close of the CoinPool to pay the onchain fees involved, so that it= would have to be a good reason indeed to perform a unilateral close. Regards, ZmnSCPxj