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

tweak excess example in docs (#1443)

Browse source 
* tweak excess example in docs

* remove reference to ECDSA signature.
remove references to passing sums of blinding factors around

* cleanup reference to _what_ is signed

* tweak who knows the private key
This commit is contained in:
Antioch Peverell 2018-08-29 12:54:33 +01:00 committed by GitHub
parent c334c557aa
commit e5d43fee44
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 26 additions and 40 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

66
doc/intro.md
View file

@ -159,23 +159,23 @@ 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
should only be spendable by you:
X = 113*G + 3*H
X = 28*G + 3*H
_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 28 is only known to you.
To transfer those 3 coins again, the protocol requires 113 to be known somehow.
To transfer those 3 coins again, the protocol requires 28 to be known somehow.
To demonstrate how this works, let's say you want to transfer those 3 same coins to Carol.
You need to build a simple transaction such that:
Xi => Y
Where _Xi_ is an input that spends your _X_ output and Y is Carol's output. There is no way to build
such a transaction and balance it without knowing your private key of 113. Indeed, if Carol
such a transaction and balance it without knowing your private key of 28. Indeed, if Carol
is to balance this transaction, she needs to know both the value sent and your private key
so that:
Y - Xi = (113*G + 3*H) - (113*G + 3*H) = 0*G + 0*H
Y - Xi = (28*G + 3*H) - (28*G + 3*H) = 0*G + 0*H
By checking that everything has been zeroed out, we can again make sure that
no new money has been created.
@ -184,30 +184,28 @@ Wait! Stop! Now you know the private key in Carol's output (which, in this case,
be the same as yours to balance out) and so you could
steal the money back from Carol!
To solve this, we allow Carol to add another value of her choosing. She picks 28, and
what ends up on the blockchain is:
To solve this, Carol uses a private key of her choosing.
She picks 113 say, and what ends up on the blockchain is:
Y - Xi = ((113+28)*G + 3*H) - (113*G + 3*H) = 28*G + 0*H
Y - Xi = (113*G + 3*H) - (28*G + 3*H) = 85*G + 0*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*G` is
a valid public key on the elliptic curve _G_, with private key 28,
Now the transaction no longer sums to zero and we have an _excess value_ on _G_
(85), which is the result of the summation of all blinding factors. But because `85*G` is
a valid public key on the elliptic curve _G_, with private key 85,
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 _G_ and that
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),
the transacting parties collectively know the private key (85 in our transaction with Carol). The
simplest way to do so is to require a signature built with the excess value (85),
which then validates that:
* The author of the transaction knows the excess value (which is also the
private key for the output)
* The sum of the transaction's outputs, minus the inputs, adds to a zero value
* The transacting parties collectively know the private key, and
* The sum of the transaction outputs, minus the inputs, sum to a zero value
(because only a valid public key, matching the private key, will check against
the signature).
Hence, what is being signed does not even matter (it can just be an empty string "").
That signature, attached to every transaction, together with some additional data (like mining
fees), is called a _transaction kernel_.
This signature, attached to every transaction, together with some additional data (like mining
fees), is called a _transaction kernel_ and is checked by all validators.
### Some Finer Points
@ -219,30 +217,18 @@ Grin, so if you're in a hurry, feel free to jump straight to
#### Change
In the above example, you had to share your private key (the blinding factor) with
Carol. In general, even though private keys should never be reused, this isn't
generally very desirable. Practically, this isn't an issue because transactions
include a change output.
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
protect your change output, and tell Carol you're sending her 2 coins and that
for her transaction to be balanced she should use 113-42 as sum of blinding
factors.
Alice. To do this you would send the remaining 1 coin back to yourself as change.
You generate another private key (say 12) as a blinding factor to
protect your change output. Carol uses her own private key as before.
Then Carol adds her own excess value of 28 (for example) and we get as outputs:
Change output: 12*G + 1*H
Carol's output: 113*G + 2*H
Your change: 42*G + 1*H
Carol: (113-42+28)*G + 2*H
What ends up on the blockchain is something very similar to before.
And the signature is again built with the excess value, 97 in this example.
The final sum that all validators end up doing looks like:
(42*G + 1*H) + (99*G + 2*H) - (113*G + 3*H) = 28*G + 0*H
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
factors for the input and change. The signature is included in the _transaction kernel_
which will be checked by all transaction validators.
(12*G + 1*H) + (113*G + 2*H) - (28*G + 3*H) = 97*G + 0*H
#### Range Proofs
@ -254,7 +240,7 @@ create new funds in every transaction.
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
the previous sections. This can't be easily detected because even if _x_ is
negative, the corresponding point `x.H` on the ECDSA curve looks like any other.
negative, the corresponding point `x.H` on the curve looks like any other.
To solve this problem, MimbleWimble leverages another cryptographic concept (also
coming from Confidential Transactions) called