Privacy in Crypto: Intro to MimbleWimble & Grin

One of the great things about being in the crypto space is the ability to experience and witness revolutionary ideas being proposed, tested, and evolve in real time. I’m not talking about the ICO shills, but truly innovative open protocols that leverage cryptographic primitives to enable us to transact in a more private and decentralized manner.

The industry is filled with personalities with all sorts of technical, financial, and legal backgrounds who often clash on ideologies on what the future of money should look like. Most are known persons with existing reputation, but once in a while, anonymous, mysterious actors appear completely out of nowhere to make game-changing contributions to the space.

We’ve seen this with the infamous Satoshi Nakamoto and his/her/their Bitcoin whitepaper in 2009. And today, we are seeing the advancement of an exciting new, privacy-preserving blockchain protocol called MimbleWimble, the history and concepts of which I will explore here.

harry potter and The history of MimbleWimble

🤐In late 2016, a pseudonymous character named Tom Elvis Jedusor showed up on the bitcoin developers’ chatroom and posted a tor link, which hosted a single file named MIMBLEWIMBLE, outlining a new design for a privacy-preserving, massively prunable blockchain. Tom Elvis Jedusor, as some may recognize, is the name of Voldemort’s given name in the French Harry Potter books. Diehard fans will also recognize MimbleWimble as the spell that ties the target’s tongue in a knot, preventing coherent speech. Tom Elvis Jedusor to this date has never logged into the chatroom again. Here is Tom’s first and only post:

Screen Shot 2019-02-24 at 2.00.00 AM.png

During the weeks following, cryptography experts examine MimbleWimble’s trust model and quickly came to recognize its legitimacy. Cryptographers Andrew Poelstra and Avi Kulkarni soon develop a “sinking signatures extension to improve the protocol’s scaling properties.

A while later, a character named Ignotus Peverell (the original owner of Harry’s invisibility cloak) appeared on the chatroom and announced a project to implement the MimbleWimble protocol. More Harry Potter characters, including Seamus Finnigan and Moaning Myrtle, later arrived to further add to the project. This MimbleWimble implementation is called Grin. Before we can dive into that, let’s look at the protocol itself…

what is mimblewimble?

MimbleWimble is a blockchain-based ledger designed to bring strong privacy and confidentiality guarantees. Its implementation is very different from Bitcoin in that it does not store transaction details that could be used to trace specific txns back to an entity. A reminder of how Bitcoin’s (UTXO-based*) transactions work…

transaction contains inputs and outputs:

  • All inputs into a transaction must be spent

  • Inputs are unspent outputs from a previous transaction.

  • Outputs will be unspent (i.e. still spendable) until they are used in a new transaction

The wallet software automatically aggregates various txn inputs that add up to construct the desired output amount. For example, if you have been sent $5, $2, and $10 on separate occasions, the wallet will decide how to best use these unspent input …

The wallet software automatically aggregates various txn inputs that add up to construct the desired output amount. For example, if you have been sent $5, $2, and $10 on separate occasions, the wallet will decide how to best use these unspent input to construct an outgoing transaction worth $15.

Image source: Bitcoin whitepaper

The inputs of a transaction become the spendable outputs of a subsequent transaction in later blocks. To sync with the Bitcoin network, a node must verify that all transactions are valid by replaying all transactions starting from the genesis block to see if each txn outputs equal its inputs (minus mining fees). Because of this, the blockchain has to preserve individual transaction data – making it quite memory intensive.

*UTXO = unspent transaction output

joining the network and verifying transactions

🔑Since you need the private key to produce a digital signature, and the digital signature to make a transaction, access to the private key is the equivalent of coin ownership. If someone gets a hold of your private keys they have just as much control over the funds as you do. This is why it's so important to keep your private keys safe and secret. A diagram of how Bitcoin transactions are linked:

Image source: Bitcoin whitepaper

Image source: Bitcoin whitepaper

“Bitcoin”s are ultimately transaction outputs sent to an address associated with a public key. The person who holds its corresponding private key (i.e. the recipient) now has the rights to spend that Bitcoin in a subsequent transaction. The current transaction input is a reference to a previous transaction output – thus, you can’t create and spend bitcoins out of nowhere. Nodes are working to verify that:

  • The inputs of the transaction are unspent

  • Sum of inputs is greater than or equal to sum of outputs

    • Individual transaction input/output values are visible and nodes can validate a transaction by checking inputs and outputs

  • The ScriptSig successfully unlocks the previous ScriptPubKey — meaning that the person holding the private key signing to authorize the current transaction has, at some point, been the recipient of the bitcoins they are trying to spend.

Each input is an output from a past transaction. For each input there is a distinct signature (scriptsig) which is created in accordance the past-output that it is spending (scriptpubkey). [17]

Every input has a key (“ScriptPubKey”) associated with it, along with a signature (“ScriptSig“) for a transaction with that key.Image source: Programming Bitcoin by Jimmy Song

Every input has a key (“ScriptPubKey”) associated with it, along with a signature (“ScriptSig“) for a transaction with that key.

Image source: Programming Bitcoin by Jimmy Song

You can learn about bitcoin transactions in detail in my previous post.

The MimbleWimble network, like Bitcoin, is one in which users may join or leave the system at any time in a decentralized, permissionless manner. Upon (re)joining the network, anyone should be able to determine the current network state and verify that it is the outcome of valid state transitions - without having to trust any third parties.

cryptographic primitives for mimblewimble

To understand how privacy is achieved on MimbleWimble, we take a look at confidential transactions and Coinjoin – proposed strategies to enhance privacy on bitcoin.

Confidential transactions allow you to encrypt transaction values and cryptographically verify that the outputs and inputs add up to zero without having to know the amounts itself. Verifiers only care about whether the sum going in equals the funds going out. They can do so without knowing the specific values involved using something called Pedersen commitments. [4]

CoinJoin is a scheme proposed by Gregory Maxwell. This technique allows us to join multiple transaction inputs together and route the appropriate values to their destinations without knowing exactly who paid whom how much. This protocol involves N users agreeing on a uniform output size and provide inputs amounting to that size. The users then all sign the transaction, which then could be transmitted. [16']

This coinjoin implementation is interactive as everybody who is transacting has to consent to it as per the protocol. If Alice wanted to make a coinjoin payment, she can find someone else who also wants to make a payment (e.g. Bob) and they can make…

This coinjoin implementation is interactive as everybody who is transacting has to consent to it as per the protocol. If Alice wanted to make a coinjoin payment, she can find someone else who also wants to make a payment (e.g. Bob) and they can make a joint payment together. Externally, it is unclear who paid Ted and who paid Carol.

Image source

Alice and Bob’s signatures for their respective inputs are completely independent of one another. They can agree on the set of inputs to spend, the set of outputs to pay to, and then separately sign a transaction and later merge their signatures. The transaction will not be accepted by the network unless both Alice and Bob’s signatures are provided. They do not have to trust each other in order to participate in a coinjoin transaction as each party has to consent to it themselves.

how these are applied to preserve privacy (and space) on mimblewimble

So, a blockchain is simply a chain of blocks containing a list of transactions. The public blockchains that we’ve seen so far (e.g. Bitcoin and Ethereum) exposes the sender and receiver’s addresses for each txn as well as their amounts. Nodes can use this information to verify that there is no unexpected inflation of coins, no double spends.

How do we preserve this verifiability without revealing specific transaction details? MimbleWimble does so by extending the ideas behind coinjoin and confidential transactions for the entire set of transactions within a block. MimbleWimble transactions contain:

  • Inputs: references to old outputs

  • Outputs: confidential transaction outputs - group elements which blind and commit to amounts

    • Along with a proof that the encrypted output does not represent a negative value (“rangeproof”)

  • Kernels (excess): the difference between outputs and inputs of that block, plus the signatures of all transacting parties in that block (for authentication and proof of non-inflation).

In MimbleWimble, we want to verify that

sum of inputs - sum of outputs - mining fee = kernel

Instead of making each transaction input and output values public, MimbleWimble aggregates all the transacting parties and verifies the entire sum instead of each signature. We calculate sum of inputs - sum of outputs to end up with a multi-signature “kernel” that was authorized by everybody involved in that block of transactions - the owner of every input and the owner of every output. This means we don’t have store individual addresses and amounts on the blockchain. Two transactions which can be merged into a block to form one, removing all intermediary information. [8]

This diagram is based off of Andrew Poelstra’s presentation on MimbleWimble.

This diagram is based off of Andrew Poelstra’s presentation on MimbleWimble.

So if Bob sends 1 Bitcoin to Alice who then sends 1 BTC to Carol, the end result would be as if Bob sent 1 BTC to Carol. But since Alice's signature is preserved in the excess, it is provable that this transaction did not take place without Alice’s consent.

If we zoom out and extend this idea to the entire blockchain, we can get a better idea of which information is preserved and which can be pruned away:

Only unspent outputs, aggregated signatures and new currency generation (coinbase) are stored on the blockchain, saving huge amounts of spaceThis diagram is based off of Andrew Poelstra’s presentation on MimbleWimble.

Only unspent outputs, aggregated signatures and new currency generation (coinbase) are stored on the blockchain, saving huge amounts of space

This diagram is based off of Andrew Poelstra’s presentation on MimbleWimble.

This is massively space and time-saving when someone wants to sync with the blockchain for the first time. In Bitcoin this can take days, because what the node has to do is build the blockchain from scratch, verifying that every transaction from the first ever one in 2009 until today is valid.

Because of the differences in MimbleWimble’s blockchain design and that of Bitcoin, integrating it as a feature on Bitcoin is a very difficult task. However, we could experiment with it as a sidechain to Bitcoin. One of the hinderances to backward-compatibility is the fact that MimbleWimble transactions are scriptless - meaning that it does not support the Script programming language that Bitcoin uses to construct and verify transactions. Having a scripting language is useful because you can extend other features on the blockchain, the downside being lower privacy. Essentially, MimbleWimble puts privacy first at the expense of all other features. [9]

Despite the difficulty of building MW on Bitcoin right away, there is consensus that the protocol is worth experimenting with. Thanks to some Harry Potter characters, we have a live implementation of the MimbleWimble protocol on the mainnet…

😁Grin

In Grin, there are no addresses, no amounts, and 2 transactions which “spend” one another can be merged to form one - with all intermediary information removed. A Grin block looks just like one big transaction and original associations between inputs and outputs are not preserved on the blockchain. Unless you directly participated in the transaction, all inputs and outputs look like random pieces of data:

Information on block #53132 on GrinExplorer

Information on block #53132 on GrinExplorer

Transactions in this block, plus its kernels:

Inputs are Pedersen commitments which are references to previous outputs, there are also no identifiable addresses. To an observer this is indistinguishable from random pieces of data.There are no visible amounts and transactions are aggregated - ma…

Inputs are Pedersen commitments which are references to previous outputs, there are also no identifiable addresses. To an observer this is indistinguishable from random pieces of data.

There are no visible amounts and transactions are aggregated - making it very hard to link individual inputs to its outputs. Each Grin block is essentially a big coinjoin transaction signed by all parties involved.

Kernels represent the excess value, lockheight, fees, and signatures of the transacting parties involved.

Kernels represent the excess value, lockheight, fees, and signatures of the transacting parties involved.

  • No addresses

    • All outputs in Grin are unique and have no common data with any previous output. Instead of relying on a known address to send money, transactions have to be built interactively, with two (or more) wallets exchanging data with one another. This interaction does not require both parties to be online at the same time.

  • No individual transaction data

    • Grin nodes can verify the correctness of total coin supply by comparing the sum of all money created by mining with the total sum of money that's being held by users

  • zero-confirmation cut-throughs

    • This refers to the Bob —> Alice —> Carol transactions mentioned above. If the coins end up with Carol we can remove the intermediary transaction information (Bob —> Alice) altogether whilst preserving its integrity, saving space.

  • Scalability

    • Most outputs end up being spent by another input in a later block. Thus, all spent outputs can be removed - and the whole blockchain can be stored, downloaded and fully verified in just a few GBs or less (assuming # txns similar to bitcoin). The Grin blockchain scales with the number of users (unspent outputs), not the number of transactions.

    • We currently also need to preserve the kernel (~100 bytes) for each transaction

Grin's emission rate is linear, meaning that a fixed amount is emitted every year and it never drops. The block reward is currently set at 60 grin with a block goal of 60 seconds. The rationale given for this is that 1) dilution trends toward zero and 2) a non-negligible amount of coins gets lost or destroyed every year. In contrast, Bitcoin's initial 50 BTC block reward is halved every 4 years until there are 21 million bitcoin in circulation. [12] Here is Grin’s monetary policy in detail.

Grin leverages Dandelion relay, which provides additional anonymity as to which IP or client the transaction originated from. [11]

Grin launched on January 15th 2019 and is still highly experimental. Unlike many cryptocurrencies today, it began with a cypherpunk-y ethos in that there was no incentives skewed towards creators. There was no ICO, no pre-mine, no advisors, no investors, nor founders’ rewards. The project is largely community-driven and funded by donations.

challenges & caveats

With sophisticated monitoring, it is still possible to reconstruct a transaction graph. Therefore it’s still remains to be tested how resistant the privacy features of Grin are to motivated adversaries.

While MimbleWimble is scriptless, many contracts that would require a script in Bitcoin can be achieved with Grin thanks to some cryptographic tricks (see: scriptless scripts). So far, there are ongoing developments and discussions to include multi-signature transactions, atomic swaps, time-locked transactions and outputs and even Lightning Network on Grin. These can work in theory but have yet to be tested in the wild, so proceed with caution! [12]

looking forward…

Fungibility is the ability for equal units to be interchangeable. Cash of equal units is fungible as most people wouldn’t think twice about exchanging two $10 bills for a $20 bill. However, if chain analysis allows companies to track cryptocurrencies, there is a chance some UTXOs on could be flagged (“tainted”) unless you use add-on privacy features like on a sidechain or take additional steps to obscure transaction information which, at its current stage of development, is not straightforward for the layman. If for some reason your crypto has been traced to a blacklisted source, there is a chance it won’t be accepted. Privacy is therefore an extremely important when considering something to be used as a money. [15]

There is a lot of work ahead to make privacy work on open blockchains at scale, and at the moment this technology is still highly experimental and proposals that seem theoretically sound are likely to face unexpected issues when used in practice. Lack of developer tools and poor UX are also bottlenecks for people looking to help out with the project or enter the ecosystem. This is why the Ethereum ecosystem has arguably been most successful at attracting new contributors - a lot of infrastructure is available out-of-the-box for developers to get started, with ample documentation and video courses to guide them.

Besides new privacy protocols and cryptographic tricks, there are products in the crypto ecosystem that helps users maintain their privacy as well. Bitcoin wallets like Samourai and Wasabi have features that make transactions more difficult to trace. Samourai enables something called stonewalling which makes regular payments look like a coinjoin transaction - essentially creating “fake change” that sends Bitcoin back to addresses that you control while appearing like it’s a coinjoin txn involving multiple parties. Another feature is something called ricochet, which adds multiple hops to your transactions to make it look like it has gone through more intermediaries. So instead of sending bitcoin from your mobile wallet (non-identifying in formation) directly to your Coinbase account (with identifying information), you can enable ricochet to obscure an entity that can identify you from your wallet address. [14]

Without turning this article into a guide on crypto-privacy, I’d like to end on a similar note to my previous articles by concluding that there are plenty of rabbit holes to enter when it comes to privacy in crypto. MimbleWimble is an exciting technology to follow, with a potential to greatly enhance the privacy and fungibility of bitcoin. Implementing MimbleWimble on a separate chain with its own coin provides a good testbed for its privacy and scalability features. We could consider Grin as an experimental chain on which to innovate quickly and enhance privacy features - and sometime in the future, implement the MimbleWimble protocol as a sidechain on Bitcoin once the community considers it adequately robust. Grin’s cypherpunk ethos and community are perhaps its greatest strength in addition to its exciting technology. I look forward to exploring more privacy-enhancing protocols in future articles. I hope this was helpful to you as a primer to Grin and MW, please leave a comment and spread the knowledge! Thanks for reading,

🥃Cheers