Based on blockchain technology, most cryptocurrencies have an open and public ledger of transactions. While this is required for these systems to work, it comes with a significant downside: Privacy is often quite limited. Analytics companies and other interested parties — let’s call them “spies” — have ways to analyze the public blockchains and peer-to-peer networks of cryptocurrencies like Bitcoin, to cluster addresses and tie them to IP addresses or other identifying information.
Still, unsatisfied with Bitcoin’s privacy potential, several cryptocurrency projects have launched with the specific goal to improve on Bitcoin’s privacy features over the years. And not without success. Several of these “privacycoins” are among the most popular cryptocurrencies on the market today, with four of them taking top-50 spots in coin market capitalization rankings.
That said, Bitcoin does have some privacy features which, as this month’s cover story details, have been improving in recent months and are set to further improve in the near future. This miniseries compares different privacycoins to the privacy offered by Bitcoin and to the privacy offered by other privacycoins.
In part 5: The upcoming Mimblewimble implementations Grin and Beam
In the summer of 2016, a person under the pseudonym “Tom Elvis Jedusor” (the evil wizard Voldemort’s real name in the French Harry Potter novels) published a white paper, to be mysteriously dropped in a Bitcoin research chat channel. In it, he described a proposal called “Mimblewimble” (a reference to a Harry Potter spell), which presented a radical slimming-down of the Bitcoin protocol.
Now, two years later, two projects are close to realizing versions of the Mimblewimble protocol, which will be launched as separate cryptocurrencies.
The first project is developed by a group of mostly pseudonymous volunteer contributors, several of which are using Harry Potter-related screen names — like “Ignotus Peverell,” who started the project. They call their upcoming cryptocurrency “Grin” (yet another Harry Potter reference), which is being implemented in the coding language Rust. Similar to projects like Bitcoin and Monero, Grin will not be maintained by any specific company or foundation, nor will it do an ICO or anything of the sort; instead, the project accepts donations. Once launched, miners will be able to mine one coin (“grin”) per second on average, and (unlike Bitcoin) this rate will never decrease. Grin is currently being tested and is roughly expected to launch in early 2019.
The second project was announced more recently and is called Beam. Beam is being implemented in coding language C++ (like Bitcoin Core). More comparable to Zcash, Beam will be launched and maintained by a for-profit company with the same name (currently headed by Israeli entrepreneur Alexander Zaidelson), though this maintaining role should later transition to a non-profit foundation. Beam will also have a founders’ reward: the Beam company and foundation will receive 20 percent of all newly mined coins for the first five years. It’s not yet announced what Beam’s emission schedule will look like, but (unlike Grin and like Bitcoin) it will be capped. Beam is also being tested right now and is scheduled to launch in December 2018.
Mimblewimble combines versions of several cryptographic tricks designed for Bitcoin. In addition, it utilizes some clever math to completely strip down what typical blockchains look like.
The first trick is Confidential Transactions (CT), which will also be deployed on Blockstream’s Liquid sidechain for Bitcoin. Confidential Transactions let users blind (or hide) the amounts that are involved in a transaction so that only the sender and receiver know how much money is involved. Using a cryptographic trick called the Pedersen commitment, anyone else can still perform math on the blinded amounts. This lets them verify that the sending and receiving end of the transaction equal out, and hence that no coins were created out of thin air.
The second trick is CoinJoin, originally proposed by Bitcoin Core contributor Gregory Maxwell. CoinJoin combines several transactions into one big transaction, where all senders send money to all receivers. If done right, this obfuscates which addresses (“inputs”) are paying which addresses (“outputs”).
In the Mimblewimble protocol, however, this is taken a big step further. By combining CT and CoinJoin with more clever math, Mimblewimble gets rid of traditional private keys, public keys and addresses, only keeping inputs and outputs (these are technically not the same thing as addresses). It also gets rid of the traditional signature per transaction, which is essentially replaced with a little bit of “excess transaction data” proving ownership of the coins.
Interestingly, Mimblewimble miners take all individual transactions that would have been included in a block and instead turn the whole block into what is essentially one big “CT and CoinJoin on steroids” transaction.
The end result of this “CT and CoinJoin on steroids” is something that seems alien compared to the standard blockchains we use today. Looking at a Mimblewimble block — a combined transaction of all transactions in it — it is completely unclear which inputs paid which outputs, and it is completely unclear how many coins were involved in any of the individual transactions. If enough people use Mimblewimble (more is better), hardly any trace of funds can be established at all, presenting a tremendous boon for privacy.
Furthermore — and this is what arguably makes Mimblewimble truly special — the protocol design allows old and new transaction data to be cancelled out against each other. This allows for a radical form of pruning: most old transaction data can be forgotten. New nodes don’t need to sync to the whole blockchain, and the amount of data that nodes need to store should grow much slower than with typical blockchains.
Where privacy features in other projects are often in conflict with scalability, Mimblewimble’s powerful privacy and scaling properties go hand in hand.
The innovative Mimblewimble architecture does come with some drawbacks. These include an absence of scripts (which makes blockchains programmable) and the requirement that wallets interact to create a transaction (no more sending money to address) — but both of these drawbacks can be worked around, to some extent.
More importantly, in the context of this article, Mimblewimble does not, in itself, counteract all types of blockchain analysis. If implemented naively, Mimblewimble leaves room for a type of analysis of the peer-to-peer network that closely resembles traditional blockchain analysis.
Specifically, a spy could deploy a node on the network that — like any other node — receives and forwards most (if not all) individual transactions. But — unlike any other node — this spy node would also record all these individual transactions. While all these transactions would subsequently be combined into a big “CT and CoinJoin on steroids” transaction by a miner, it’d be too late by then: The spy already knows which inputs are paying which outputs. (Though he’d still not learn how much money is moving around.)
This problem is not completely unsolvable; the Beam project has made some suggestions already. But it’s also not completely solved.
One proposed solution is to combine transactions between users even before they hit the network, similar to CoinJoin-related privacy solutions on Bitcoin. This would help the users involved, but it would also face a drawback similar to that on Bitcoin: Those users who feel they have “nothing to hide” may not want to bother with the added hassle. This, in effect, weakens privacy for all and could even raise suspicion for those that do use it.
A second proposal is to add “dummy” outputs to transactions, containing zero coins. By (automatically) spending the dummy outputs in a later block, this obfuscates where the money really moved to. This maneuver also comes at an increased cost, however, once again risking that not everyone will use it. (On the upside, it wouldn’t hurt Mimblewimble’s long-term scalability because such transaction data would cancel out and disappear.)
An even better solution would be to aggregate transactions as they are spread over the network, potentially combined with a Dandelion-type of peer-to-peer obfuscation technique. If nodes keep adding all the transactions they know about into a big CoinJoin-like transaction before forwarding it, a “snowball effect” would make it exceedingly hard for spies to learn anything useful. This solution is quite challenging to implement, however, and introduces several new problems. (But it can be combined with the dummy output solution, further benefiting the potential of both.)
All this brings us to Mimblewimble’s biggest and most obvious “weakness”: Grin and Beam are still works in progress. The potential of the Mimblewimble protocol is very promising, but much depends on the specific implementations, making it impossible to say exactly how strong the privacy guarantees of these projects will be and how this will compare to Bitcoin and other privacycoins.