In 2016, an anonymous author published a short paper under a pseudonym lifted from a Harry Potter villain, describing a spell that ties an enemy's tongue so they cannot speak a secret.
The joke was apt. The proposal described a way to write a ledger in which there is almost nothing to say — no addresses, no amounts, no history of where a coin has been. The author never revealed themselves, the paper circulated as a curiosity, and then a small group of cryptographers turned it into software.
This chapter is about what that design actually does, in plain language, and what it costs. Both parts matter. Mimblewimble is the reason Epic Cash can claim privacy without a shielded pool and a small chain without pruning a database, and it is also the reason using it feels different from using Bitcoin in a way that took years to smooth out.
What a transaction has to prove Strip a payment down and there are only two things the network must be convinced of.
That no money was created. The inputs are worth exactly what the outputs are worth, minus a fee.
That the owner authorized it. Whoever is moving the coins knew the private key that controls them.
Bitcoin proves both by showing everything: here are the inputs, here are the outputs, here are the signatures, check the arithmetic yourself. The proof is the disclosure. That is why the ledger is transparent, and it is why the ledger is a surveillance record.
Mimblewimble asks a different question: can you prove the arithmetic without showing the numbers?
Sealed envelopes that still add up The tool is called a commitment, and the intuition is a sealed envelope with a number written inside it.
You write an amount on a slip of paper, seal it in an envelope, and put the envelope on a table. Anyone can pick it up and see that it is a valid envelope. Nobody can see the number inside without opening it. Now do that with every input and every output in a transaction, and add a second trick: the envelopes are constructed so that the arithmetic still works while sealed. The network can verify that the input envelopes and the output envelopes balance, without ever opening one.
Cryptographers call this a Pedersen commitment. The construction uses a blinding factor — a random number mixed in with the amount — so that two envelopes holding the same amount look different, and one envelope cannot be compared to another to guess what is inside.
The network ends up knowing exactly one thing: this transaction did not create money. It knows nothing about who sent it, who received it, or how much moved.
Why you cannot hide an amount and allow a negative There is an obvious attack on the scheme as described. If the amounts are hidden, what stops someone from writing a transaction whose outputs are a large positive number and a large negative number, so that they balance but create money out of nothing?
The defense is a range proof: a cryptographic proof that each hidden amount falls within a valid range — no negatives, no absurdly large values — without revealing the value itself. This is where zero-knowledge proofs enter, and it is worth being precise about a distinction that confuses people: Mimblewimble is not free of zero-knowledge cryptography. It is free of a shielded pool. The proofs that keep the amounts honest are zero-knowledge proofs, and Epic uses a modern construction called Bulletproofs, which are compact and require no trusted setup — no ceremony, no toxic waste, no group of people who could collude to forge proofs if they kept a secret.
That last property matters more than it sounds. Several privacy systems have needed a multi-party ceremony to generate parameters, and a ceremony is a trust assumption, however well managed. Epic's range proofs do not require one.
No addresses, and what that changes Bitcoin transactions reference addresses — destinations that persist, accumulate history, and can be clustered. Mimblewimble has no addresses in the ledger at all. Outputs are one-time objects that exist only as an entry, and the ledger keeps no link from an output to the person who can spend it.
This is the technical reason for the claim on the cover of this book. Amounts and identities are hidden, and there is nothing on the chain to look up or hand to an analysis firm. Linking some payments is possible only through costly, targeted surveillance of the network itself.
It also creates a problem that nobody expects until they try to use it: if there are no addresses, how does a sender construct a payment to a receiver?
Under the hood, both parties contribute to the transaction. The sender cannot build a valid transaction alone: each party proves its own output is valid, and the two wallets jointly sign the kernel. That means the wallets have to talk to each other, exchange a small amount of data, and sign.
This is the interactivity cost of Mimblewimble, and it is real. Early implementations handled it by passing a file back and forth. That works between two people who are both at a computer, and it is hopeless for buying coffee.
Which is why the practical question for any Mimblewimble chain is not "does it hide the amounts" — it does — but "how does the wallet handshake happen in the real world."
The relay, and why the Onchain Note exists Epic's answer is a relay. Wallets can exchange the handshake data through an encrypted mailbox — the Epicbox relay — or over Tor, or as a file, or in the extreme as a message pasted into a chat. The sender addresses the payment to a mailbox identifier, the receiver's wallet collects it, and the transaction completes without either party being online at the same time.
That design decision has a visible consequence, and it is the single most practical thing to understand about using this coin.
Because there are no addresses on the chain, an exchange has nothing to credit when your deposit arrives. It cannot look at the ledger and see that a payment was sent to it, because the ledger does not say who received what. So it does something else: it gives you a number — an onchain note — and asks you to put that number in the payment. When the transaction lands, the exchange matches the note to your account and credits you.
Forget the note, and the exchange is holding funds it cannot attribute to anyone. This is not a quirk or a bug in the exchange. It is the direct, predictable consequence of a chain with no addresses, and it is why the guide in the appendix spends a page on a field your wallet labels "optional" and the exchange labels "required."
A privacy design that removes the address has to replace the address with something. The relay and the note are what replaced it.
Cut-through: why the chain is four gigabytes The second half of Mimblewimble is about what the ledger does not keep.
In Bitcoin, every transaction ever made is stored forever. A coin that was spent in 2013 is still in the database, because the history is the proof.
Mimblewimble removes the history that no longer matters. When an output is spent, both the output and the input that consumed it can be deleted — they cancel out — leaving only the proof that the transaction happened. This is called cut-through, and it applies within a block and, more importantly, across blocks.
What remains is a set of unspent outputs, a small header, and one kernel per transaction: roughly a hundred bytes that prove a valid transaction existed and paid a fee, without saying who, to whom, or how much.
The arithmetic is stark. Epic has produced more than three million blocks and its full chain is about four gigabytes — small enough to download on a home connection, validate on a laptop, and keep on a ordinary disk. A full Bitcoin node is measured in hundreds of gigabytes; a full Monero node is around two hundred; a Zcash node can pass three hundred. Epic is in a different category, and the difference is not engineering effort. It is a property of the ledger format.
This is the point where privacy and practicality stop trading off against each other. Cutting the spent data is what makes the chain small, and having no addresses and no amounts is what makes the remaining data useless to a surveillance analyst.
What this does not do Mimblewimble hides what is inside a transaction. It does not hide that a transaction happened at all, and it does not, by itself, hide where it came from on the network.
If your wallet broadcasts a transaction from an IP address that is also associated with you, the cryptography has done its job and the network layer has given you away. This is why the design includes Dandelion++, which routes a transaction through a small number of random relays before broadcasting it widely, making it difficult to connect the first sender to the eventual diffusion.
It is also why the wallet matters. Sending over Tor, or through the relay, changes what the network can observe. A private ledger with a careless network path is a locked door with the key under the mat.
And one more limit, honestly stated: the cryptography here is elliptic-curve based, like every other coin in this book. A sufficiently large quantum computer would break the commitments and the signatures alike. "Quantum future proofed" in the scorecard means the ability to change the scheme without rebuilding the monetary system, not immunity today.
What we now have Three claims, and the machinery behind each one.
Private by default. No addresses, no amounts, no optionality — and the range proofs that keep the hidden amounts honest.
Fungible. Nothing on the ledger records where a coin has been, so there is nothing to grade, taint, or refuse.
Small. Cut-through removes the spent history, leaving unspent outputs and a hundred bytes per transaction.
The next chapter takes the second of those and asks the harder question: what does it actually buy you when a government, an exchange and a mining pool all decide they would rather not process your coins?