Can someone explain to me in human language how the blind signature scheme in WabiSabi works?
How do you blind, sign, unblind? It's something with randomizing Pedersen commitments but I'd like to gain some intuition. Appreciated <3
Discussion
This might be the ELI5 you are looking for.
https://github.com/zkSNACKs/WabiSabi/blob/master/explainer.md
I need someone to hold my hands while I grock the HVAC math ser. The Signal paper was a bit more expressive, I'm getting there.
Haven’t a clue. I presume you’ve heard the carbon copy paper envelope analogy? Signing the envelope copies the signature to the envelope contents but reveals nothing about the contents to the signer.
This analogy is generally useful for any kind of blind signing. Dr Calle seems to be looking for details on how tbe blind signing work for WabiSabi.
https://lontivero.github.io/Wiki/html/cashabi.html
Vs
Dr…missed that.
So…yeah, lol, I doubt he needed the general public hand waving intuitive view! I figured he was (like a lot of us here) a newbie pleb wondering how such a miracle could be possible (a lot of crypto stuff seems unbelievable!).
Lol. Dude did the phd thing and i saw your title and couldnt help myself. 😅
No worries! Hes in fact a lead contributor and perhaps creator of the cashu ecash protocol. I follow him for big brain stuff and occasional snarky notes 🙃
Did you see Max hillebrand’s reply?
This is some seriously awesome tech. Homomorphic encryption lets signers and miners see input = output but not individual values of inputs and outputs. I wonder if it can show input - output = exact number (for miner fees)…
But this is crucial to solving the bitcoin fungibility problem. Which, imho, from a legal perspective, is the biggest elephant in the room…
I saw but am too dumb to grok.
did you see some of the other replies?
https://youtu.be/Ia-mH6XuFcA?si=7X38m0MMOO0qklwd
Interesting podcast on a cryptographic proof of utxo set. The idea being one can prove validity of utxo set essentially instantly instead of downloading half a terabyte of bitcoin data.
Basically, a Wabisabi transfer always has two inputs, and two outputs.
The inputs are the unspent ecash tokens which are destroyed, so basically a message and signature part.
The outputs are the new ecash tokens to be created, basically the blinded message which the mint is meant to sign.
Each ecash token has not just the blind signature, but also a commitment to a homomorphic encrypted value of sats.
With this homomorphic encrypted values, the mint can verify that the sum of the two inputs are exactly equal to the sum of the two outputs. Which prevents the unwanted inflation of tokens, without revealing the actual value of any of the four tokens of the transaction.
There are also zero value tokens which are needed to split up a single coin. For example, one input worth 5 btc, one input worth 0 btc, one output worth 3 btc, one output worth 2 btc. The mint verifies that 5+0=3+2, but has no idea what value any or the tokens have.
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)`
