← Back to team overview

mimblewimble team mailing list archive

Re: [POLL] Perfectly hiding vs perfectly binding


After speaking to Igno, @urza_cc_twitter on the Grin Gitter and Peter Todd,
I've reconsidered my position. I am now in favor of perfect hiding for grin.
My reasons are thus:

  - First, unlike in Elements/Liquid/"Bitcoin+CT"/etc, in Mimblewimble the
    CT blinding factors are authentication keys. So a QC attacker will be
    able to steal coins, because there is no script system he must also
    subvert. Preventing inflation by somebody who can steal arbitrary coins
    is a dubious value proposition.

  - Second, in Peter's words, "it's easy to replace lost money but impossible
    to replace lost privacy". The reason we want privacy in Grin is to ensure
    human rights to free association and self-determination are respected, and
    there is a chilling effect if coin values might be exposed in the future,
    even if it is in the far future.

    In many specific contexts, it's ok to suffer a loss of privacy as long as
    it is privacy of sufficiently old data, because the need for privacy is
    somewhat ephemeral (e.g. preventing frontrunning, hiding trade secrets).
    But a publicly accessible system should not be limited to these specific

With this in mind, it is actually a feature, not a bug, that a perfectly hiding
Mimblewimble would respond to a ECDL break by philosophically erasing the amounts
of all coins in history (in the sense that every commitment would be openable to
every amount).

It is very rare in computer science to get this sort of provable deletion, so
we should take advantage of it.


On Thu, May 04, 2017 at 02:42:35PM +0000, Andrew Poelstra wrote:
> I should start by saying that I am in favor of unconditional soundness.
> My reasons are twofold:
>   - First, user assurance that no inflation has happened or ever will
>     happen, even in the presence of a discrete logarithm break/QC.
>     Note that unlike Bitcoin, we can't just softfork in a replacement
>     for OP_CHECKSIG that will prevent theft in this case. We would need
>     to replace the output commitments and rangeproofs, which along with
>     some hash structures constitute the entirety of Mimblewimble's
>     consensus model. So users worried about _theft_ need to develop a new
>     quantum hard MW regardless of the outcome of this discussion.
>     (_Detecting theft_, at least in a way that you can prove to yourself
>     that it happened, is pretty easy -- just sign-to-contract the current
>     state of your wallet in every transaction you produce. This is quantum
>     secure and works regardless of soundness. I'll talk about this in
>     some future post about wallet design.)
>   - Secondly, it's important to realize that inflation is literally
>     undetectable with Pedersen commitments in the case of a discrete log
>     break. You can't even just open the commitments and add up the values
>     because the commitments will no longer have meaningful openings.

Andrew Poelstra
Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

"A goose alone, I suppose, can know the loneliness of geese
 who can never find their peace,
 whether north or south or west or east"
       --Joanna Newsom

Attachment: signature.asc
Description: PGP signature

Follow ups