diff options
author | Antoine Riard <antoine.riard@gmail.com> | 2020-06-12 20:28:27 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2020-06-13 00:28:41 +0000 |
commit | b7a2d2cfdc107eb9c69f576dbf5b15c8425fc186 (patch) | |
tree | 1b9312dcfb368dbe7bf0c139c5b1a4a52758674c | |
parent | 8915f92f30623b6a4aaf48359fbcf6b2e66a7eec (diff) | |
download | pi-bitcoindev-b7a2d2cfdc107eb9c69f576dbf5b15c8425fc186.tar.gz pi-bitcoindev-b7a2d2cfdc107eb9c69f576dbf5b15c8425fc186.zip |
Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy
-rw-r--r-- | e8/0daab6c102d922c1e217659a3d139ff3d02acd | 351 |
1 files changed, 351 insertions, 0 deletions
diff --git a/e8/0daab6c102d922c1e217659a3d139ff3d02acd b/e8/0daab6c102d922c1e217659a3d139ff3d02acd new file mode 100644 index 000000000..fba02c3af --- /dev/null +++ b/e8/0daab6c102d922c1e217659a3d139ff3d02acd @@ -0,0 +1,351 @@ +Return-Path: <antoine.riard@gmail.com> +Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 69575C016F + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 13 Jun 2020 00:28:40 +0000 (UTC) +Received: by mail-pj1-f43.google.com with SMTP id ne5so4301420pjb.5 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CALZpt+FqAWCAqCLF2HsajL84sOvst_X9_34bb_tvUxLFw=HTAA@mail.gmail.com> + <7cWQJzkWNEZCI2fYYrJCFxrmGfDGFAtsOyGpXRmB-g4Qhm2jzhyxLtuOIpJAr2CMJjAjri12lmR-h96ev3NWqaTgDtc_NN0yhyVxuIlBuzU=@protonmail.com> +In-Reply-To: <7cWQJzkWNEZCI2fYYrJCFxrmGfDGFAtsOyGpXRmB-g4Qhm2jzhyxLtuOIpJAr2CMJjAjri12lmR-h96ev3NWqaTgDtc_NN0yhyVxuIlBuzU=@protonmail.com> +From: Antoine Riard <antoine.riard@gmail.com> +Date: Fri, 12 Jun 2020 20:28:27 -0400 +Message-ID: <CALZpt+EsACbq1QM9MFkC63_gDXW0vHfeTjXc7C9r4+2-1WKAJw@mail.gmail.com> +To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Content-Type: multipart/alternative; boundary="00000000000072c71a05a7ec466d" +X-Mailman-Approved-At: Sat, 13 Jun 2020 05:46:19 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <ZmnSCPxj@protonmail.com> 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 + +<div dir=3D"ltr"><div>Hi ZmnSCPxj,<br><br>> I have not studied the propo= +sal in close detail yet, but anyway, my main takeaway roughly is:<br>><b= +r>> * 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).<br>>= + =C2=A0 * At each update of the state, all participants must sign off on th= +e new state.<br><br>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.<br><br>> 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.<br><br>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><= +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.<br><br>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.<b= +r><br>> 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.<br><br>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.<br><br>&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.<br= +><br>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".<br><br>Thanks for th= +e high-quality review, as usual ;)<br><br></div>Antoine<br></div><br><div c= +lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 12 = +juin 2020 =C3=A0=C2=A004:39, ZmnSCPxj <<a href=3D"mailto:ZmnSCPxj@proton= +mail.com">ZmnSCPxj@protonmail.com</a>> a =C3=A9crit=C2=A0:<br></div><blo= +ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left= +:1px solid rgb(204,204,204);padding-left:1ex">Good morning Antoine and Gleb= +,<br> +<br> +I have not studied the proposal in close detail yet, but anyway, my main ta= +keaway roughly is:<br> +<br> +* The core of CoinPool is some kind of multiparticipant (N > 2) offchain= + update mechanism (Decker-Wattenhofer or Decker-Russell-Osuntokun).<br> +=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).<br> +=C2=A0 * At each update of the state, all participants must sign off on the= + new state.<br> +<br> +It seems to me that it would be possible to use a [WabiSabi protocol](<a hr= +ef=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017= +969.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio= +n.org/pipermail/bitcoin-dev/2020-June/017969.html</a>) during negotiation o= +f a new state.<br> +<br> +Now, WabiSabi is a client-server protocol.<br> +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.<br> +<br> +Then the participants can operate as WabiSabi clients.<br> +Each participant registers the outputs they currently own in the current st= +ate, getting credentials that sum up to the correct value.<br> +Then, during the WabiSabi run, they can exchange credentials among the part= +icipants in order to perform value transfers inside the WabiSabi constructi= +on.<br> +Then, at output registration, they register new outputs to put in the next = +state of the CoinPool.<br> +<br> +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.<br> +<br> +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.<br> +<br> +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.<br> +<br> +This is arguably a mild privacy leak: every other participant now knows how= + much that particular participant took out from the CoinPool.<br> +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.<br> +<br> +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.<br> +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.<br> +<br> +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.<br> +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.<br> +<br> +<br> +Regards,<br> +ZmnSCPxj<br> +</blockquote></div> + +--00000000000072c71a05a7ec466d-- + |