switch commitment discussion

[antiochp]

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(v*G + 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.

Best,
Tim

[antiochp]

Hey @real-or-random, tracking your suggestion here to make sure it gets discussed.

[quentinlesceller]

Linking the previous PR #841.

[antiochp]

Closing. Yay!