All (full) Bitcoin nodes verify all transactions on the network. This allows the system to be entirely trustless and decentralized, but also presents significant drawbacks. Privacy and fungibility are at odds, because public transactions allow anyone to trace the flow of bitcoins over the blockchain. Meanwhile, verifying a growing number of transactions adds to the cost of running a node, which could be a centralizing force.
But perhaps these drawbacks can be tackled. Last week, a new white paper was somewhat mysteriously dropped on a Bitcoin research channel, written by the pseudonymous author “Tom Elvis Jedusor” (Voldemort’s real name in the French edition of the Harry Potter novels). His proposal “Mimblewimble” — a reference to a Harry Potter spell — presents a radical slimming-down of the Bitcoin protocol that could not only dramatically increase privacy and fungibility, but also present significantly more scalability than Bitcoin’s current blockchain architecture.
Mimblewimble may just hit two giant birds with one stone. Here’s how.
Hiding Amounts
Mimblewimble is based on some of Bitcoin’s familiar privacy features. One of these is Confidential Transactions, which was mostly developed by Bitcoin Core and Blockstream developer Gregory Maxwell and is currently deployed on Blockstream’s Elements Alpha sidechain.
Confidential Transactions lets senders encrypt the bitcoin amounts in transactions with random strings of numbers called “blinding factors.” This process works because transactions also include information with which (only) receivers can decrypt the amounts. And, by utilizing a cryptographic trick called the Pedersen Commitment, anyone else can still perform math on the encrypted amounts. Specifically, Bitcoin nodes can subtract the encrypted amounts on the sending side of transactions (“inputs”) from the encrypted amounts on the receiving side of transactions (“outputs”). If the two sides cancel out to zero, it means the combined inputs and the combined outputs are equal, and no bitcoins were created out of thin air.
Mimblewimble sort of turns this trick on its head as the receiver of a transaction generates the blinding factor. This is important because as one of the main deviations from the current Bitcoin protocol, this blinding factor is effectively used to prove ownership of the (blinded) bitcoins — private keys are no longer in play at all. (Nor are public keys or addresses.)
Proving ownership of the blinding factor itself revolves around a series of cryptographic tricks that are Mimblewimble’s closest equivalent to Bitcoin’s cryptographic signatures, though the full extent of these tricks is beyond the scope of this article.
It is important to note, however, that part of these mathematical maneuvers includes the introduction of a sort of “dummy output.” Where transaction outputs normally indicate under what conditions the receiver of a transaction may later spend the bitcoins, these dummy outputs are really just random numbers to ensure that only the person who generated the blinding factor can spend the bitcoins in the real outputs.
Combining Transactions
Another familiar Bitcoin trick that inspired Mimblewimble is CoinJoin, first proposed by (again) Maxwell.
CoinJoin allows users to bundle their transactions into one bigger transaction, scrambling all inputs (the “from” part of a transaction), as well as all outputs (the “to” part). This potentially obfuscates which bitcoins were sent from which address to which address, and breaks the assumption that all inputs belong to the same user.
Mimblewimble (and a fix by Blockstream mathematician Andrew Poelstra) takes this concept a bit further and completely gets rid of transactions once a new block is created. Instead of transactions, Mimblewimble blocks mainly consist of three lists: a list of new inputs (referring to old outputs), a list of new outputs and a list of cryptographic signatures created with the aforementioned dummy outputs.
Utilizing the Pedersen Commitment scheme, all nodes can use the input list and the output list, and verify that no bitcoins were created out of thin air. The dummy output signatures, meanwhile, prove that all individual transactions must have been valid. Acting rather like “stamps of approval,” these dummy output signatures only add up mathematically if the whole transaction itself does.
And since it is never revealed which inputs spent bitcoins to which outputs exactly, nor how many bitcoins were actually spent, no trace of funds can be established at all. As such, Mimblewimble presents a tremendous boon for privacy and fungibility.
Scalability
And then there’s the scalability improvement.
Currently, many transactions on the Bitcoin network are linked. Spending a bitcoin really takes an output from a previous transaction and turns it into an input of a new transaction. This means that if an older transaction is invalid, a newer transaction that relies on the older transaction is invalid, too. So to be able to validate all transactions on the Bitcoin network, nodes must know all transactions that ever took place; the entire blockchain. (That’s currently some 80 gigabytes worth.)
But with Mimblewimble there is no longer really such a thing as a transaction history per coin. Each coin does have a specific block in which it was first created. But from then on, its value simply becomes part of the combined Unspent Transaction Output (UTXO) set, which defines all outputs that store coins and could potentially be spent at any time.
This means that in order to verify new transactions, nodes no longer need to care about previous transactions. All they need to care about is that the specific outputs used are valid.
With even more clever math, nodes can establish the validity of outputs relatively easily. They just need the block headers of all blocks (a sort of index of blocks without all transaction data) and the aforementioned dummy output signatures: both relatively compact data-sets. All other transaction data — almost the entire blockchain — can be safely discarded.
The benefit compared to other anonymizing techniques is substantial. If Confidential Transactions and CoinJoin had been used in Bitcoin from day one, nodes would currently require more than a terabyte of data to operate. With Mimblewimble, they would need closer to 120 gigabytes. And perhaps even more interesting: where the blockchain necessarily has to grow over time, the required Mimblewimble dataset does not, and can actually shrink if more bitcoins are stored in fewer outputs.
Compatibility
Now for the bad news. Mimblewimble, in its current form, is not very compatible with the Bitcoin protocol. This is mainly because for Mimblewimble to work, script must be purged from transactions. As such, there would no longer be room for a whole set of Bitcoin features, like time-locked transactions (used for the Lightning Network among other things), atomic swaps (for cross-blockchain interoperability), and more.
But that doesn’t make Mimblewimble useless. Mimblewimble may, for instance, be the perfect fit for a privacy-focused sidechain. Bitcoin users could lock their bitcoins into a specific output on the Bitcoin blockchain and “move” their coins to the Mimblewimble chain. On this sidechain, users could transact freely and privately for as long as they want, until the new owner decides to “move” the funds back to the Bitcoin blockchain by unlocking the original output.
Due to the efficiency offered by Mimblewimble’s sidechain, the added burden of maintaining it would be very manageable. Moreover, it could potentially unload much data from the Bitcoin blockchain, increasing scalability even for those who don’t use Mimblewimble at all. Where sidechains are typically not considered a scaling solution, Mimblewimble offers one.
For a full technical explanation of Mimblewimble, including the mathematical details, see the white paper.
Written by Aaron van Wirdum for the Bitcoin Magazine | Original article: https://bitcoinmagazine.co…
---------------------
Liked this article? Share it with others:
Follow Us for Latest News & Articles:
