Proving that a block is valid

Tech Support
1

I’m trying to wrap my head around MimbleWimble and Grin. I’m first attempting to show that a block is valid. Much of my understanding came from the excellent Mimblewimble documentation.

As I understand it, the sum of a block’s outputs minus the sum of the block’s inputs should equal the sum of the kernel excesses. I believe all these items: outputs, inputs, and excesses are represented as public keys - is that right?

So, given this block, I see the output and input commits. Are these Pedersen Commitment public keys? I don’t see any kernel excess keys, I’m guess they are just not shown in the UI - is that right or did I miss something?

1 Like
2

Each block satisfies the equation

Σ outputs - Σ inputs = Σ kernel + offset * G + 60e9 * H

which can be seen is a small variation on the equation for the entire transaction history [1], which has no inputs and the UTXO set as outputs.

No; they’re all Pedersen commitments, but only the kernels are represented as public keys, because they are Pedersen commitments to a zero value.

Correct. It would be nice if they’re shown just like inputs and outputs are.

[1] Oneliner Grin: Σ utxo = Σ kernel + offset * G + height * 60 * H

1 Like
3

Thanks for the clarifications! So is it right to say that the Pedersen commitments can be summed in order to be used in the validity equation you posted? As in these outputs from the example block I posted earlier…

097afb11d708b0f8e6f1168f2d361ecf6332fffc4a6d944cf0a41b732fc788ba62
09fa190d5cb6d845534892e54f0a518e821be069aa082fc6f225b9cfc3717e522d
087fb515e85d2c0090142d24afd94f56b2471c2030e432e26e11a6c80c6a89ee9c

Can these be summed together? Thanks!

4

Yes, those outputs (curve points serialized as a 33 byte DER-encoding) can be summed to form the “Σ outputs” part of the equation above.

1 Like
5

Excellent! Very helpful.

My only other question at this point is around G and H. According to the equation, these values need to be known in order to prove the block validity.

Can you direct me on where to find these values? I was under the impression these were public keys of the sender/receiver but that is probably incorrect.

1 Like
6

You forgot Master Key in first 100byte of each block of you pocket Blockchain and this Master Key make this Coin - Pocket Coin

7

See the thread https://forum.grin.mw/t/definition-of-h-and-g

2 Likes
10

One follow up, can you explain what “offset” is? Thanks!

Update: ah is that the “Total Kernel Offset” as seen here? GrinExplorer - The first Open-Source Grin Blockchain Explorer

11

Yes, each kernel is generated with an accompanying offset. When merging multiple transactions together, as happens in forming a block, the offsets get summed into one.

1 Like
12

An offset is basically a scalar correction of the sum of kernels. After the correction is made, the result (Σkernel + offset*G) is equal to the Σoutputs - Σinputs curve point. A transaction basically has a random curve point being a kernel and comes with a correction scalar offset. When aggregating two transactions, these offset scalars can be summed together to obtain a single offset (their sum) making it impossible to deaggregate the transaction without knowing the original offsets.

13

I’m in way over my head, but I’m slowly learning, damn it. After looking at the official Node code, I observed that the commitments are serialized to_hex (33 byte DER!) and are deserialized from_hex to a bytes array.

Now, because the commitments are curve points, is it right that I need to convert the bytes array into an x and y?

14

If you want to add commitments, then yes, you need to represent them as curve points (x,y) first.

1 Like
15

Is total_kernel_offset, as returned by the api, also a curve point serialized as 33 byte DER?. Example:

5cecafdce371db3e59da8f194437657cfe14876ea40d0f0b904ff5457a9d6f0e

https://grinexplorer.net/block/0000a31177fbc8b77b7f373956e6af906680e4e1ffb9c9d73d50271c631a5aa6

16

No; offsets are always scalars.