Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 69575C016F for ; Sat, 13 Jun 2020 00:28:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 5F71C882BB for ; Sat, 13 Jun 2020 00:28:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfdCoS5E7gV3 for ; Sat, 13 Jun 2020 00:28:40 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 2114E882AD for ; Sat, 13 Jun 2020 00:28:40 +0000 (UTC) Received: by mail-pj1-f43.google.com with SMTP id ne5so4301420pjb.5 for ; Fri, 12 Jun 2020 17:28:40 -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=+uxaVKFrOQPWuZErQp7nF2E1DVs/a2dKZSbM36X+Vyo=; b=QxcvxCFAC4YhPr3xgzrwXfg+3P9WXWn6Jh5DNPh6HedGQVBYfXix8PCcz9xpt1U0sd jX11CJhudrD0XFgsjmCcQ1VBmEexcn1qqu0KhHOeUesfUMs9JPs9xxUzbbdzICXAkD3x FT2k+iNTOoqwb/Ccr33B+N8mw2PPwOuuIS5FFcHTqSsrp2sGqdbcEBSfoTeNzrGbG25i mFZk/Gj6HeFHpv49FyS9kPVZJkTlQFG4rtbauNDKVCs0GCBUdJIl7mIredkaPznCp6/a 3CGaxmX1GEBGdL4IBLddBYEnNmoesxx/VNpWbXGdy2y6wJjvKr1Zx4bZkYrKwLWFlCAR TXyg== 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=+uxaVKFrOQPWuZErQp7nF2E1DVs/a2dKZSbM36X+Vyo=; b=Ub0yD3Dye+gRoQF5bMdBFx1pRnCCOzAjmb/sjGTbRBH8XYoNL4BdELxIDrrSMRjh71 Y74WvYkG7NaILb+gLOTGrDvXRzcokZ3I02pP0XqWHmxdQdG9CpcGTXr/1A89L2Nfq8ck c+blAkKIYhxrgUVGJi56ax0njWg8/bn6muvjqGOb4ylUefyjqcybLTljc7jSdxx/mWnq O08et89k+wIsIgPyNrmTNAueuvzTodIhVwjjLwFRXYXm8EgZ0ol1zVhev+J2QWIhiUpP taxKWV4b67cadbRorU0NQHDtuhUOVjwLQ9hAGuEXL/oYSy7lomZ+3PGhNYxxDJSk8O7R ePTw== X-Gm-Message-State: AOAM530oyVQ7fe2WKmPYuniL4BPSTHqmYiOWTTnAHzbfLcUTyRwtyN6y WvlhjS7b+/5JbIAcCjd5N0d38wUkp+xbDS9Y9r0= X-Google-Smtp-Source: ABdhPJwCmGrd7nr10a7SnT8WoNag/mGp5eCg6DjBUfc0TCnOCjk6nSmJM7LxySOWyZz6de+HZDgosvXK49FYK9KSuuI= X-Received: by 2002:a17:90a:d3d7:: with SMTP id d23mr1298221pjw.233.1592008119599; Fri, 12 Jun 2020 17:28:39 -0700 (PDT) MIME-Version: 1.0 References: <7cWQJzkWNEZCI2fYYrJCFxrmGfDGFAtsOyGpXRmB-g4Qhm2jzhyxLtuOIpJAr2CMJjAjri12lmR-h96ev3NWqaTgDtc_NN0yhyVxuIlBuzU=@protonmail.com> In-Reply-To: <7cWQJzkWNEZCI2fYYrJCFxrmGfDGFAtsOyGpXRmB-g4Qhm2jzhyxLtuOIpJAr2CMJjAjri12lmR-h96ev3NWqaTgDtc_NN0yhyVxuIlBuzU=@protonmail.com> From: Antoine Riard Date: Fri, 12 Jun 2020 20:28:27 -0400 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="00000000000072c71a05a7ec466d" X-Mailman-Approved-At: Sat, 13 Jun 2020 05:46:19 +0000 Cc: Bitcoin Protocol Discussion 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: Sat, 13 Jun 2020 00:28:41 -0000 --00000000000072c71a05a7ec466d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi ZmnSCPxj, > I have not studied the proposal in close detail yet, but anyway, my main takeaway roughly is: > > * The core of CoinPool is some kind of multiparticipant (N > 2) offchain update mechanism (Decker-Wattenhofer or Decker-Russell-Osuntokun). > * The output at each state of the update mechanism is some kind of splitting construction (which I have not studied in detail). > * At each update of the state, all participants must sign off on the new state. Overall, that's a really accurate description. I would add you can embed a funding outpoint of any offchain protocol on the splitting construction, modulo some timelocks shenanigans. > In order to hide transfers from the elected WabiSabi server, participants can maintain two coins in every state, and move coins randomly across the two coins they own at each state update, in order to hide "real" transfers from the elected server. Yes I'm quite sure you can reuse WabiSabi as a communication channel between participants, assuming you support tapscript and merkle branch transports, and server build a tree. Generally, we tried to keep design as flexible as we can to reuse privacy tools. > Indeed, from what I can understand, in order to properly set up the splitting transactions in the first place, at each state every participant needs to know how much each other participant actually owns in the CoinPool at that point in time. Yes, that's part of future research, defining better *in-pool* observer. Sadly, right now, even if you use mask construction inside, it's quite easy to trace leaves by value weight. Of course, you can enforce equal-value leaves, as for a regular onchain CoinJoin. I think it comes with a higher onchain cost in case of pool breakage. > That way, output addresses can be to fresh pseudonyms of the participant, removing all linkages of participant to amount they own, and each participant can maintain multiple outputs per state for their own purposes and to mildly obscure exactly how much they own in total. That's right that an in-pool observer may learn a link between an exit and an onchain withdraw. There is a future optimization, if you can swap your withdraw with an already onchain output, therefore breaking heuristics. > We can do this by using `SIGHASH_ANYPREVOUT` to force whoever performs a unilateral 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. Absolutely, for the fee structure, as the withdraw output is at the discretion of user, I was thinking some CPFP. There is maybe a better solution, haven't spend that much on the exact adequate, incentives-align mechanism beyond a "withdraw-must-pay-its-fees". Thanks for the high-quality review, as usual ;) Antoine Le ven. 12 juin 2020 =C3=A0 04:39, ZmnSCPxj a =C3= =A9crit : > Good morning Antoine and Gleb, > > I have not studied the proposal in close detail yet, but anyway, my main > takeaway roughly is: > > * The core of CoinPool is some kind of multiparticipant (N > 2) offchain > update mechanism (Decker-Wattenhofer or Decker-Russell-Osuntokun). > * The output at each state of the update mechanism is some kind of > splitting construction (which I have not studied in detail). > * At each update of the state, all participants must sign off on the ne= w > 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) > during 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 ne= w > 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 > state, getting credentials that sum up to the correct value. > Then, during the WabiSabi run, they can exchange credentials among the > participants in order to perform value transfers inside the WabiSabi > construction. > Then, at output registration, they register new outputs to put in the nex= t > state of the CoinPool. > > In order to hide transfers from the elected WabiSabi server, participants > can maintain two coins in every state, and move coins randomly across the > two coins they own at each state update, in order to hide "real" transfer= s > from the elected server. > > Then, after output registration, the participants ratify the new state by > signing off on the new state and revoking the previous state, using the > update mechanism. > > Of course, we should note that one desired feature for CoinPool in the > original 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 > splitting transactions in the first place, at each state every participan= t > needs to know how much each other participant actually owns in the CoinPo= ol > at that point in time. > > To hide how much each participant owns in the CoinPool from other > participants, we would have to make unilateral closes expose all the > current outputs, without trying to identify *which* participant exited th= e > CoinPool, and thus 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, > removing all linkages of participant to amount they own, and each > participant can maintain multiple outputs per state for their own purpose= s > and to mildly obscure exactly how much they own in total. > > If we drop that feature (of being able to exit a participant without > closing the *entire* CoinPool), of course, we need to mildly disincentivi= ze > a participant closing unilaterally for trivial reasons. > We can do this by using `SIGHASH_ANYPREVOUT` to force whoever performs a > unilateral close of the CoinPool to pay the onchain fees involved, so tha= t > it would have to be a good reason indeed to perform a unilateral close. > > > Regards, > ZmnSCPxj > --00000000000072c71a05a7ec466d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi ZmnSCPxj,

> I have not studied the propo= sal in close detail yet, but anyway, my main takeaway roughly is:
>> * The core of CoinPool is some kind of multiparticipant (N > 2) o= ffchain update mechanism (Decker-Wattenhofer or Decker-Russell-Osuntokun).<= br>> =C2=A0 * The output at each state of the update mechanism is some k= ind of splitting construction (which I have not studied in detail).
>= =C2=A0 * At each update of the state, all participants must sign off on th= e new state.

Overall, that's a really accurate description. I wo= uld add you can embed a funding outpoint of any offchain protocol on the sp= litting construction, modulo some timelocks shenanigans.

> In ord= er to hide transfers from the elected WabiSabi server, participants can mai= ntain two coins in every state, and move coins randomly across the two coin= s they own at each state update, in order to hide "real" transfer= s from the elected server.

Yes I'm quite sure you can reuse Wabi= Sabi as a communication channel between participants, assuming you support = tapscript and merkle branch transports, and server build a tree. Generally,= we tried to keep design as flexible as we can to reuse privacy tools.
<= br>> Indeed, from what I can understand, in order to properly set up the= splitting transactions in the first place, at each state every participant= needs to know how much each other participant actually owns in the CoinPoo= l at that point in time.

Yes, that's part of future research, de= fining better *in-pool* observer. Sadly, right now, even if you use mask co= nstruction inside, it's quite easy to trace leaves by value weight. Of = course, you can enforce equal-value leaves, as for a regular onchain CoinJo= in. I think it comes with a higher onchain cost in case of pool breakage.
> That way, output addresses can be to fresh pseudonyms of the par= ticipant, removing all linkages of participant to amount they own, and each= participant can maintain multiple outputs per state for their own purposes= and to mildly obscure exactly how much they own in total.

That'= s right that an in-pool observer may learn a link between an exit and an on= chain withdraw. There is a future optimization, if you can swap your withdr= aw with an already onchain output, therefore breaking heuristics.

&g= t; We can do this by using `SIGHASH_ANYPREVOUT` to force whoever performs a= unilateral 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.
Absolutely, for the fee structure, as the withdraw output is at the di= scretion of user, I was thinking some CPFP. There is maybe a better solutio= n, haven't spend that much on the exact adequate, incentives-align mech= anism beyond a "withdraw-must-pay-its-fees".

Thanks for th= e high-quality review, as usual ;)

Antoine

Le=C2=A0ven. 12 = juin 2020 =C3=A0=C2=A004:39, ZmnSCPxj <ZmnSCPxj@protonmail.com> a =C3=A9crit=C2=A0:
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= update mechanism (Decker-Wattenhofer or Decker-Russell-Osuntokun).
=C2=A0 * The output at each state of the update mechanism is some kind of s= plitting construction (which I have not studied in detail).
=C2=A0 * 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.linuxfoundatio= n.org/pipermail/bitcoin-dev/2020-June/017969.html) during negotiation o= f 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" tr= ansfers from 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
--00000000000072c71a05a7ec466d--