diff --git a/doc/intro.md b/doc/intro.md index baa4d50a9..8cb6bab86 100644 --- a/doc/intro.md +++ b/doc/intro.md @@ -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