Grin: switch commitment discussion

Created on 23 Apr 2018 · 3Comments · Source: mimblewimble/grin

Tim Ruffing resurrected the "switch commitment" discussion on the ML -
https://lists.launchpad.net/mimblewimble/msg00479.html

tl;dr sounds like there is a "zero cost" way of getting switch commitments in as part of the commitment itself, so we would not need to store and maintain a separate "switch commitment" on each output.

I saw that switch commitments have been removed for various reasons.
Let me suggest a variant (idea suggested by Pieter Wuille initially):

The switch commitment is (vG + bH), where b = b' + hash(vG + b'H,
b'*J). (So this "tweaks" the commitment, in a pay-to-contract / taproot
style).

Before the switch, this is just used like a normal Pedersen commitment
vG + bH.
After the switch, users can reveal (vG + b'H, b'J), and verifiers
check if it's computed correctly and use as if it were the ElGamal
commitment (vG + bH, bJ).

This variant has the following features:

It's as secure as the other one (a security proof will appear in my
thesis).

It does not need additional space (we suggested the other one
because we thought it's anyway useful to store the hash in Grin).

It does not need an additional random value (better than the
previous suggestion).

b' can be derived from the private key (and then b can be derived
via the hash).

It does not allow for the inclusion of arbitrary data. (You can of
course use everything as a preimage of the hash but people can always
use a hash here, no matter whether switch commitments are used or not.)

I don't know the code but I don't see how this should add a lot of
complexity: generating the commitment is a few lines more and the
verification is not changed at all.

I could see how this adds complexity because the "main secret" b of
the user looks different now. But if this is an issue, it's not
necessary to tweak the commitment itself. For example, it's possible to
tweak EC points in the range proof instead, and Andrew confirmed that
does not introduce any problems or overhead in the range proofs.

Feel free to ignore this suggestion but I'm resurrecting that
discussion yet again because I think that this switch commitments come
at basically zero cost now, and so it can be wrong to have them in the
future, even if it's unclear if they will be needed.