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 <apoels...@wpsoftware.net> 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@lists.launchpad.net > <mailto:mimblewimble@lists.launchpad.net> > 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~mimblewimble More help : https://help.launchpad.net/ListHelp
