Part 1 of 4: Mimblewimble / MWC - Scalability

This will be the first installment of a 4 part series making the case for Mimblewimble and specifically MWC (Mimblewimble Coin). We will go over the major advantages of the Mimblewimble protocol and explain in detail our thesis and why we created MWC.

In part 1, we covered scalability. In part 2, we covered privacy. In part 3, we covered fungibility. In part 4, we tie them all together.

First, some background: Mimblewimble is a blockchain protocol which was disclosed to the public through a paper written by the pseudonymous, Tom Elvis Jedusor on July 19, 2016. The paper was significant because of the protocol's massively better scalability, fungibility, and privacy when compared to previously existing blockchain protocols. Since the paper's release, revisions have been made by Andrew Polestra of Blockstream and three major Mimblewimble based blockchains have been released: first Beam, then Grin, and most recently, MWC. The keys to the protocol are that there are no addresses, the amounts are encrypted and old transactions can be deleted.

As we have stated in the past, we don't consider MWC to be privacy coin even though it has significant privacy implications. We consider it more of a general upgrade to blockchain protocol. The fact that legacy blockchains do not encrypt amounts and have publicly known addresses that can be blacklisted and tracked is more what we would consider to be a bug and it is part of what Mimblewimble addresses, but not all. For these reasons, we wanted to emphasize in the first part of the series, the scalability of the Mimblewimble blockchain.

Scalability is a widely used term in the cryptocurrency world and it is frequently misused and misunderstood. In many cases, when people discuss scalability, they are actually talking about capacity increases. So, let's start by defining the terms. Scalability is the ability of a piece of software to deal with a specific workload whereas capacity is an increase in hardware such that more work can be done. In the software world, we call capacity increases "throwing hardware at it". It just means instead of optimizing the code, you spend money to buy more server resources. Scalability is generally considered a better solution to the problem than a capacity increase.

Before we get into examples, let's talk about what the scalability bottlenecks are in Bitcoin. When developers talk about scalability in Bitcoin, they are primarily talking about the "Initial Block Download" problem or IBD for short. One of the properties of Bitcoin is that in order to validate a transaction, you must download the entire history of all blocks first. Since this continually grows, it becomes harder and harder to validate transactions. As of right now, the blockchain is 250 GB so all of this data must be downloaded and processed in order to validate any Bitcoin transactions. While there are other parts of the codebase that can and have been optimized for scalability, this turns out to be the hardest part to scale. So, discussions around Bitcoin's scalability center around this aspect.

So, let's take some examples in the crypto world and talk about whether they are scalability improvements or capacity increases. First, a block size increase. A block size increase is a capacity increase. It makes it so that everyone on the network (from miners, to exchanges, to users) have to process more transactions and download more data, therefore it is a capacity increase. In particular with respect to IBD, a bigger block size means more data to download as part of the IBD. Next, let's talk about Schnorr signatures (or signature aggregation). This is a technique that allows us to make some transactions more compact. On average, it is expected to make blocks about 30% smaller. This is clearly a scalability increase because less resources are used to do the same work and IBD is less when this technique is used. Finally, let's talk about Segwit. Segwit is primarily a capacity increase because it allows for a 4 mb block weight, as opposed to the previous 1 mb block size. It also includes a fix to the transaction malleability bug that opened up the door for Lightning network. Since lightning network allows multiple off-chain transactions for a single on-chain transaction, it can be considered a scalability improvement. So, since Segwit enabled this improvement, it can be said that it is an indirect scalability improvement because it enables lightning network.

Before we get into Mimblewimble, let's talk about capacity increases and why we can't just increase the capacity of Bitcoin and expect better results. The reason IBD is a big deal is because as you increase the requirements of full nodes on the network, you increase the centralization of the network. This is because it gets harder and harder to download and store the dataset so fewer participants attempt to do so. We've seen this with blockchains like the Ethereum blockchain which now require more than 1 TB for IBD to do a full validation. This is why almost no one, including the Ethereum foundation runs a fully validating node. Ethereum is clearly more centralized than Bitcoin. In Bitcoin itself, we have examples of forks that were primarily done as a means to increase the capacity. The two most direct examples are Bitcoin Cash and Bitcoin SV. Bitcoin Cash has 32 mb blocks and Bitcoin SV has much larger blocks even as big as 128 mb (maybe bigger it wasn't clear from a google search what the actual limit is). Since it's been over two years since the BCH fork, it's fairly clear that the market does not favor capacity increases and rightfully so. The only way to create value is through scalability increases. This is because the decentralization of the Bitcoin network is key to its utility.

Now that we have made the distinction between scalability and capacity and explained why the market favors scalability increases over capacity increases, let's talk about the scalability improvements that can be expected from Mimblewimble. As mentioned, one of the keys to the Mimblewimble protocol is the ability to delete old spent transactions from the blockchain. What this means is that if I send you 1 MWC (let's call this transaction 1) and you send the same MWC back to me (let's call this transaction 2), we no longer need to store most of the data associated with transaction 1. In Bitcoin, we'd need to save the entirety of both transaction 1 and transaction 2. The implications of this, ability to delete old spent transactions, is enormous. An analysis was done [see https://www.grin-forum.org/t/grin-blockchain-size/1334] and if Bitcoin were ran as a Mimblewimble blockchain from the start and it was determined that it would take around 1/3 the space required for the Bitcoin blockchain. That means the Bitcoin blockchain could have had three times more capacity while maintaining the same level of decentralization. When compared to a privacy coin like Monero, the Mimblewimble chain would use approximately 1/10 the space.

What does this mean? Well, if we can get a 3X capacity increase to Bitcoin while maintaining the same level of decentralization, that means the supply of transaction space in a Mimblewimble chain can be 3 times that of a legacy blockchain. That will have a direct impact on the cost of transactions. Before we talk about how much less transaction fees would be on a Mimblewimble chain, let's review how Bitcoin transaction fees are determined. Since, as we have seen Bitcoin has a finite block size, the only way to determine which transactions get in a block and which don't is through a fee market. For most of the history of Bitcoin, blocks have not been full, however as Bitcoin increases in value and becomes more widely used, and we cannot increase the block size, it should be expected that blocks will fill up and remain full. In late 2017, blocks filled up and fees went up significantly. In the expected state of Bitcoin, with full blocks, fees will be significantly higher than they are today. So, a 200% increase in capacity, which can be expected from an upgrade to a Mimblewimble based blockchain, will allow for massively lower fees. To understand this extra capacity's impact on fees, let's imagine you have an Island that normally has 1 boatload of milk delivered per week. Now imagine 3 boatloads are delivered one week. What would the expected impact to prices be? Since the milk would very quickly go bad, the excess milk would have to be sold for much less than full price. Block space is very similar to goods like milk because it's use it or lose it. Every block has a specific capacity and you can't make the next block bigger just because the previous block was not used. So, in a sense the block space spoils instantly. That means we can expect prices for block space in a blockchain that has 3 time the capacity to be significantly lower. It's quite possible that fees would be 50% less, with the same level of decentralization, on a Mimblewimble chain. In this case, the Mimblewimble based chain, at scale will be able to offer much lower fees than a legacy chain. In the real world any business that can undercut their competitor by 50% would be expected to almost immediately put the competition out of business. That's because price is normally the most important factor used by consumers to distinguish between products. As we saw, the market understands that lower fees alone doesn't indicate more value (i.e. BSV/BCH), but when centralization stays the same, and fees are lower, you have a completely different scenario.

One might argue that this analysis was for on-chain transactions and in the future the majority of transactions will be done off-chain. That's a fine argument, but the same applies to Mimblewimble. Likely the majority of transactions in a Mimblewimble based blockchain would be done in a layer two solution like Lightning Network. Consumers of the block space would care about the cost of on-chain fees since at times, they will still have to do on-chain transactions. It's the total cost to transaction that matters. Imagine the legacy chain has $1,000 on-chain transaction fees and the Mimblewimble chain has $500 transaction fees. Clearly a Mimblewimble based chain would win out and likely render the legacy chain obsolete in such a future scenario. This scenario is not at all far fetched either and what's very clear is the fees will be much lower in a Mimblewimble chain than legacy chain for a given level of decentralization.

The last thing we'll say about the scalability increase of Mimblewimble is that when we're talking about cryptocurrency, let's be clear that the only significant use case, thus far has been that of money. Money has been studied widely and there are 6 properties that determine what is used as money. Generally the best good with respect to these 6 properties in a geographic region is used as money. These properties are: divisibility, portability, durability, recognizability, fungibility, and scarcity. So, how does scalability fit in? It maps directly to portability. If it costs me $1,000 per transaction on a legacy chain and $500 on a Mimblewimble based chain the Mimblewimble based money is significantly more portable than the legacy chain based money because there is much less friction, while all of the other variables are equal (not to mention the increased privacy and fungibility).

This completes our discussion in part 1 on the Scalability of MWC and Mimblewimble. Stay tuned for part 2 which will be on Privacy, part 3 on Fungibility, and part 4 which will tie it all together.