mimblewimble team mailing list archive

[Oleg Andreev <oleganza@xxxxxxxxx>]

Maybe store it committed to the excess factors (via merkle tree, to allow one excess to commit to multiple switch commitments)? Tx kernels are prunable, but committed to each block, so we can have a merkle proof of inclusion in a historical block to open the commitment.

Raw excess commitment E = e*G

Actual excess commitment K = E + Hash(E || <switch commitment merkle root>)*G

Output blinding factors will have to be compensated by that commitment.

Validation:

1. Prove that kernel excess commitment K was published in some tx in block B (merkle path).
2. Prove that commitment K == E + Hash(E || R)
3. Prove that X belongs to the merkle root R, X = Hash((vH + rG) || rJ)
4. Check that the inner pedersen commitment (vH + rG) equals to the one being spent right now.
5. Verify the rangeproof for the presented ElGamal commitment (vH + rG, rJ).

The most tricky part is proving existence of kernels (if they are not stored forever). Would need storage or transmission of a bunch of historical block headers...


> On 7 Sep 2017, at 14:23, Andrew Poelstra <apoelstra@xxxxxxxxxxxxxx> wrote:
> 
> 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><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/> <http://wpsoftware.net/ <http://wpsoftware.net/>>
>>> Web:   https://www.wpsoftware.net/andrew <https://www.wpsoftware.net/andrew> <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> <https://launchpad.net/~mimblewimble <https://launchpad.net/~mimblewimble>>
>>> Post to     : mimblewimble@xxxxxxxxxxxxxxxxxxx <mailto:mimblewimble@xxxxxxxxxxxxxxxxxxx> <mailto:mimblewimble@xxxxxxxxxxxxxxxxxxx <mailto:mimblewimble@xxxxxxxxxxxxxxxxxxx>>
>>> Unsubscribe : https://launchpad.net/~mimblewimble <https://launchpad.net/~mimblewimble> <https://launchpad.net/~mimblewimble <https://launchpad.net/~mimblewimble>>
>>> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp> <https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>>
> 
>> -- 
>> 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>
> 
> 
> -- 
> 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