# Implications and remedies of fixed 'H' in Pedersen commitment

In the monero document "Zero to Monero" pp. 30 the Pedersen Commitment scheme is described as requiring generators `G, H` such that no-one knows an `x` where `G = x*H`. The actual `H` is defined as `H=to_point(Keccak(G))` where `to_point` is a function mapping scalars to elliptic curve points. Gregory Maxwell describes this function in more detail:

... Where to_point() takes the input as the x value of a new point, checks that its on the curve and solves for the y value. ...

Rather than simply multiplying by `G`, somewhat breaking the scheme.

However, if someone was to figure out the `x` above doesen't this become a single, centralized point-of-failure for the entire currency? Meaning that by breaking this single, 128-bit secure key, absolutely all monero transactions - future and past - could be decoded w.r.t. the amounts sent? As a follow up: would it be possible for the sender to pick a fresh `H` for every transaction?

The commitment is actually xG + aH where both G and H are pre-defined generators. The hardness of the discrete logarithm problem ensures calculating a from H (or x from G) is infeasible. Put another way, both G and H are points, and because of ECC point multiplication, you can't deduce x or a.

Further, you'll see described in Maxwell's Confidential Transactions paper:

``````The Pedersen commitment is created by picking an additional generator
for the group (which we'll call H) such that no one knows the discrete
log for H with respect to G (or vice versa), meaning no one knows an
x such that xG = H. We can accomplish this by using the cryptographic
hash of G to pick H:

H = to_point(SHA256(ENCODE(G)))
``````

Which is precisely how H is constructed in Monero: H = Hp(G), which is `H = to_point(Keccak(G))`.

Further:

However, if someone was to figure out the x above doesen't this become a single, centralized point-of-failure for the entire currency?

No. x is a binding factor in a single commitment. A centralized point of failure would be if someone knew the discrete log for H with respect to G (or vice versa). If one miraculously calculated an x in one commitment, this wouldn't compromise other commitments. Think about it like this: just because you know your x for a commitment, doesn't mean you can work out other x's.

Also:

As a follow up: would it be possible for the sender to pick a fresh H for every transaction?

That's essentially what happens because of the point multiplication using a. E.g. aH.

• "A centralized point of failure would be if someone knew the discrete log for H with respect to G (or vice versa)." This is what I'm asking, as basically all transactions use the same G and H. But is there any technical reason for keeping H constant? – SigningUpForOneQuestionOnly Mar 8 '19 at 4:41
• The fact that G and H are known is irrelevant. What matters is you don't know an x such that xG = H. – jtgrassie Mar 8 '19 at 4:48
• What matters is that somebody else might know the x, without me knowing this fact. – SigningUpForOneQuestionOnly Mar 8 '19 at 4:57
• Then they would know how to defeat the discrete log problem and everything that relies on ECC would be broken. – jtgrassie Mar 8 '19 at 5:01
• It's more a question of resources, surely breaking one key for the whole network, costing e.g. \$ 1B, is cheaper than breaking one key per transaction. It's also a question of time, as 80-bit encryption is no-longer considered secure (although it still costs something to break each key) and ECRYPT standards (keylength.com/en/3) indicate that the curve is only secure for at least 10 years. Besides, if/when this break occurs the key could be replicated and shared with select blockchain analysis companies creating cheap, asymmetric transparency to the blockchain. – SigningUpForOneQuestionOnly Mar 8 '19 at 5:11