mimblewimble team mailing list archive
Mailing list archive
Re: Hashed switch commitments
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:
>> 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 . 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.
>> - 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
>>  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>