Harry Potter, MimbleWimble and Invisibility Cloaks — Building a More Privacy and Scalable Data…

Harry Potter, MimbleWimble and Invisibility Cloaks — Building a More Private, Trustworthy and Scalable Data World

For today, you can call me Dumbledore, and I’m going to write a paper on quantum cryptography. Well, maybe not, but, on 19 July 2016, someone called Tom Elvis Jedusor (Voldemort’s French name in the Harry Potter book) wrote a paper on Bitcoin:

It outlined Mimblewimble (named after a curse in The Deathly Hallows book) [here], and presented a blockchain method which improves privacy, scalability and fungibility. Since it was published in 2016, no-one has seen or heard of Elvis again. But now, Ignotus Peverell (named after the person who originally owned the invisibility cloak in Harry Potter) has created a Git hub for it [here]:

The focus of Mimblewimble is to plug the privacy gap in Bitcoin (and many other blockchain methods), and also to allow it to scale up. While other blockchain methods such as ZCash and Monero integrate privacy-preserving methods, Bitcoin and other methods do not actually protect the sender and receiver of a transaction. The value of the transaction is also plain for everyone to see.

Often, though, we have a Catch-22 situation, and where to check that Bob has enough funds in his account to pay Alice, we must see all of Bob’s transactions. With this we total up his inputs (the money he has received) and then look at his outputs (including all his payments, and for the transaction to Alice), and make sure that he still has a balance with is greater than or equal to zero. This involves searching the whole of the blockchain to make a tally of his funds. Within Mimblewimble, those who are involved in transactions can reveal the details contained in them, but still allow others to check that no new currency is being created and that the transactions are valid.

ECC

At the core of Mimblewimble is the magic of Elliptic Curve Cryptography (ECC). In this we have a private key (n) and a point on an elliptic curve (G). The public key is then:

P = nG

The multiplication of n times G is simple, but it is almost impossible to find n given P and G. We can also perform an addition of two private keys (n and m) and end up with a point on the elliptic curve:

P = nG + mG = (n+m)G

In this case, the private key is (n+m), and the public key is (n+m)G. A demo of this is here:

Confidentially

A transaction in Mimblewimble involves the verification of zero sums, and where the sum of outputs less the sums of the inputs will always equal zero. This is transacted without actually revealing the amounts used for the inputs and outputs. Unlike other cryptocurrency methods, the signer does not actually sign a transaction with their private key, even though they own the transaction.

Balances

Building upon the properties of ECC we described above, one can obscure the values in a transaction.

Let’s say that we have a transaction value of v, we can now define this as a point on the elliptic curve (H) as:

v*H

If we have three transactions (v1, v2 and v3), we can create a sum total of:

Total = v1*H + v2*H+ v3*H= (v1+v2+v3)*H

We can thus determine the sum of the transactions. But we could eventually find-out the values of v1, v2 and v3, as they would always appear as the same value when multiplied by H. We can now add a blinding factor by adding a second point on another elliptic curve (G) and a private key (r).

A transaction value is then (as defined as a Pedersen Commitment):

v*H + r*G

Let’s say that Bob has two input values (v1 and v2) and one output value (v3), and where v3= v1+v2. We can then create a blinding factor for each transaction:

(ri1*G + vi1*H) + (ri2*G + vi2*H) = (ro3*G + vo3*H)

Then:

ri1 + ri2 = ro3

In this case if we can prove this, we have proven that the inputs are equal to the outputs. A demo of this is here:

Ownership

In ECC, the ownership of a transaction is defined by the ownership of a private key. If Bob has created a transaction for Alice for v=4, and has a blinding value of r=10, the output will be:

X = 4*G + 10*H

Only Bob will know the value of 10, and Alice and Bob will know the value of 4. To send these coins to Carol we have a transaction of:

Xi => Y

In this case Xi are the inputs that equal to Carol’s output (Y). This can only be created if Bob’s private key is known. Thus only Bob will be able to create this assertion:

X = 4*G + 10*H - 4*G + 10*H => 0

In this way Bob shows that there is no new currency being created. The problem is that we will have to use Carol’s private key to prove this calculation. For this she picks her own private key (such as 11) and adds the following onto the blockchain:

Y - Xi = (11*G + 10*H) - (4*G + 10*H) = 8*G 

This does not end up with zero, but we now have a valid public key (8*G) on the elliptic curve.

Thus we verify that Y-Xi is a valid public key on the curve, and that all of the transacting parties know the private key for this transaction. The signature is then created from this private key — this is known as the transaction kernel.

The downside?

Well, the simplicity of just sending transactions to a Bitcoin address is one of its core strengths, but it has to change in order to address privacy concerns. With Mimblewimble we now need wallets to interact for payments in order to create a transaction. There is also the opportunity for Eve to play a spy node in the network, and which listens to each of the individual transactions. This would allow Eve to know the senders and the receivers.

Conclusions

There you go. Wasn’t that fun? Some Harry Potter, invisibility cloaks, and a whole lot of ECC.

Oh, how I love cryptography! Every day brings a new world of learning, and a strive towards a more trusted world.

Sometime, soon, we need to start integrating privacy and ownership into everything that we do in a digital world. Mimblewimble showcases this and builds a new digital world. Our future digital world will be built on trustworthy transactions which respect privacy, and not relational data structures which have little thought on ownership, privacy, and consent.

Our current data world is all wrong, so let’s rebuild it properly!