Core/grin
0
0
Fork 0
mirror of https://github.com/mimblewimble/grin.git synced 2025-02-01 17:01:09 +03:00
Code Issues Projects Releases Packages Wiki Activity Actions

Small tweaks to intro doc following John Tromp's review

Browse source 
* Various typo fixes and minor improvements.
* Switch from v*G + k*H to r*G + v*G as symbols to stay more consistent
with the rest of the litterature.
This commit is contained in:
Ignotus Peverell 2017-03-21 14:05:10 -07:00
parent cc63c17f39
commit f9f69dea25
No known key found for this signature in database
GPG key ID: 99CD25F39F8F8211
1 changed files with 50 additions and 48 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

96
doc/intro.md
View file

@ -12,14 +12,14 @@ cryptocurrency deployment.
The main goal and characteristics of the Grin project are: The main goal and characteristics of the Grin project are:
* Privacy as a default. This enables complete fungibility without precluding * Privacy by default. This enables complete fungibility without precluding
the possibility to ability to optionally disclose information as needed. the possibility to ability to selectively disclose information as needed.
* Scales with the number of users and not the number of transactions, with very * Scales with the number of users and not the number of transactions, with very
large space savings compared to other blockchains. large space savings compared to other blockchains.
* Strong and proven cryptography. MimbleWimble only relies on Elliptic Curve * Strong and proven cryptography. MimbleWimble only relies on Elliptic Curve
Cryptography which has been tried and tested for decades. Cryptography which has been tried and tested for decades.
* Design simplicity that makes it easy to audit and maintain over time. * Design simplicity that makes it easy to audit and maintain over time.
* Community driven, using an asic-resistent mining algorithm (Cuckoo Cycles) * Community driven, using an asic-resistent mining algorithm (Cuckoo Cycle)
encouraging mining decentralization. encouraging mining decentralization.
# Tongue Tying for Everyone # Tongue Tying for Everyone
@ -31,7 +31,7 @@ this document is understandable to most technically minded readers. Our objectiv
to encourage you to get interested in Grin and contribute in any way possible. to encourage you to get interested in Grin and contribute in any way possible.
To achieve this objective, we will introduce the main concepts required for a good To achieve this objective, we will introduce the main concepts required for a good
understanding of Grin as a MimbleWimble implementation. We will start with brief understanding of Grin as a MimbleWimble implementation. We will start with a brief
description of some relevant properties of Elliptic Curve Cryptography (ECC) to lay the description of some relevant properties of Elliptic Curve Cryptography (ECC) to lay the
foundation on which Grin is based and then describe all the key elements of a foundation on which Grin is based and then describe all the key elements of a
MimbleWimble blockchain's transactions and blocks. MimbleWimble blockchain's transactions and blocks.
@ -50,16 +50,16 @@ the addition and multiplication operations have been defined, just like we know
to do additions and multiplications on numbers or vectors. Given a number _k_ and to do additions and multiplications on numbers or vectors. Given a number _k_ and
using the multiplication operation we can compute `k*H`, which is also a point on using the multiplication operation we can compute `k*H`, which is also a point on
_H_. Given another number _j_ we can also calculate `(k+j)*H` which is equivalent _H_. Given another number _j_ we can also calculate `(k+j)*H` which is equivalent
to `k*H + j*H`. Given that the addition and multiplication operations on an elliptic to `k*H + j*H`. The addition and multiplication operations on an elliptic curve
curve maintain the commutative and associative properties of addition and maintain the commutative and associative properties of addition and multiplication:
multiplication:
(k+j)*H = k*H + j*H (k+j)*H = k*H + j*H
In ECC, if we pick a very large number _k_ used as a private key, `k*H` is In ECC, if we pick a very large number _k_ as a private key, `k*H` is
defined as the corresponding public key. Even if one knows the 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 value of the public key `k*H`, deducing _k_ is close to impossible (or said
differently, while multiplication is trivial, "division" is extremely difficult). differently, while multiplication is trivial, "division" by curve points is
extremely difficult).
The previous formula `(k+j)*H = k*H + j*H`, with _k_ and _j_ both private The previous formula `(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, demonstrates that a public key obtained from the addition of two private
@ -70,12 +70,12 @@ implementation do as well.
## Transacting with MimbleWimble ## Transacting with MimbleWimble
The structure of transactions demonstrate a crucial tenet of MimbleWimble: The structure of transactions demonstrates a crucial tenet of MimbleWimble:
strong privacy and confidentiality guarantees. strong privacy and confidentiality guarantees.
The validation of MimbleWimble transactions rely on two basic properties: The validation of MimbleWimble transactions relies on two basic properties:
* **Verification of zero sums.** The sum of outputs minus the inputs always equals zero, * **Verification of zero sums.** The sum of outputs minus inputs always equals zero,
proving that the transaction did not create new funds, _without revealing the actual amounts_. proving that the transaction did not create new funds, _without revealing the actual amounts_.
* **Possession of private keys.** Like with most other cryptocurrencies, ownership of * **Possession of private keys.** Like with most other cryptocurrencies, ownership of
transaction outputs is guaranteed by the possession of ECC private keys. However, transaction outputs is guaranteed by the possession of ECC private keys. However,
@ -90,32 +90,33 @@ fundamental properties are achieved.
Building up on the properties of ECC we described above, one can obscure the values Building up on the properties of ECC we described above, one can obscure the values
in a transaction. in a transaction.
If _v_ is the value of a transaction input or output and _G_ an ECC curve, we can simply If _v_ is the value of a transaction input or output and _H_ an ECC curve, we can simply
embed `v*G` instead of _v_ in a transaction. This works because using the ECC embed `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 operations, we can still validate that the sum of the outputs of a transaction equals the
sum of inputs: sum of inputs:
v1 + v2 = v3 => v1*G + v2*G = v3*G v1 + v2 = v3 => v1*H + v2*H = v3*H
Verifying this property on every transaction allows the protocol to verify that a Verifying this property on every transaction allows the protocol to verify that a
transaction doesn't create money out of thin air, without knowing what the actual transaction doesn't create money out of thin air, without knowing what the actual
values are. However, there are a finite number of possible values and one could try every single values are. However, there are a finite number of usable values and one could try every single
one of them to guess the value of your transaction. In addition, knowing v1 (from one of them to guess the value of your transaction. In addition, knowing v1 (from
a previous transaction for example) and the resulting `v1*G` reveals all outputs with a previous transaction for example) and the resulting `v1*H` reveals all outputs with
value v1 across the blockchain. For these reasons, we introduce a second ECC curve value v1 across the blockchain. For these reasons, we introduce a second ECC curve
_H_ and a private key _k_ used as a *blinding factor*. _G_ and a private key _r_ used as a *blinding factor*.
An input or output value in a transaction can then be expressed as: An input or output value in a transaction can then be expressed as:
v*G + k*H r*G + v*H
Where: Where:
* _v_ is the value of an input or output and _G_ is an elliptical curve. * _r_ is a private key used as a blinding factor, _G_ is an elliptical curve and
* _k_ is a private key used as a blinding factor, _H_ is another elliptical curve and their product `k*H` is the public key for _k_ on _H_. their product `r*G` is the public key for _r_ on _G_.
* _v_ is the value of an input or output and _H_ is another elliptical curve.
Neither _v_ nor _k_ can be deduced, leveraging the fundamental properties of Elliptic Neither _v_ nor _r_ can be deduced, leveraging the fundamental properties of Elliptic
Curve Cryptography. `v*G + k*H` is called a _Pedersen Commitment_. Curve Cryptography. `r*G + v*H` is called a _Pedersen Commitment_.
As a an example, let's assume we want to build a transaction with one input and two As a an example, let's assume we want to build a transaction with one input and two
outputs. We have (ignoring fees): outputs. We have (ignoring fees):
@ -130,11 +131,11 @@ Such that:
Generating a private key as a blinding factor for each input value and replacing each value Generating a private key as a blinding factor for each input value and replacing each value
with their respective Pedersen Commitments in the previous equation, we obtain: with their respective Pedersen Commitments in the previous equation, we obtain:
(vi1*G + ki1*H) + (vi2*G + ki2*H) = (vo3*G + ko3*H) (ri1*G + vi1*H) + (ri2*G + vi2*H) = (ro3*G + vo3*H)
Which as a consequence requires that: Which as a consequence requires that:
ki1 + ki2 = ko3 ri1 + ri2 = ro3
This is the first pillar of MimbleWimble: the arithmetic required to validate a This is the first pillar of MimbleWimble: the arithmetic required to validate a
transaction can be done without knowing any of the values. transaction can be done without knowing any of the values.
@ -155,7 +156,7 @@ blinding factor (note that in practice, the blinding factor being a private key,
extremely large number). Somewhere on the blockchain, the following output appears and extremely large number). Somewhere on the blockchain, the following output appears and
should only be spendable by you: should only be spendable by you:
X = 3*G + 113*H X = 113*G + 3*H
_X_, the result of the addition, is visible by everyone. The value 3 is only known to you and Alice, _X_, the result of the addition, is visible by everyone. The value 3 is only known to you and Alice,
and 113 is only known to you. and 113 is only known to you.
@ -171,7 +172,7 @@ such a transaction and balance it without knowing your private key of 113. Indee
is to balance this transaction, she needs to know both the value sent and your private key is to balance this transaction, she needs to know both the value sent and your private key
so that: so that:
Y - Xi = (3*G + 113*H) - (3*G + 113*H) = 0*G + 0*H Y - Xi = (113*G + 3*H) - (113*G + 3*H) = 0*G + 0*H
By checking that everything has been zeroed out, we can again make sure that By checking that everything has been zeroed out, we can again make sure that
no new money has been created. no new money has been created.
@ -183,14 +184,14 @@ steal the money back from Carol!
To solve this, we allow Carol to add another value of her choosing. She picks 28, and To solve this, we allow Carol to add another value of her choosing. She picks 28, and
what ends up on the blockchain is: what ends up on the blockchain is:
Y - Xi = (3*G + (113+28)*H) - (3*G + 113*H) = 0*G + 28*H Y - Xi = ((113+28)*G + 3*H) - (113*G + 3*H) = 28*G + 0*H
Now the transaction doesn't sum to zero anymore, we have an _excess value_ on _H_ Now the transaction doesn't sum to zero anymore, we have an _excess value_ on _G_
(28), which is the result of the summation of all blinding factors. But because `28*H` is (28), which is the result of the summation of all blinding factors. But because `28*G` is
a valid public key on the elliptic curve _H_, with private key 28, a valid public key on the elliptic curve _G_, with private key 28,
for any x and y, only if `x = 0` is `x*G + y*H` a valid public key on H. for any x and y, only if `y = 0` is `x*G + y*H` a valid public key on _G_.
So all the protocol needs to verify is that (`Y - Xi`) is a valid public key on H and that So all the protocol needs to verify is that (`Y - Xi`) is a valid public key on _G_ and that
the transaction author knows the private key (28 in our transaction with Carol). The the transaction author knows the private key (28 in our transaction with Carol). The
simplest way to do so is to require an ECDSA signature built with the excess value (28), simplest way to do so is to require an ECDSA signature built with the excess value (28),
when then validates that: when then validates that:
@ -209,7 +210,7 @@ fees), is called a _transaction kernel_.
This section elaborates on the building of transactions by discussing how change is This section elaborates on the building of transactions by discussing how change is
introduced and the requirement for range proofs so all values are proven to be introduced and the requirement for range proofs so all values are proven to be
positive. Neither of these are absolutely required to understand MimbleWimble and non-negative. Neither of these are absolutely required to understand MimbleWimble and
Grin, so if you're in a hurry, fee free to jump straight to Grin, so if you're in a hurry, fee free to jump straight to
[Putting It All Together](#transaction-conclusion). [Putting It All Together](#transaction-conclusion).
@ -222,19 +223,20 @@ include a change output.
Let's say you only want to send 2 coins to Carol from the 3 you received from Let's say you only want to send 2 coins to Carol from the 3 you received from
Alice. You simply generate another private key (say 42) as a blinding factor to Alice. You simply generate another private key (say 42) as a blinding factor to
protect your change output, and tell Carol you're sending her 2 coins and that for her transaction to be protect your change output, and tell Carol you're sending her 2 coins and that
balanced she should use 113-42 as sum of blinding factors. for her transaction to be balanced she should use 113-42 as sum of blinding
factors.
Then Carol adds her own excess value of 28 (for example) and we get as outputs: Then Carol adds her own excess value of 28 (for example) and we get as outputs:
Your change: 1*G + 42*H Your change: 42*G + 1*H
Carol: 2*G + (113-42+28)*H Carol: (113-42+28)*G + 2*H
The final sum that all validators end up doing looks like: The final sum that all validators end up doing looks like:
(1*G + 42*H) + (2*G + 99*H) - (3*G + 113*H) = 0*G + 28*H (42*G + 1*H) + (99*G + 2*H) - (113*G + 3*H) = 28*G + 0*H
Carol generates a signature with `28*H` as public key, as described in the previous Carol generates a signature with `28*G` as public key, as described in the previous
section, to prove that the value is zero and that she was given the summation of blinding section, to prove that the value is zero and that she was given the summation of blinding
factors for the input and change. The signature is included in the _transaction kernel_ factors for the input and change. The signature is included in the _transaction kernel_
which will be checked by all transaction validators. which will be checked by all transaction validators.
@ -248,13 +250,13 @@ create new funds in every transaction.
For example, one could create a transaction with an input of 2 and outputs of 5 For example, one could create a transaction with an input of 2 and outputs of 5
and -3 and still obtain a well-balanced transaction, following the definition in and -3 and still obtain a well-balanced transaction, following the definition in
the previous sections. This can't be easily detected because even if _x_ is the previous sections. This can't be easily detected because even if _x_ is
negative, the corresponding point `x.G` on the ECDSA curve may not be. negative, the corresponding point `x.H` on the ECDSA curve looks like any other.
To solve this problem, MimbleWimble leverages another cryptographic concept (also To solve this problem, MimbleWimble leverages another cryptographic concept (also
coming from Confidential Transactions) called coming from Confidential Transactions) called
range proofs: a proof that a number falls within a given range, without revealing range proofs: a proof that a number falls within a given range, without revealing
the number. We won't elaborate on the range proof, but you just need to know the number. We won't elaborate on the range proof, but you just need to know
that for any `v.G + k.H` we can build a proof that will show that _v_ is greater than that for any `r.G + v.H` we can build a proof that will show that _v_ is greater than
zero and does not overflow. zero and does not overflow.
<a name="transaction-conclusion"></a> <a name="transaction-conclusion"></a>
@ -265,8 +267,8 @@ A MimbleWimble transaction includes the following:
* A set of inputs, that reference and spend a set of previous outputs. * A set of inputs, that reference and spend a set of previous outputs.
* A set of new outputs that include: * A set of new outputs that include:
* A value and a blinding factor (which is just a new private key) multiplied on * A value and a blinding factor (which is just a new private key) multiplied on
a curve and summed to be `v.G + k.H`. a curve and summed to be `r.G + v.H`.
* A range proof that shows that v is positive. * A range proof that shows that v is non-negative.
* An explicit transaction fee, in clear. * An explicit transaction fee, in clear.
* A signature, computed by taking the excess blinding value (the sum of all * A signature, computed by taking the excess blinding value (the sum of all
outputs plus the fee, minus the inputs) and using it as a private key. outputs plus the fee, minus the inputs) and using it as a private key.
@ -331,7 +333,7 @@ A block is simply built from:
* The list of inputs remaining after cut-through. * The list of inputs remaining after cut-through.
* The list of outputs remaining after cut-through. * The list of outputs remaining after cut-through.
* The transaction kernels containing, for each transaction: * The transaction kernels containing, for each transaction:
* The public key `k*H` obtained from the summation of all the commitments. * The public key `r*G` obtained from the summation of all the commitments.
* The signatures generated using the excess value. * The signatures generated using the excess value.
* The mining fee. * The mining fee.
@ -351,7 +353,7 @@ And yet, it all still validates!
Going back to the previous example block, outputs x1 and x2, spent by I1 and Going back to the previous example block, outputs x1 and x2, spent by I1 and
I2, must have appeared previously in the blockchain. So after the addition of I2, must have appeared previously in the blockchain. So after the addition of
this block, those outputs as well as I1 and I2 an also be removed from the this block, those outputs as well as I1 and I2 can also be removed from the
overall chain, as they do not contribute to the overall sum. overall chain, as they do not contribute to the overall sum.
Generalizing, we conclude that the chain state (excluding headers) at any point Generalizing, we conclude that the chain state (excluding headers) at any point