How Mimblewimble Could Make Bitcoin Work Better


Mimblewimble claims to use a new cryptographic protocol that could revolutionize the way bitcoin works, making it more scalable and private.

The protocol generates a blinding factor that can prove ownership of bitcoins, making private keys unnecessary, and offering a solution to the need to balance bitcoin privacy against fungibility while also improving scalability, according to a white paper that appeared mysteriously on a bitcoin research site authored by a person using a pseudonym.

The author refers to himself as “Tom Elvis Jedusor,” a name taken from the Harry Potter novels.

Bitcoin’s Verification Challenge


Bitcoin is the first widely used financial system for which all the necessary data to validate the system status can be cryptographically verified by anyone, the white paper notes.

It accomplishes this by storing all transactions in a public database called “the blockchain.” Someone who wants to check this state has to download the whole chain and replay each transaction, checking each one as they go.

It would be easier if an auditor only had to check data on the outputs themselves, but this is not possible since they are only valid if the output is at the end of a chain of prior outputs. The whole blockchain has to be validated to confirm the final state.

Considering that the transactions are cryptographically atomic, the outputs that go into and emerge from every transaction are very clear. The “transaction graph” that results reveals a lot of information and is subjected to analysis by numerous companies whose business model is to monitor and control the lower classes.

This makes it very non-private and even dangerous to use.

Proposed Solutions

Some solutions to this have been proposed, Jedusor notes. Greg Maxwell discovered how to encrypt the amounts so that the graph of the transaction is faceless but still validates the sums. Maxwell also produced CoinJoin, a system for bitcoin users to combine interactively transactions, confusing the transaction graph.

Nicolas van Saberhagen developed a system to blind the transaction entries, further clouding the transaction graph. Shen Noether combined the two approaches to obtain the “confidential transactions” of Maxwell and the “darkening” of van Saberhagen.

These solutions would make bitcoin safe, Jedusor observes. But too much data can make things worse. Confidential transactions require multi-kilobyte proofs on every output. van Saberhagen signatures require every output to be stored forever, as it is not possible to truly tell when they are spent.

Maxwell’s CoinJoin needs interactivity. Yuan Horas Mouton fixed this by making transactions freely mergeable, but he had to use pairing-based cryptography which can be slower and harder to trust. He called this “one-way aggregate signatures” (OWAS).

OWAS combined the transactions in blocks. It could be possible to combine across blocks (perhaps with some glue data) so that when the outputs are created and destroyed, it is as if they never existed, Jedusor notes.

Then, to validate the entire chain, users only need to know when money enters the system (new money in each block as in bitcoin or Monero or peg-ins for sidechains) and final unspent outputs. The rest can be removed and forgotten.

Confidential transactions hide the amounts and OWAS to blur the transaction graph by using less space than bitcoin to enable users to verify the blockchain.

Mimblewimble prevents the blockchain from referencing all of a user’s information, Jedusor observes.

Confidential Transactions

The first step is to remove bitcoin Script. It is too powerful, so it is impossible to merge transactions using general scripts.

Instant transaction

Maxwell’s Confidential Transactions are enough (after some small modification) to authorize the spending of outputs and also to make combined transactions without interaction. This is identical to OWAS, enabling the relaying nodes to take some transaction fee or the recipient to change the transaction fee. Bitcoin cannot do these additional things.

In Confidential Transactions work, the amounts are coded by the following equation: C = r*G + v*H.

C is a Pedersen commitment, G and H are fixed nothing-up-my-sleeve elliptic curve group generators, v is the amount, and r is a secret random blinding key.

Attached to this output is a rangeproof proving that v is in [0, 2^64], so the user cannot exploit the blinding to produce overflow attacks, etc.

To validate a transaction, the verifier will add commitments for all outputs, plus f*H (f being the transaction fee that is given explicitly) and subtracts all input commitments. The result must be 0, proving no amount was created or destroyed overall.

To create such a transaction, the user has to know the sum of the values of r for commitments entries. Therefore, r-values (and their sums) serve as secret keys. If the r output values are made known only to the recipient, an authentication system exists. Unfortunately, by keeping the rule that commits all to add up to zer0, this is impossible since the sender knows the sum of all his r values, and therefore knows the recipient’s r values sum to the negative of that.

Instead, the transaction is allowed to sum to a non-zero value,  k*G, and require a signature of an empty string with this as key, proving its amount component is zero.

The transactions can have as many k*G values as they want, each with a signature, and sum them up during verification.

Creating Transactions

To create transactions, the sender and recipient do the following:

1) The sender and recipient agree on the amount to send. Call this b.

2) The sender creates a transaction with all inputs and change output(s), and gives the recipient the total blinding factor (r-value of change minus r-values of inputs) along with the transaction. The commitments sum to r*G – b*H.

3) The recipient chooses random r-values for his outputs, and values that sum to b minus fee, then adds these to the transaction (including range proof). Now the commitments sum to k*G – fee*H for some k that only the recipient knows.

4) The recipient attaches the signature with k to the transaction, and the explicit fee.

Creating transactions like this supports OWAS already. To demonstrate this, consider two transactions that have a surplus k1*G and k2*G, and the attached signatures with these. Then combine the lists of inputs and outputs of the two transactions, with both k1*G and k2*G to the mix, and it is again a valid transaction. From the combination, it is not possible to know which outputs or inputs are from which original transaction.

Because of this, the block format changes from bitcoin to this information:

1) Explicit amounts for new money (block subsidy or sidechain peg-ins) with whatever else data this needs. For a sidechain peg-in, it may reference a bitcoin transaction that commits to a specific excess k*G value.

2) Inputs of all transactions.

3) Outputs of all transactions.

4) Excess k*G values for all transactions.

Each is grouped together because it does not matter what the transaction boundaries are originally. In addition, lists 2, 3 and 4 should be coded in alphabetical order, since it is quick to check and prevents the block creator from leaking any information about the original transactions.

The outputs are now identified by their hash, rather than their position in a transaction that could easily change. Therefore, it should be banned to have two unspent outputs equal at the same time to avoid confusion.

Merging Transactions

Maxwell’s Confidential Transactions has already been used to create a non-interactive version of his CoinJoin. Another idea is needed. A non-interactive version of this is created to show how it is used with several blocks.

Each block can be seen as one large transaction. To validate it, add the output commitments together, then subtract the input commitments, k*G values, and the explicit input amounts times H. The transactions from two blocks can be combined to form a single block, resulting again in a valid transaction.

The difference is that output commitments have an input commitment equal to it, where the first block’s output is spent in the second block. Both commitments can be removed and still have a valid transaction. There is not even the need to check the rangeproof of the deleted output.

The extension of this idea, all the way from the genesis block to the latest block, shows that each non-explicit input is deleted with its referenced output. All that remains are the unspent outputs, explicit input amounts and every k*G value.

The entire mess can be validated as if it were one transaction by adding all unspent commitments output, subtracting the values k*G, validating explicit input amounts (if there is anything to validate) and subtracting them times H. If the sum is zero, the complete chain is good.

When a user downloads the chain, the following data is needed from each block:

1) Explicit amounts for new money (block subsidy or sidechain peg-ins) with whatever else data this needs.

2) Unspent outputs of all transactions, along with a merkle proof that each output appeared in the original block.

3) Excess k*G values for all transactions.

Bitcoin currently has about 423000 blocks, totaling around 80GB of data on the hard drive to validate everything. The data represents around 150 million transactions and 5 million
unspent, non-confidential outputs.

Each unspent output on a Mimblewimble chain is around 3Kb for rangeproof and Merkle proof. Each transaction adds around 100 bytes: a k*G value and a signature.

The block headers and explicit amounts are negligible. Added together this is 30Gb – with an obscured transaction graph and a confidential transaction.

Also read: Mimblewimble: A stripped down version of bitcoin improves privacy, fungibility and scalability 

Questions and Intuition

The following questions arise.

Q: If you delete the transaction outputs, the user cannot verify the rangeproof and may be a negative amount is created.

A: This is acceptable. For the entire transaction to validate, all negative amounts must have been destroyed. Users have SPV security only that no illegal inflation happened in the past, but the user knows that at this time, no inflation occurred.

Q: If you delete the inputs, double spending can happen.

A: In fact, this means someone may claim that unspent output was spent in the old days. But this is impossible, otherwise the sum of the combined transaction could not be zero.

An exception is that if the outputs amount to zero, it is possible to make two that are negatives of each other, and the pair can be revived without anything that breaks. So to prevent consensus problems, outputs 0-amount should be banned. Just add H at each output.

They all amount to at least 1 at present.

Future Research

Here are some questions that cannot be answered at the time of this writing.

1) What script support is possible? One would need to translate script operations into some discrete logarithm information.

2) Users are required to check all k*G values when in fact all that is needed is that the sum is of the form k*G. Instead of using signatures, is there another proof of discrete logarithm that could be combined?

3) There is a denial-of-service option when a user downloads the chain. The peer can give gigabytes of data and list the wrong unspent outputs. The user will see that the results do not add up to 0, but cannot tell where the problem is.

For now, maybe the user should just download the blockchain from a Torrent or something where the data is shared between many users and is reasonably likely to be correct.

Images from Shutterstock.

Lester Coleman is a veteran business journalist based in the United States. He has covered the payments industry for several years and is available for writing assignments.