loading . . . What is a Pedersen commitment? Iâm taking a break from my series on celestial navigation. The previous posts give the basics, but I havenât thought of a way to go further that Iâm satisfied with. So now for something completely different: **Pedersen commitments**.
Pedersen commitments are a building block of zero knowledge proofs (ZKP), and they give an opportunity to look at a couple other other interesting topics: nothing-up-my-sleeve constructions and homomorphic encryption.
A Pedersen commitment to a value _v_ takes a random number _x_ and two generators of an elliptic curve, _G_ and _H_ , and returns
C = _vG_ + _xH_.
The significance of _C_ is that it appears to be a random number to the recipient, but the sender who calculated it can later show that it was computed from _c_ and _x_. _C_ is called a **commitment** to the value _v_ because the sender cannot later say that _C_ was computed from a different _v_ and a different _x_.
## Mathematical details
The addition in
C = _vG_ + _xH_
is carried out on on an elliptic curve, such as Ed25519 in the case of Monero. Multiplication is defined by repeated addition, though itâs not computed that way [1]. _G_ and _H_ are not just points on the elliptic curve but points in a large, prime-order subgroup of the elliptic curve.
Because the value _x_ is random, the possible values of _C_ are uniformly distributed on the curve, and so someone observing _C_ learns nothing about _v_. For that reason _x_ is called a **blinding factor**.
The difficulty of the discrete logarithm problem insures that it is impractical come up with different values _v_ â and _x_ â such that
_v G_ + _x H_ = _v_ â _G_ + _x_ â _H_.
This depends on two assumptions.
The first assumption is that the discrete logarithm problem is hard to solve given current algorithms and hardware. The prevailing opinion is that it is unlikely anyone will come up with an efficient algorithm for solving the discrete logarithm problem on current hardware. However, Shorâs algorithm could solve the discrete logarithm problem efficiently if and when a practical, large-scale quantum computer is created.
The second assumption is that the generator _H_ was chosen at random and not calculated to be a backdoor.
## How to make and use a backdoor
Because _G_ and _H_ are members of the same prime-order (i.e. cyclic) group, there exists some integer _h_ such
_H_ = _hG_
If the generator _H_ was randomly selected, nobody knows _h_ and nobody can calculate it. But if _H_ was calculated by first selecting _h_ and multiplying _hG_ then there is a backdoor.
Now
C = _vG_ + _xH_ = _vG_ + _x_(_hG_) = (_v_ + _xh_)_G._
If you know _h_ , you can pick a new _v_ â and solve for _x_ â such that
_v_ + _xh_ = _v_ â + _x_ â _h._
That would mean that in the context of a cryptocurrency that uses Pedersen commitments, such as Monero or the Liquid Network on top of Bitcoin, you could initially commit to spending _v_ and later claimed that you committed to spending _v_ â.
Note that solving for _x_ â requires modular arithmetic, not solving the discrete logarithm problem.
## How to prove no backdoor
The way to prove that the generator _H_ was chosen in good faith is to be transparent about how it was created. In practice this means using some sort of cryptographic hash function. For example, Bulletproofs hashed âbulletproof_gâ and âbulletproof_hâ to create itâs values of _G_ and _H_. Bulletproofs require multiple values of _G_ and _H_ and so consecutive integers were concatenated to the strings before hashing.
Reversing a cryptographic hash like SHA256 is impractical, even assuming you have a quantum computer, and so it is extremely unlikely that there is a backdoor when the generators were created by hashing a natural string.
Itâs said that Pedersen commitments do not require a **trusted setup**. Thatâs true in spirit, but more precisely they require a transparent setup that is easy to trust.
## Homomorphic encryption
The function
_C_ : (_v_ , _x_) ⌠_vG_ + _xH_
is a **group homomorphism** from pairs of integers to the subgroup generated by _G_ and _H_. This means that
_C_(_v_ , _x_) + _C_(_v_ â, _x_ â) = _C_(_v_ + _v_ â, _x_ + _x_ â)
or in other words, you can combine multiple commitments into a single commitment. The sum of a commitment to (_v_ , _x_) and a commitment to (_v_ â, _x_ â) is a commitment to (_v_ + _v_ â, _x_ + _x_ â).
## Related posts
* How and why Bitcoin uses Merkle trees
* Monero stealth addresses
* Zero knowledge proof of compositeness
[1] In practice the number _x_ is enormous, say on the order of the number of points on the elliptic curve, and so software does not add _H_ to itself _x_ times. Instead it uses a process analogous to fast exponentiation. In fact, if you write the group operation multiplicatively rather than addititively, it is exactly fast exponentiation. https://www.johndcook.com/blog/2025/12/06/pedersen-commitment/
