0

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?

Improve this question

1 Answer 1

Reset to default
2

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.

Improve this answer
6
  • "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, 2019 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, 2019 at 4:48
  • What matters is that somebody else might know the x, without me knowing this fact.
    – SigningUpForOneQuestionOnly
    Mar 8, 2019 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, 2019 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, 2019 at 5:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.