"Grin, a new cryptocurrency using the mimblewimble protocol, has excited the whole market for days. But its related tutorials are not good.
Pedersen commitment is used for grin output. The output form is as follows:
Grin output - Pedersen commitment scheme.
Pedersen commitment is a clever way to hide information. If this is the first time you hear commitment, you can understand it as "hidden value" when you see this word again.
If we choose a very large number k as the private key, K * h is considered the corresponding public key. Even if we know the value of public key K * h, it is almost impossible to deduce the value of K
• R is the private key, used as the blind factor, G is the fixed point on the elliptic curve, and their product R * g is the public key of R on the curve.
• V is the input or output value and H is another fixed point on the elliptic curve.
In the formula (K + J) * H = k * H + J * h, K and j are both private keys, indicating that the two private keys and the obtained public key (K + J) * h are equal to the corresponding public key sum of each private key (k * H + J * h).
There is a more in-depth study of cryptography in ECC introduction, but in short, to spend grin, we must know the blind factor (R) and the number of grins (V). It is impossible to deconstruct the commitment to infer these values. We must know these values in advance.
The blind factor exists because the people who pay you grin also know the value of V (how many grins they send you). But only you (not the sender of GRIN) know the blind factor of the output, so only you can spend the output.
It is assumed that the pen output uses a blind factor of 20, and the pen output includes 40 grins（ Note: the number of grins is actually sent in multiples of atomic unit 1 nanogrin. For simplicity, we use "grin" here.):
In this pen output, the blind factor is 20 and the number of grins is 40
If you look at grin's blockchain browser, you will find that this output will not be neatly decomposed as described above. The following is the real grin output, just like what we created:
Grin output form (under the commit column)
Similarly, it is impossible to derive "20" (blind factor) or "40" (GRIN number) from this output.
Cost output
Suppose the output we show belongs to Alice. Now, Alice wants to send 25 of the 40 grins to Bob. For convenience of explanation, we will ignore the miner's fee.
If you buy a $3 item with a $5 bill, you will get $2 change (balance). The same is true of bitcoin trading, and grin is no exception. If Alice wants to send 25 grins to Bob from her unused 40 grin outputs, she will also create an output in the same transaction, which will return the remaining 15 grins (change) to herself.
Alice determines the number of grins she wants to send to Bob and their balance.
These 15 grins will be returned to Alice's account, which means that only she can control and spend again. In other words, Bob can't spend Alice's 15 change. To do this, Alice must create a new blind factor for these 15 changes. Suppose Alice chooses 34 as the blind factor.
Alice knows both the R value (the blind factor of the zero output) and the V value (the number of remaining grins). In this way, she has all the information she needs to create a change output (CO). This will also be recorded on the blockchain as an output, just like the output that Alice quickly generated and sent 25 grins to Bob.
Alice's balance output.
As mentioned earlier, to spend any output, you must know the blind factor used in the output. Alice knows the blind factor (20) used in the output she wants to spend, but she needs a way to prove to everyone that she knows.
To do this, she needs to create a completely independent calculation method - blind factor sum. Here, Alice needs to subtract the blind factor (20) of the output she wants to spend from the blind factor (34) she just created for her balance output.
The sum of Alice's blind factors.
S (s represents the sender, i.e. Alice) is the sum of all blind factors of Alice. In this example, the sum is 14（ Note: in this article, I intentionally ignored kernel offset).
Finally, Alice creates a random number KS (s also represents the sender). She will use this random number to build a signature for the transaction, and we will show the process of building the signature later. Alice will not send the actual random number to Bob. Instead, she sends KS • g, which is a commitment to the random number. As mentioned earlier, Alice multiplies the random number by the generation point G, thereby hiding the value of the actual random number.
Alice will send the following information to Bob. But in fact, grin data is not divided into "metadata" and "data" fields. For the sake of clarity, we will express it here in the following form.
All the information Alice sent to Bob in the first step of this grin transaction.
Metadata fields include:
1. Sent quantity: the number of grins Alice wants to send to Bob (25 in this example).
2. TX UUID: the unique identifier used by Alice and Bob to identify this transaction when sending data back and forth.
3. TX fee: transaction fee (not discussed in this tutorial).
4. Block height (lock)_ Height: the block number when the transaction takes effect.
Data fields include:
1. TX input: output not spent. Alice is used as the input for transaction with Bob.
2. Co: Alice's balance output.
3. KS • G: Alice's random number KS is multiplied by the generation point G to become a commitment to the random number.
4. RS • G: the sum of all blind factors rs of Alice multiplied by the generation point G becomes the commitment to this value.
Alice sends all the above data to Bob, and Bob continues with the next step.
It's Bob's turn
After receiving the data from Alice, Bob will the transaction fee (TX fee) and block height (lock_ Height) variable to create m, which we call the "message" of the transaction.
"Information" of the transaction
Bob selects a blind factor RR for the 25 grins he wants to receive from Alice (R represents the receiver, in this case Bob). Suppose he chooses 11 as the blind factor RR and his own random number Kr (r also represents the receiver).
As Alice did, Bob also multiplies these two values by the generation point G to create a commitment to these two values. Bob then uses these values to generate a Schnorr challenge for the transaction, which is represented by the variable E:
Schnorr challenge of the transaction.
Schnorr challenge contains the sha256 hash of the following in order:
1. Transaction information.
2. Alice and Bob use the promised sum of random numbers.
3. Sum of blind factor commitments of Bob (25 grin outputs) and sum of all blind factors of Alice.
Bob uses e to generate his Schnorr Signature for the transaction, Sr (R represents the receiver). Although this is the whole content of Bob's signature, we call it Bob's partial signature because it will eventually be added to Alice's partial signature to get the signature of the whole transaction.
Part of Bob's signature on this transaction
When Alice finally receives Sr, she cannot know the value of Kr or RR.
Bob sends the following back to Alice:
Bob sends back his partial signature, random number commitment and commitment to output blind factor to Alice.
These include, in order:
1. SR: partial signature of Bob.
2. Kr • G: Bob's random number commitment
3. RR • G: Bob promised the 25 grin blind factors he wanted
Last step: back to Alice
Alice now has all the information she needs to calculate e locally, that is, the Schnorr challenge of the transaction. After calculating e locally, Alice can verify Bob's partial signature.
Bob's partial signature SR contains the following:
Part of Bob's signature on this transaction
Based on the properties of the elliptic curve we described earlier, Alice can introduce the generation point G into both sides of the equation, and the equation is still valid.
Alice multiplies both sides of the equation by the generating point G.
Since Alice received Bob's Kr • g (Bob's random number commitment) and RR • g (Bob's blind factor commitment, he will use the blind factor to obtain the 25 grins he will receive), and since E has been calculated locally, Alice can simply multiply the generation point G and ensure that the right side of the equation is equal to this value, so as to verify Bob's partial signature Sr.
In this way, Alice proved that:
1. Bob knows how many grins he will receive (25).
2. Bob knows his random number.
3. Bob knows the 25 grin blind factors he wants.
Alice doesn't know Bob's random number or blind factor.
Next, Alice generates her own partial signature:
Alice generated a partial signature for the transaction.
Alice can now generate the signature of the transaction, including some signatures of Alice and Bob:
Transaction signature, including the sum of partial signatures of Alice and Bob and the commitment to their random numbers.
The signatures include, in order:
1. Sum of partial signatures of Alice and Bob.
2. The sum of Alice and Bob's random number commitments (they don't know each other's real random number).
After simplification, the signature is shown as:
Signature of the transaction
Where s = SS + Sr, k = KS + KR
Remember this signature and you will soon understand its meaning.
Complete the transaction
Digital currency needs "memory" - that is, when you send a sum of money to one person, you can't send it to another person. The operation mode of GRIN hides the number of grins sent and the receiver. So how can we prove that a sum of money has not been repeatedly paid or created out of thin air?
In a grin transaction, when all outputs are subtracted from the input, the number of remaining grins should be equal to 0. So back to the previous $5 example:
Give the cashier 3 US dollars (output) + 2 US dollars change and return it to me (output) – 5 US dollars bill (input) = 0
In grin's transaction, when a transaction is legal, the same summation makes the sum of V values zero. But how can we prove this without showing these values? Let's look at the inputs and outputs used in the transaction from Alice to Bob:
（34•G） + （15•H） + （11•G） + （25•H） - （20•G） - （40•H） = （25•G） + （0•H）
The trick here is that when the number of grins is offset (there is no result that should be obtained if there is no creation out of thin air), what is left after subtracting the output from the input is the commitment of "the excess blinding factor", or "kernel excess". In this example, the commitment of the blind factor is 25 • g, which is the public key on the curve.
If the total output minus the total input of a grin transaction will produce a valid public key on the curve, you will know that the V value must have been offset. If the right side of the equation is not in the form of n • G + 0 • h for a known value of N, the transaction is invalid. This means that either the amount spent is greater than the sum of the input (for example, you take out a $5 bill and pay the cashier $3, but get a change of $10), or the input is greater than the output (for example, you take out a $5 bill and pay the cashier $3, but no change).
Remember this signature?
Signature of the transaction
This signature has actually signed a commitment to the too many blind factors I just mentioned. This is explained below.
If you remember, this is Bob's partial signature when you multiply the generating point G on both sides of the equation at the same time.
When both sides are multiplied by the generation point G at the same time, Bob's partial signature.
Similarly, the following is the partial signature of Alice after both sides of the equation are multiplied by the generation point G at the same time.
After both sides of the equation are multiplied by the generation point G at the same time, Alice's partial signature.
What happens if two equations are added together? You will get:
sr•G + ss•G = （kr • G） + （ks • G） + （e • （rr•G + rs•G））
Remember, RR is Bob's blind factor and RS is the sum of Alice's blind factors. The previously mentioned RR • G + RS • G is equivalent to (RR + RS) • G.
Bob's commitment to his blind factor is 11 • G. Alice's commitment to the sum of her blind factors is 14 • G. Add the two together to get 25 • g, which is the commitment to too many blind factors in the transaction. Therefore, adding Sr and SS (partial signatures of Bob and Alice) proves the effectiveness of the whole transaction, because they add up to a commitment to too many blind factors.
Further simplifying the equation, we will get:
sr•G + ss•G = （k•G） + （e • （r•G））
Or:
Our other product:
