1,177 reads

Protocol Spotlight: MimbleWimble and Grin

by FlatOutCryptoAugust 6th, 2018

Too Long; Didn't Read

If you enjoy this article then please follow me <a href="https://twitter.com/flatoutcrypto" target="_blank">@FlatOutCrypto</a>. You can find all my articles on <a href="http://flatoutcrypto.com" target="_blank">flatoutcrypto.com</a>.

Companies Mentioned

Coins Mentioned

featured image - Protocol Spotlight: MimbleWimble and Grin

If you enjoy this article then please follow me @FlatOutCrypto. You can find all my articles on flatoutcrypto.com.

Continuing my series breaking down some of the newer or lesser known protocols, attention now turns to the gloriously named MimbleWimble.

It’s easy to get jaded in crypto but I knew I’d enjoy researching MimbleWimble when I stumbled across this list of some of the core tenets of the project:

no ico
no premine
no instamine
no mining tax
no masternodes
no governance
no room for spam

I then saw comments at a meetup from one of the developers stating:

“If you’re a developer, just contribute directly. If you’re a VC, we can’t offer any ICO or pre-mining or anything like that.”

“The community pays my salary…There’s no ICOs, no backers, no VCs involved”

Usual disclaimers apply:

I will explain the key concepts of MimbleWimble but not go through every single piece of how it works at a granular level — the whitepaper serves that purpose. As such, some of the intricacies, exceptions and smaller aspects that take many words but have a minimal impact will be omitted
I will avoid validating — or refuting — the team’s claims. I am just explaining what the team are trying to do for those who might not have the inclination or technical background to read up on it further
This will be a less in-depth look than the likes of Avalanche, Maidsafe or Rootstock — I will do a more in-depth update on the workings of the protocol nearer to its release

Unlike some of the other projects I’ve looked at where I’ve been amongst the first to go into detail, MimbleWimble benefits from existing good and concise explanations.

I’ve referenced at the bottom of this post a list of the resources I used but it should be noted that I interchangeably reference the original whitepaper from the anonymous Tom Elvis Jedusor (we’ve gone from the Pokemon references of Avalanche to Harry Potter here), Andrew Poelstra’s successor paper and the also anonymous Ignotus Peverell’s documentation on Github. I also refer to work from Grin’s (one of the first implementations of MimbleWimble) developers and resources, although I try and differentiate between the two where possible. With that out the way…

What is MimbleWimble?

MimbleWimble can be thought of as a stripped back — but still powerful — blockchain protocol which aims to improve upon existing implementation’s scalability and privacy. What makes it interesting is that it tackles scalability in a different way to a lot of other protocols. Rather than focus on centralisation (masternodes, coordinators), Layer 1 (sharding) or Layer 2 solutions (state channels), it focuses on creating a new and stripped back protocol. This makes running a node less resource intensive.

It also claims improvement on the privacy properties of Bitcoin. Normally I would groan at yet another project noting how it beats the decade old Bitcoin but in MimbleWimble’s case it makes more sense. It boasts similar characteristics and aspirations to those of Bitcoin in its early years and is avowedly a project to “design a Bitcoin-like cryptocurrency”, just one with improved privacy and scalability.

The anonymous founder, the lack of VC backing or an ICO, the community development are all reminiscent of the original cryptocurrency, but so too are more implementation specific decisions such as a return to the out of favour PoW but one which aims to be more centralisation resistant, a conscious decision for no on-chain governance (a beautiful set of words) and a long term emission rate.

What problems is it trying to solve?

So MimbleWimble is tackling privacy and scaling. But what specifically are they trying to do?

Scaling

Unlike other projects, which aim for huge throughput (amazing how many projects are promising 1 million transactions per second), MimbleWimble attacks a less addressed aspect of scaling. It elects to eradicate inefficiencies, rather than increase the power, by pruning the blockchain of superfluous data.

To run a Bitcoin node you have to download the entire ledger, some 175GB at present. The Ethereum ledger, meanwhile, is now over 1TB. Every new transaction takes up a little bit more space. MimbleWimble, however, gets rid of old and unneeded transactions. What do they mean by this?

Imagine I make a transaction to Bob. Bob then makes a transaction to Alice, who in turn transacts to Carol who in turn transacts to David. The end result is that my original output is now in the hands of David. So why keep the additional data? MimbleWimble removes these spent outputs by combining intermediary transactions together. The authorisation of these transactions remains (we need this because otherwise transactions could be reversed), but the evidence of these now redundant transactions are lost.

What is really clever is that this allows the network to continue functioning “even if no users retain the vast majority of historic blockchain data”. As such MimbleWimble is not as burdened by data comprising historic transactions (although there is a small 100 byte ‘kernel’ that must be stored for every transaction, meaning early aspirations to reduce the blockchain to mere megabytes are presumably currently no longer on the cards).

What makes this work is that we know exactly how many coins there is and ever will be, similar to how Bitcoin has a fixed supply of 21m. There can never be more than the maximum supply. There is no inflation. No-one can arbitrarily print more Bitcoin. Therefore for each unspent output there will be a path of transactions that led to it.

Everything must sum to 0, and this is essentially what MimbleWimble does — it verifies for each transaction that the sum of outputs minus inputs equals zero e.g. I send 1 BTC, 1 BTC is received. I have not created any new funds. This all that a transaction is checking for. Ownership is proved by a user’s blinding factor (more on that in the next section).

This scaling solution is important because it is sustainable; we will always be able to sum to zero and therefore remove unnecessary transactions, keeping the blockchain a manageable size.

Privacy

What I like about MimbleWimble is that it tackles problems in a different way to other projects and this extends to privacy. Most privacy solutions use something like zero knowledge proofs or ring signatures to obfuscate transactions. MimbleWimble and Grin do it slightly differently.

1. No addresses

This is quite hard to grasp given how other cryptoassets work, all (unless I’m being forgetful) rely on addresses to send/receive. I copy my Bitcoin address, give it to the sender, they send to my address. Grin is built differently. The best way to think of it is that two wallets would communicate with each other to exchange data. The recipient then creates a destination for the sender to send the funds, but this information is only ever seen by the two parties. This doesn’t require both parties to be online at the same time and the interaction could be done via practically any medium, as impractical as it may be (email, over the phone etc).

No-one else would be able to reuse this information. It always requires inputs from both sides.

2. No transaction details

They also can’t see any details about the transaction. Unless you were one of the participants, none of the transactions in any given block will be recognisable to you. Unlike the likes of Monero, if you view a block you won’t see a list of transactions in that block. You’ll just see one big transaction which has mixed and merged everything — all that is left are the “list of new inputs, a list of new outputs and a list of cryptographic signatures created with the aforementioned dummy outputs.”

This means that it is impossible to recognise what has actually happened in any given block i.e. you cannot tell when there has been a transaction, when a user has sent to another use. It is hidden from you in plain sight.

3. Confidential Transactions and blinding factors

While the above points may mean that it is impossible for anyone to trace down historic transactions, it leaves transactions open at their source for anyone monitoring the network. What we have to do is make sure that no-one can see output amounts.

To do this MimbleWimble uses a ‘blinding factor’ which is essentially the user’s private key. This is a very large number which is used to both obfuscate transaction values and to prove ownership. I’m not going to go into details (read this if you would like more) but essentially this blinding factor is what allows the network to validate a transaction without knowing any of the values.

This process is derived from Confidential Transactions, an already existing invention. They have been developed and proposed for Bitcoin as well as other cryptoassets and essentially make it so that while the sender and the recipient can see the amount transacted, everyone else simply sees that an unknown amount has been transacted.

Traditional weaknesses of such implementations include:

Addresses are still visible
If a future transaction is not hidden then it can be possible to retrospectively work out how much the original transaction was for
They increase the size of a transaction (although the size is coming down with development work), making them hard to implement for most blockchains

However, by not having any addresses or transaction details, Confidential Transactions mean that someone viewing the MimbleWimble blockchain would be unable to see any details of the sender or recipient, any amount transacted at any point or even recognise when there even was a transaction.

4. Fungibility

This isn’t something MimbleWimble is doing to solve the problem, but rather is a problem solved by MimbleWimble.

One of the issues with Bitcoin is that ‘dirty’ BTC can be tracked. Say someone hacks an exchange and steals BTC but you then buy said BTC without realising from them. These BTC will be marked as dirty in much the same way that banknotes stolen from a vault would be. You have bought this BTC in good faith, but you may face restrictions for using it. As a result, although we call BTC or ETH fungible tokens (i.e. all the same), that isn’t strictly true.

Grin, however, would lead to truly fungible tokens. This is as a result of how it verifies transactions (i.e. summing to 0) before discarding all inputs/outputs and masking all transactions.

What else should I know?

There is a very good read on the monetary policy of Grin here by Myles Snider which I would encourage people to read. Snider argues that Grin’s monetary policy will likely mean that early holders are encouraged to spend. After eight years, there will be 25% less Grin than BTC at the same stage of their life cycles, proportional to maximum supply. Grin list itself as being better tailored as ‘a medium of exchange’ rather than store of value, so this fits
Although the nature of Grin makes cold storage/hardware wallets (like the Ledger Nano S) harder to implement, it is not impossible
Grin doesn’t have a scripting language built in, so smart contracts are again harder. However, Grin can use something called ‘Scriptless Scripts’ which may enable similar functionality
The nature of the project also makes atomic swaps harder, but again, not impossible
There is another MimbleWimble implementation called Beam. Interestingly, BEAM state in their position paper that “performance will not be high enough for BEAM to be used as “means of exchange”. Which is why we believe that BEAM will be primarily used as “store of value”.” Obviously this is at odds with Grin
Igno Peverell outlined upcoming developments for Grin here. If nothing else, it shows just how much the project has going on

Financials

N/A but as already covered, no ICO or premine.

Conclusion

This look at MimbleWimble should have made clear that there is still a lot of work to be done (and the above will be updated in the future to reflect developments) but also that it promotes an interesting approach to solve common issues, attacking them in a different manner.

It’s a project I’m looking forward to following in the coming months and years, especially given the imbalance of resources the team has against better financed competition.

If you enjoy this article then please follow me @FlatOutCrypto. You can find all my articles on flatoutcrypto.com.