lontivero on Nostr: There are 9 publicly known group elements (points in the secp256k1 curve) named Gw, ...
There are 9 publicly known group elements (points in the secp256k1 curve) named Gw, Gw', Gx0, Gx1, GV, Ga, Gg, Gh and Gs.
The credential issuer creates a secret key (sk) that is a 5-tuple (w, w', x0, x1, ya), these are just 5 secp256k1 keys.
The credential issuer computes the public issuer parameters (Cw, I) where Cw = w * Gw + w' * Gw' and I = GV - (x0 * Gx0 + x1 * Gx1 + ya * Ga). The credential issuer publish it.
Now, you want to request a credential for a given amount 'a' but you don't want the issuer to know how much 'a' is. You "hide" the amount in a pedersen commitment `Ma` so, you get a random number 'r' and compute Ma as follow: `Ma = a*Gg + r*Gh`. That commitment is sent to the issuer with a range proof but we can forget about that by imaging everybody is honest.
The issuer receives the request (Ma) and computes a MAC, a 2-tuple (t, V) where `t` is justa random namber (scalar) and V = w*Gw + (x0 + x1*t)*U + ya*Ma. And where U is a group element generated from `t` (U = GroupElementFromHash(t))
For the sake of simplicity lets forget about the proofs the coordinator need to generate and lets assume the issuer is honest. In that scenario, the generated MAC is what we call a credential.
Once you have a credential you can present it to the issuer but obviously you want to "blind" it somehow, otherwise the issuer can recognize it. Remember that at this point you know the MAC (t, V) and Ma, you can compute U from t. So, you "randomize"/"bind" the credential (MAC) as follow:
* compute `z0 = -t * z` where `z` is a random scalar
* compute Z = z * I
* compute Ca = z * Ga + Ma
* compute Cx0 = z * Gx0 + U
* compute Cx1 = z * Gx1 + t * U
* compute CV = z * GV + V
and sends the 4-tuple (Ca, Cx0, Cx1, CV,) to the issuer, which cannot "see" the MAC because it is hidden behind the DLs. This is what we call the "randomized credential". Here, once more, the client must prove the randomized credential is valid but for simplicity lets assume it is not necessary (but it is very important in this case)
The issuer can verify that `Z = CV - (w*Gw + x0*Cx0 + x1*Cx1 + ya*Ca)`
The credential issuer creates a secret key (sk) that is a 5-tuple (w, w', x0, x1, ya), these are just 5 secp256k1 keys.
The credential issuer computes the public issuer parameters (Cw, I) where Cw = w * Gw + w' * Gw' and I = GV - (x0 * Gx0 + x1 * Gx1 + ya * Ga). The credential issuer publish it.
Now, you want to request a credential for a given amount 'a' but you don't want the issuer to know how much 'a' is. You "hide" the amount in a pedersen commitment `Ma` so, you get a random number 'r' and compute Ma as follow: `Ma = a*Gg + r*Gh`. That commitment is sent to the issuer with a range proof but we can forget about that by imaging everybody is honest.
The issuer receives the request (Ma) and computes a MAC, a 2-tuple (t, V) where `t` is justa random namber (scalar) and V = w*Gw + (x0 + x1*t)*U + ya*Ma. And where U is a group element generated from `t` (U = GroupElementFromHash(t))
For the sake of simplicity lets forget about the proofs the coordinator need to generate and lets assume the issuer is honest. In that scenario, the generated MAC is what we call a credential.
Once you have a credential you can present it to the issuer but obviously you want to "blind" it somehow, otherwise the issuer can recognize it. Remember that at this point you know the MAC (t, V) and Ma, you can compute U from t. So, you "randomize"/"bind" the credential (MAC) as follow:
* compute `z0 = -t * z` where `z` is a random scalar
* compute Z = z * I
* compute Ca = z * Ga + Ma
* compute Cx0 = z * Gx0 + U
* compute Cx1 = z * Gx1 + t * U
* compute CV = z * GV + V
and sends the 4-tuple (Ca, Cx0, Cx1, CV,) to the issuer, which cannot "see" the MAC because it is hidden behind the DLs. This is what we call the "randomized credential". Here, once more, the client must prove the randomized credential is valid but for simplicity lets assume it is not necessary (but it is very important in this case)
The issuer can verify that `Z = CV - (w*Gw + x0*Cx0 + x1*Cx1 + ya*Ca)`