mimblewimble team mailing list archive

[Andrew Poelstra <apoelstra@xxxxxxxxxxxxxx>]

Hiding important data inside the rangeproofs would force nodes to keep it around.
The rangeproofs are otherwise purely witness data that non-archival nodes can
discard.

On Thu, Sep 07, 2017 at 01:33:14PM -0700, Oleg Andreev wrote:
> How about this (weird) idea:
> 
> 1. Store `sha256(r*J)` inside one of the first 2 forged elements (corresponding to the lowest bit of your number, assuming base-4 rangeproofs; for base-3 it also works).
> 2. When you reveal it after PQ upgrade, you will destroy 1 bit of privacy in your number, revealing if it's even or odd. That's spiritually compatible with "min value" support in range proofs, that's just a 1 bit of minvalue, delayed till quantum threat becomes real.
> 3. It is safe because you if you don't have QC, you cannot pre-commit an alternative sha256(r2*J) which would match your commitment. If you already have a QC, you can forge the amount anyway.
> 
> Alternative is to allow _any_ forged s-element to contain a commitment to r*J, safety argument in (3) should still stand, and you probably can commit it in the element corresponding to the "1" bit, so you reveal "0" bit - that would not leak the magnitude of the amount (could be simply the padding zero in the high digits).
> 
> 
> > On 7 Sep 2017, at 11:12, Andrew Poelstra <apoelstra@xxxxxxxxxxxxxx> wrote:
> > 
> > On Thu, Sep 07, 2017 at 01:23:45PM -0400, Ignotus Peverell wrote:
> >> Hi,
> >> 
> >> I wanted to pick that back up. I think it comes down to yet another tradeoff between privacy, security and convenience. To give back some context from Andrew's email:
> >> 
> >>> Basically our outputs should consist of the pair
> >>>  vH + rG, sha256(rJ)
> >>> where J is a new NUMS generator, G the standard generator, and H is our asset
> >>> ID as always. We set this up so that we can softfork a rule that only allows
> >>> outputs to be spent by revealing rJ and an unconditional rangeproof, but prior
> >>> to the softfork we only require ordinary rangeproofs.
> >> 
> >> I'll let you refer to Andrew's email for a bigger list of benefits [1]. Now the drawbacks: to store the hash, we need an extra 32 bytes field in outputs. We could likely make that even a little smaller but the size isn't my bigger worry. With an additional free-form field people and wallets implementations will:
> >> 
> >> - Compromise their privacy by inserting data that make their transactions look different from the others.
> > 
> > A weak form of this is intentional -- that wallets will recognize their
> > hopefully-uniformly-random data to be able to identify their own outputs.
> > It's hard to do this with only the Pedersen commitment because it's
> > tangled up with the output value.
> > 
> > It's true that people can put non-random things here which would be really
> > bad for privacy. I don't think there's any efficiently-verifiable way to
> > prevent that. Maybe requiring the data be a hash and requiring the preimage
> > be exposed during spending, even in the pre-switch era?
> > 
> >> - Insert hashes of documents, identity, images, etc. and likely never allow pruning of these outputs.
> > 
> > Yeah.
> > 
> >> - Use it as plain storage and demand the field to be larger.
> >> 
> > 
> > They can already use the rangeproof to encrypt tons of data to themselves,
> > if they want to do this...so I think that's a simple response to any demands
> > to increase the size of the field, without even needing to argue about
> > whether this is a sensible use of blockchain space.
> > 
> >> So I'd be happy to hear others' arguments. The benefits would be tangible, but so would be the drawbacks.
> >> 
> >> - Igno
> >> 
> >> [1] https://lists.launchpad.net/mimblewimble/msg00165.html <https://lists.launchpad.net/mimblewimble/msg00165.html>
> > 
> > 
> > -- 
> > Andrew Poelstra
> > Mathematics Department, Blockstream
> > Email: apoelstra at wpsoftware.net <http://wpsoftware.net/>
> > Web:   https://www.wpsoftware.net/andrew <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
> > 
> > -- 
> > Mailing list: https://launchpad.net/~mimblewimble <https://launchpad.net/~mimblewimble>
> > Post to     : mimblewimble@xxxxxxxxxxxxxxxxxxx <mailto:mimblewimble@xxxxxxxxxxxxxxxxxxx>
> > Unsubscribe : https://launchpad.net/~mimblewimble <https://launchpad.net/~mimblewimble>
> > More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>

> -- 
> Mailing list: https://launchpad.net/~mimblewimble
> Post to     : mimblewimble@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~mimblewimble
> More help   : https://help.launchpad.net/ListHelp


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