Definition of H and G?

Hi there,
I am trying to build a local version of MimbleWimble using Python just to understand the protocol and the idea better. I use secp256k1 to generate EC points for values and blinding factors, however I feel I’m missing something. In practice, H and G are supposed to be the same curve - but G being “another generator point on the same curve group” https://github.com/mimblewimble/grin/blob/master/doc/intro.md). I wonder how is G exactly defined in Grin? Is it necessary that G and H are not the same generators in order for the Pedersen commitment to be safe or does it work even if G = H?

Points (not curves!) G and H on curve secp256k1 are defined in https://github.com/mimblewimble/secp256k1-zkp

Not only must H differ from G, but there can be no known relation between them:
no one can know n such that H = n * G

Hi John,
Thanks for the insight. Could you elaborate a bit more on that? I’m trying to get enough understanding of the basics involved here, unfortunately I’m still not that well versed in all the underlying mathematics… In the intro https://github.com/mimblewimble/grin/blob/master/doc/intro.md (which by the way I think is pretty good) it is mentioned that H and G are curves, but I see they are generator points - does the terminology matter? I thought somehow there is only one generator point for each curve (e.g. https://safecurves.cr.yp.to/base.html) but I also remember reading somewhere that under some conditions almost any point could serve as generator…
Where are the points defined exactly and how did you choose them?
Am I right that if G and H generate points in the same curve then rG + vH must also be a point in the curve? I remember reading the opposite somewhere (that the result shouldn’t be a valid point in the curve). Or is the addition operator here not acting as an elliptic curve point addition?

The eliptic curve intro needs a little rewriting. I’ll start working on that.
Linear combinations of curve points are of course also points on the curve.

The secp2561k1 curve used in Grin was standardized in section 2.4.1 on page 9 of
http://www.secg.org/sec2-v2.pdf
The matching source code can be found in

Point H is defined in nothing-up-my-sleeve fashion (as essentially SHA256(G)) in

Agreed, I tried to keep a balance between being easy to understand and accurate but may not always have succeeded.

Thanks! That was helpful.

Hi! :slightly_smiling_face:

Sorry to hijack this thread but I have a related question:
I understand how generator point H is created from sha256 of G (and successfully verified the calculation myself), but I am not able to do the same for the generator point GENERATOR_PUB_J_RAW .

When I tried to redo the calculation described in the comments above the definiton I come up with a different point:

Is the comment incorrect, or what did I wrong?

sage: import hashlib
sage: F = FiniteField (0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F)
sage: gen_h =  hashlib.sha256('0479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8'.decode('hex'))
sage: gen_j_input = gen_h.hexdigest()
sage: gen_j =  hashlib.sha256(gen_j_input.decode('hex'))
sage: G3 = EllipticCurve ([F (0), F (7)]).lift_x(Integer(int(gen_j.hexdigest(),16)))
sage: '%x %x'%G3.xy()
'b860f56795fc03f3c21685383d1b5a2f2954f49b7e398b8d2a0193933621155f a43f09d32caa8f53423f427403a56a3165a5a69a74cf56fc5901a2dca6c5c43a'

As you see my calculation returns the curve point:
X: b860f56795fc03f3c21685383d1b5a2f2954f49b7e398b8d2a0193933621155f
Y: a43f09d32caa8f53423f427403a56a3165a5a69a74cf56fc5901a2dca6c5c43a

Why is this different to GENERATOR_PUB_J_RAW ?

I just realized it is indeed the same point, but with reversed byte order. :slight_smile:

Is there any specific reason for this?

[Edit]
Nevermind, I found the background behind this in this PR discussion: https://github.com/mimblewimble/rust-secp256k1-zkp/pull/38