Multiverse 2.357

Mimblewimble is the funny sounding and unconventional blockchain protocol that emphasizes scalability, privacy and fungeability. It is full of Harry Potter lore, cryptography and bright new ideas for cryptocurrency.

Due to the way mimblewimble is constructed, it’s best suited for comparisons to Bitcoin. If you need a quick refresher, consider giving my Intro to Bitcoin podcast a listen. Also, if you’re interested in learning more about the mimblewimble protocol you might want to listen to my Intro to Mimblewimble podcast on HPR as well.

Mimblewimble is a network protocol for cryptocurrency that has a great origin story too. An anonymous character, Tom Elvis Jedusor, showed up in the bitcoin wizards irc channel and left a link to a simple text file describing this protocol in summer 2016. Apparently this name is the French name of the Voldemort character from Harry Potter stories. This is about the extent of my Harry Potter knowledge.

Andrew Poelstra, a mathematician at Blockstream, published a revised version a couple months later that formalized the protocol and shortly thereafter another mysterious person, Ignatious Perevell joined the irc and announced that he started an open source implementation of this. This is the genesis of the Grin blockchain, one of two major implementations of the mimblewimble protocol. I have no idea who this Perevell character is in the Harry Potter stories, but I’m pretty sure he’s involved somehow.

Mimblewimble is a network protocol that focuses on scalability via the realization that transaction history does not need to be stored. Blockchains like Bitcoin that store the transaction history in entirety can only grow over time, making running nodes increasingly infeasible over time for many individuals. This protocol allows for combining transactions at multiple stages, and not recording all the inputs and outputs into blocks.

Privacy is good in this protocol, supported by some of the same features that give it scalability. There are no addresses on blockchains using this protocol, and no amounts are recorded with any transactions. Add to that a variety of tactics designed to hide the origin of transactions and you have a recipe for strong privacy.

Dandelion Protocol

One of the key parts of Mimblewimble is called the Dandelion protocol. This is a method of oscuring the source of a transaction. In Bitcoin, the sender constructs a transaction and signs it, then it is broadcast to peers on the network in order that it get included in the earliest block possible. Here the idea is to conceal the fact that a particular node is broadcasting the transaction.

What actually happens is that the transaction is passed along to only one random peer. That peer will sometimes broadcast it, but more often will pass it along yet again to a random peer. At some point, a node will broadcast the transaction to all its peers, but chances are that this is not the originating node.

So an adversarial node on the network would be more likely to see a transaction after it is broadcast, rather than in the “stem phase” where it’s being passed along to a single node at a time. At each step along the way, a node will combine this transaction with any other transactions it sees at that time. This aggregation results in transactions having inputs and outputs from multiple transactions combined into a single one.

Cut Thru

This might be the most intuitive feature related to scalability. Cut-thru is the process that allows the elimination of redundent inputs and outputs. Kernels still remain, to ensure no funny business happened, but the Pederson commitments that represent the inputs and outputs of many transactions do not need to be stored.

Conceptually it works like this: imagine Alice sends a coin to Bob, who later sends that coin to Charlie. Both of these transactions are pending inclusion into the current block, so the current UTXO set has that coin still controlled by Alice. When the state of the blockchain is updated by adding a new block, the new UTXO set will reflect the fact that the coin is now associated to a new UTXO, and the coin is controlled by a private key in Charlie’s wallet.

Notice the information about Bob is not needed explicitly. Alice had the coin in the previous blockchain state, now Charlie controls it. The first transaction, where Alice sent the coin to Bob, no longer needs the output because Bob sent that coin to Charlie. That input to the transaction where Bob sends the coin to Charlie is not needed either. That UTXO was controlled by Alice previously, now the UTXO can be spent by Charlie. This is sufficient because all parties signed the transactions that happened, and the proofs remain in the form of kernels even after the transactions have been pruned.

There is so much more to say about this protocol, and the major blockchains that implement it, that I’ll have to continue this in other posts. Still needing explanation is how amounts are not visible to anyone except the participants directly participating in a transaction, for example. We mentioned kernels but offered no description. Transactions definitely need elaboration because they are very different, and there are other things to discuss. Beam and Grin, the two very different blockchains using this protocol need to be described too, so stay tuned!