Introduction

Overview of the Cryptocurrency Revolution:

Breakthroughs and Challenge

The birth of Bitcoin, the world’s first Blockchain-based cryptocurrency, a decade ago has led to thousands of spin-offs in the form of altcoins, tokens, crypto exchanges, and other special use cases for the Blockchain technology outside fintech.
Today, there are over 2000 cryptocurrencies in the world with a combined market capitalization of over 173 Billion USD as at April 2019, having already experienced an all-time high of 800 Billion USD in January 2018.

Market Cap

Leveraging Blockchain’s principle of decentralized processes, these new digital have been selling on the need for better speed, borderless transactions, security, and privacy, all of which are major issues with traditional banking today. But as is evident in the figure above, the cryptocurrency space has had its own share of highs and lows since Blockchain and Bitcoin first became famous.

The nascent nature of the technology and other challenges such as resistance from national governments, security breaches and hacks, scalability of the major cryptos and privacy concerns, have all contributed heavily to the volatile nature of the crypto marketplace. All of these challenges have continued to undermine the great potential of Blockchain-powered currency solutions in today’s financial marketplace.

CoinJoin Diagram

At the point of ‘confidential transactions’, the above solutions had significantly made Bitcoin and other altcoins safe to use, however, the problem of too much data persists and is made even worse because Confidential Transactions require multi-kilobyte proofs on every output, and van Saberhagen signatures require every output to be stored forever, since it is not possible to tell when they are truly spent. The implication: there was still a need for a better approach.

The Mimblewimble Intervention

What Is Mimblewimble?

Launched in 2016 by a pseudonymous developer in a Bitcoin developers’ channel, the Mimblewimble protocol seeks to significantly improve privacy and scalability of Bitcoin and other cryptocurrency networks by creating an efficient, confidential Blockchain which ensures that transaction does not create surplus money and proof of ownership is established through private keys.

Essentially, the protocol addresses gaps existing in almost all current Blockchain implementations by building upon the twin concepts called ‘Confidential Transactions’ and ‘Transaction Cut – Through.’

Visualisation of Bitcoin’s UTXO model

Visualisation of Bitcoin's UTXO model

Basic Elements of a Mimblewimble Protocol Transaction

Essentially, a Mimblewimble transaction involves the following:
  • A set of inputs that reference and spend a set of previous outputs.
  • A set of new outputs that include:
  • A value and a blinding factor (which is just a new private key) multiplied on a curve and summed to be r*G + v*H.
  • A range proof that shows that v is non-negative.
  • An explicit transaction fee, in clear.
  • 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.

How It Works

» Confidential Transactions

Confidential transactions are implemented by using a cryptographic commitment scheme which has two basic properties: hiding and binding. It is similar to giving someone a closed safe box with some message inside that only you know the combination for. When the time comes, you can reveal the key, and the person can make sure that your commitment is valid (binding) while he cannot know what it was before the key is received (hiding).

Mimblewimble utilizes a well-known commitment scheme called Pedersen Commitment that achieves this using Elliptic Curve Cryptography and is of the form C = r * G + v * H, where:

  •  r is a blinding factor, a secret key hiding the real value
  • V and G and H are generator points on a specific elliptic curve.

Each input and output of a transaction is thus a linear combination of two factors: an actual value of the transaction and a blinding factor. In order to transfer ownership of a UTXO (Unspent Transaction Output), a sender needs to reveal its value and blinding factor to the receiver, which in turn needs to create a new output commitment using a different blinding factor, known only to him.
Due to the linearity property of Pedersen Commitments, if we have two identical transactions: from A to B, and then from B to C, we can cut through the intermediate transaction, resulting in a merged transaction from A to C, which is a valid transaction in the system.

Since the block is just a list of transactions, each with its list of inputs and outputs, a block can be seen as one large transaction as well, allowing us to “cut through” i.e. merge all intermediate outputs both within a single block as well as across multiple blocks in the Blockchain.
Extending this approach to the entire chain, we get a system that only needs to store the current UTXO state, instead of entire transaction history.
Validity of the history that brought us to this state can be confirmed by storing only the headers of the previous blocks which hold the proof of validity of previous states (using a structure called a Merkle tree) and Proof of Work that allows to reach consensus on which of the header chains should be considered the correct one (in case of Blockchain branching). Since all that is needed to prove ownership of the UTXO is the value and the unique blinding factor, there is no need to store any addresses in the Blockchain.

After creating the transaction between two wallets, either online or using any other secure mechanism, only the commitment is recorded in the Blockchain. This means that no matter the resources of the attacker, no personal information can be extracted from the Blockchain. In addition to Inputs, Outputs, Proofs, and fees, each Mimblewimble transaction includes the transaction kernel, which in its most basic form contains the difference between blinding factors of sender and receiver. Each transaction should also contain a non-interactive zero.

Knowledge range proof to ensure that transaction value is positive without revealing the actual value. This is important because allowing the user to create transactions with negative value would result in the ability to arbitrarily create new coins which should be prohibited by the system.

For this purpose, we use Bulletproofs, a compact and highly computation-efficient implementation of zero knowledge range proofs that are attached to every transaction and checked by the system during transaction validation.

» Transacting with Mimblewimble

Validation of transactions within a Mimblewimble Blockchain relies on two basic properties:

  • 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.
  • Possession of Private Keys: Like with most other cryptocurrencies, ownership of transaction outputs is guaranteed by the possession of ECC private keys. However, the proof that an entity owns those private keys is not achieved by directly signing the transaction.

» Transaction Cut – Through

Mimblewimble further improves the Blockchain via ‘transaction cut-through’ which provides:

  • Extremely good scalability, because the majority of transaction data can be eliminated over time, without compromising security.
  • Further anonymity by mixing and removing transaction data.
  • And the ability for new nodes to sync up with the rest of the network very efficiently. When a new node joins a network building up a Mimblewimble chain, the amount of information that needs to be transferred is also very small.

The important feature of Mimblewimble regarding scalability is “Cut Through.” A single block consists of hundreds of transactions as well as plenty of information that needs to be stored on the Blockchain. However, these blocks can be compressed with Mimblewimble’s Cut Through feature as a large part of the info can be removed from the blocks without risking the security of the Blockchain.

Example: 

Jane sends 1 BTC to Rob

Rob sends 1 BTC to Charles.

In this case, a typical block has two UTXOs. The first UTXO will hold the input for that 1 BTC which reflects how it got to Jane.

The output for the first UTXO is the result of the transaction, which verifies that the Bitcoin is now owned by Rob. The second UTXO consists of the output of the first UTXO – which is now the input of the second UTXO – and the output of the second transaction to Charles.

This means that Mimblewimble eliminates the output of the first transaction and the input of the second transaction. So, we’ll only have one input and one output – that verifies how Jane got this 1 Bitcoin and how Charles received their 1 BTC -, instead of having two of each. This compresses the size of the Blockchain, making Mimblewimble much lighter regarding the data storage.In this case, a typical block has two UTXOs. The first UTXO will hold the input for that 1 BTC which reflects how it got to Jane.

The output for the first UTXO is the result of the transaction, which verifies that the Bitcoin is now owned by Rob. The second UTXO consists of the output of the first UTXO – which is now the input of the second UTXO – and the output of the second transaction to Charles.

This means that Mimblewimble eliminates the output of the first transaction and the input of the second transaction. So, we’ll only have one input and one output – that verifies how Jane got this 1 Bitcoin and how Charles received their 1 BTC -, instead of having two of each. This compresses the size of the Blockchain, making Mimblewimble much lighter regarding the data storage.

Core Values of Mimblewimble

» Balance

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

If v is the value of a transaction input or output and H a point on the elliptic curve C, we can simply 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 sum of inputs:

v1 + v2 = v3 => v1*H + v2*H = v3*H

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 values are. However, there are a finite number of usable values (transaction amounts), and one could try every single one of them to guess the value of your transaction. In addition, knowing v1 (from 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 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.

An input or output value in a transaction can then be expressed as:

r*G + v*H

Where: r is a private key used as a blinding factor, G is a point on the elliptic curve C, and their product r*G is the public key for r (using G as generator point). V is the value of an input or output, and H is another point on the elliptic curve C, together producing another public key v*H (using H as generator point).

Neither v nor r can be deduced, leveraging the fundamental properties of Elliptic Curve Cryptography. r*G + v*H is called a Pedersen Commitment.

For example, if we are to build a transaction with two inputs and one output, the following obtains (that’s minus processing fees):

» vi1 and vi2 as input values.
» vo3 as output value. vi1 + vi2 = vo3

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:

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

Which as a consequence requires that:

ri1 + ri2 = ro3

» Ownership

With Mimblewimble a private key can be leveraged to prove ownership of the value, as is shown in the example below:

Jane sends you 3 coins and to obscure that amount; you chose 28 as your blinding factor (note that in practice, the blinding factor being a private key, it’s an extremely large number). Somewhere on the Blockchain, the following output appears and should only be spendable by you:

X = 28*G + 3*H

»  X, the result of the addition, is visible by everyone. The value 3 is only known to you and Jane, and 28 is only known to you.

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 Tessy. You need to build a simple transaction such that:

Xi => Y

Where Xi is an input that spends your X output, and Y is Tessy’s output. There is no way to build such a transaction and balance it without knowing your private key of 28. Indeed, if Tessy is to balance this transaction, she needs to know both the value sent and your private key so that:

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.

Wait! Stop! Now you know the private key in Tessy’s output (which, in this case, must be the same as yours to balance out) and so you could steal the money back from Tessy! To solve this, Tessy uses a private key of her choosing. She picks 113 say, and what ends up on the Blockchain is:

Y - Xi = (113*G + 3*H) - (28*G + 3*H) = 85*G + 0*H

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 the elliptic curve using generator point G.
In effect, all the protocol needs to verify is that (Y – Xi) is a valid public key on the curve and that the transacting parties collectively know the private key x (85 in our transaction with Tessy) of this public key. If they can prove that they know the private key to x*G + y*H using generator point G, then this proves that y must be 0 (meaning above that the sum of all inputs and outputs equals 0).

The simplest way to do so is to require a signature built with the excess value (85), which then validates that: the transacting parties collectively know the private key (the excess value 85), 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).

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.

» Range Proofs

In all the above calculations, we rely on the transaction values to always be positive. The introduction of negative amounts would be extremely problematic as one could 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 curve looks like any other.

To solve this problem, Mimblewimble leverages another cryptographic concept (also coming from Confidential Transactions) called 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 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.

The requirement to know both values to generate valid range proofs is an important feature since it prevents a censoring attack where a third party could lock up UTXOs without knowing their private key by creating a transaction from:

» Tessy's UTXO: 113*G + 2*H
» Attacker'soutput: (113 + 99)*G + 2*H

Which can be signed by the attacker since Tessy’s private key of 113 cancels due to the adversarial choice of keys? The new output could only be spent by both the attacker and Tessy together. However, while the attacker can provide a valid signature for the transaction, it is impossible to create a valid range of proof for the new output invalidating this attack.

The Market Opportunity for Mimblewimble Today

Against the background of existing challenges that have continued to affect a wider acceptance of cryptocurrencies as a viable driver of the digital future, the Mimblewimble protocol comes into play at the right time.

While it is still a relatively new concept in terms of actual use cases, its theoretical foundations have been laid for quite some time now.

Beyond the need to cash in on the mouthwatering returns on investments that cryptocurrency business offers, Mimblewimble represents a bold innovation to solve all existing privacy and scalability problems!

Lower-bound Estimate of Total Cryptoasset Users

Lower-bound Estimate of Total Cryptoasset Users

The task of making cryptocurrencies achieve better acceptance and stability is certainly one that Bitcoin alone and other Blockchain efforts such as privacy-centric offerings, Monero, DASH, and the likes, cannot deliver.

The entrance of Mimblewimble-based Blockchain projects such as Grin and BEAM have offered hope in this regard, but the Hermione Project seeks to take the Mimblewimble solution even further.

The Hermione Mimblewimble Project

The Hermione Project