kernel
), resulting in a large space saving compared to other blockchains.k*H
, which is also a point on curve C. Given another integer j we can also calculate (k+j)*H
, which equals k*H + j*H
. The addition and scalar multiplication operations on an elliptic curve maintain the distributive property of addition and multiplication:k*H
is considered the corresponding public key. Even if one knows the value of the public key k*H
, deducing k is close to impossible (or said differently, while multiplication is trivial, "division" by curve points is extremely difficult).(k+j)*H = k*H + j*H
, with k and j both private keys, demonstrates that a public key obtained from the addition of two private keys ((k+j)*H
) is identical to the addition of the public keys for each of those two private keys (k*H + j*H
). In the Bitcoin blockchain, Hierarchical Deterministic wallets heavily rely on this principle. Mimblewimble and the Grin implementation do as well.v*H
instead of v in a transaction. This works because using the ECC operations, we can still validate that the sum of the outputs of a transaction equals the sum of inputs:v1*H
reveals all outputs with value v1 across the blockchain. We introduce a second point G on the same elliptic curve (practically G is just another generator point on the same curve group as H) and a private key r used as a blinding factor.r*G
is the public key for r (using G as generator point).v*H
(using Has generator point).r*G + v*H
is called a Pedersen Commitment.85*G
is a valid public key for the generator point G.Y - Xi
(this should be the corresponding public key, for generator point G; 85*G
in the above example). A simple way of doing so is by using the public key Y - Xi
(85*G
) to verify a signature, that was signed using the excess value (85). This ensures that:Y - Xi
).x*H
on the curve looks like any other.r*G + v*H
we can build a proof that shows that v is non-negative and does not overflow.Y - Xi
:(113 + 99)*G + 2*H
) requires that both the numbers 113 and 99 are known in order to be spent; the attacker would thus have successfully locked Carol's UTXO. The requirement for a range proof for the blinding factor prevents this because the attacker doesn't know the number 113 and thus neither (113 + 99). A more detailed description of range proofs is further detailed in the range proof paper.r*G + v*H
.r*G
simply is the public key of the excess value r. To mitigate this we redefine the kernel excess from r*G
to (r-kernel_offset)*G
and distribute the kernel offset to be included with every transaction kernel. The kernel offset is thus a blinding factor that needs to be added to the excess value to ensure the commitments sum to zero:r*G + 0*H
with the offset a
, the transaction is signed with (r-a)
and a is published so that r*G
could be computed in order to verify the validity of the transaction: given the kernel excess (recall that it is given as part of the transaction kernel) (r-a)*G
and the offset a
, one computes a*G
and obtains (r-a)*G + a*G = r*G
. During block construction all kernel offsets are summed to generate a single aggregate kernel offset to cover the whole block. The kernel offset for any individual transaction is then unrecoverable and the subset problem is solved.(r-a)*G
, which is the (modified) kernel excess.(r-a)
as the private (signing) key.