summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAntoine Riard <antoine.riard@gmail.com>2020-06-12 20:28:27 -0400
committerbitcoindev <bitcoindev@gnusha.org>2020-06-13 00:28:41 +0000
commitb7a2d2cfdc107eb9c69f576dbf5b15c8425fc186 (patch)
tree1b9312dcfb368dbe7bf0c139c5b1a4a52758674c
parent8915f92f30623b6a4aaf48359fbcf6b2e66a7eec (diff)
downloadpi-bitcoindev-b7a2d2cfdc107eb9c69f576dbf5b15c8425fc186.tar.gz
pi-bitcoindev-b7a2d2cfdc107eb9c69f576dbf5b15c8425fc186.zip
Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy
-rw-r--r--e8/0daab6c102d922c1e217659a3d139ff3d02acd351
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>&gt; I have not studied the propo=
+sal in close detail yet, but anyway, my main takeaway roughly is:<br>&gt;<b=
+r>&gt; * The core of CoinPool is some kind of multiparticipant (N &gt; 2) o=
+ffchain update mechanism (Decker-Wattenhofer or Decker-Russell-Osuntokun).<=
+br>&gt; =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>&gt;=
+ =C2=A0 * At each update of the state, all participants must sign off on th=
+e new state.<br><br>Overall, that&#39;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>&gt; 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 &quot;real&quot; transfer=
+s from the elected server.<br><br>Yes I&#39;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>&gt; 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&#39;s part of future research, de=
+fining better *in-pool* observer. Sadly, right now, even if you use mask co=
+nstruction inside, it&#39;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>&gt; 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&#39;=
+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&#39;t spend that much on the exact adequate, incentives-align mech=
+anism beyond a &quot;withdraw-must-pay-its-fees&quot;.<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 &lt;<a href=3D"mailto:ZmnSCPxj@proton=
+mail.com">ZmnSCPxj@protonmail.com</a>&gt; 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 &gt; 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 &quot;real&quot; 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--
+