mimblewimble team mailing list archive

[Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>]

The final tally is 5 votes for perfectly binding vs 3 for perfectly hiding, including my own vote for the latter. I had a slight preference for perfectly hiding previously to the vote and still do. It's been great hearing the different arguments on both sides.

Note that, as pointed out by John Tromp and others, we can start with perfectly binding and add an asset (likely a soft fork) to protect ourselves against QC later on. I don't think the crypto is ready yet for MimbleWimble to be credibly fully QC resistant. The good news is we still have some time to figure it out.

Thanks for your help and participation!

- Igno

-------- Original Message --------
On May 8, 2017, 12:46 PM, Andrew Poelstra wrote:

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
contexts.

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.

Cheers
Andrew

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