From: Antoine Riard <antoine.riard@gmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy
Date: Fri, 12 Jun 2020 20:28:27 -0400 [thread overview]
Message-ID: <CALZpt+EsACbq1QM9MFkC63_gDXW0vHfeTjXc7C9r4+2-1WKAJw@mail.gmail.com> (raw)
In-Reply-To: <7cWQJzkWNEZCI2fYYrJCFxrmGfDGFAtsOyGpXRmB-g4Qhm2jzhyxLtuOIpJAr2CMJjAjri12lmR-h96ev3NWqaTgDtc_NN0yhyVxuIlBuzU=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 6539 bytes --]
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 à 04:39, ZmnSCPxj <ZmnSCPxj@protonmail•com> a écrit :
> 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 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)
> 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 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
> 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 next
> 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" transfers
> 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 participant
> needs to know how much each other participant actually owns in the CoinPool
> 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 the
> 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 purposes
> 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 disincentivize
> 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 that
> it would have to be a good reason indeed to perform a unilateral close.
>
>
> Regards,
> ZmnSCPxj
>
[-- Attachment #2: Type: text/html, Size: 7058 bytes --]
next prev parent reply other threads:[~2020-06-13 0:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-11 8:53 Antoine Riard
2020-06-11 17:21 ` Jeremy
2020-06-12 23:45 ` Antoine Riard
2020-06-12 8:39 ` ZmnSCPxj
2020-06-13 0:28 ` Antoine Riard [this message]
2020-06-13 0:45 ` ZmnSCPxj
2020-06-13 1:20 ` ZmnSCPxj
2020-06-16 5:23 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALZpt+EsACbq1QM9MFkC63_gDXW0vHfeTjXc7C9r4+2-1WKAJw@mail.gmail.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox