LibraryPrivacy2016Design paperCorpus record
Mimblewimble
Mimblewimble. Tom Elvis Jedusor.
A short 2016 note on a ledger that stores confidential transactions and can delete spent history. Grin and Beam are later implementations. The note itself is the primary text.
Mimblewimble stores a chain of confidential outputs and the kernels that authorise them, and it lets spent history be cut away without breaking the check that no value was created.
The five-minute read
The chain does not need every old story
If amounts are commitments, a spent output and the input that consumed it can cancel. What remains is the set of outputs that still exist, plus proof that each cancellation was authorised.
A transaction is a set of excesses
Inputs and outputs are commitments. Their difference is a kernel: an excess that commits to the fee, with a signature. The signature is the authority. There is no script in the Bitcoin sense.
Cut-through is the scaling claim
Once an output is spent, a node that only wants the current state can drop the intermediate history. The paper's bet is that the state, not the narrative, is what must be kept.
Privacy is the cancellation, not a ring
Mixing happens because transactions can be joined before they are published, and because the chain does not keep the path. It is a different privacy mechanism from CryptoNote and from Zerocash.
Scripts were the thing that got cut
The original design is hostile to rich predicates. Later systems added layers for contracts. Those layers are not in the short paper, and they change the 'nothing but kernels' picture.
One action, walked through
- A sender and recipient build a transaction together, so the recipient's output commitment is created without a public address being reused on a broadcast.
- The difference between input and output commitments is the kernel, which commits to the fee.
- Both sides contribute randomness so neither can unilaterally reconstruct the other's blinding factor.
- The kernel is signed. Nodes check that the commitments sum and that the signature is valid.
- After the outputs are later spent, a pruning node drops the cancelled pairs and keeps the unspent outputs and the kernel set it still needs.
The argument, unpacked
Pruning only works if the proof is in the kernel
You can delete history only if the authorisation does not live in that history. Mimblewimble puts authorisation in the kernel's signature and the balance in the commitments. A design that prunes but keeps a script that must be replayed has not earned this cut.
Interactive construction is a product decision
The recipient helps build the transaction. That is how blinding factors stay safe. It is also a worse fit for 'send to an address while the recipient is offline', which is the payment habit Bitcoin taught. Papers that ignore the interactivity are describing a different wallet.
Joined transactions are the anonymity set
Privacy improves when several payments are aggregated before they land in a block. If every payment is broadcast alone, cut-through still saves disk, but the graph is easier to read. The scaling claim and the privacy claim are related, and they fail separately.
What has to be true
- Commitment schemes are homomorphic, so inputs and outputs can be added without opening them.
- Kernels cannot be forged. The signature scheme is the whole authorisation story.
- Enough transactions are aggregated, by users or by the block builder, for the privacy claim to mean anything.
- Recipients can participate when a payment is built, or a later extension has replaced that step honestly.
What happened after the paper
Grin and Beam implemented the idea, with different emission and wallet choices. Mimblewimble extension blocks and other 'add it onto Bitcoin' proposals came later and were not the 2016 note. Script-like covenants in descendant systems should be read as amendments, not as pages of this paper.
What to check before you use the idea
- Can a wallet pay someone who is offline, and if so, which extension allows it?
- What does a new node download: full history, or the unspent set plus kernels?
- Who aggregates transactions, and is that aggregation optional?
- Where would a contract predicate live if the product needs one?
Terms
- Kernel
- The excess commitment and signature left after inputs and outputs cancel. It authorises the transaction and commits to the fee.
- Cut-through
- Deleting a spent output and the input that consumed it, because their commitments cancel and the kernel already carries the proof.
- Blinding factor
- The secret randomness in a commitment. It hides the amount. It has to be handled so the other party cannot steal the coin.
- Homomorphic commitment
- A commitment you can add. The sum of commitments to amounts is a commitment to the sum, which is how balance is checked in private.
The problem the paper names
Bitcoin keeps every spent output forever, and it keeps the script that spent it. Mimblewimble asks whether a chain whose only job is value transfer can commit to the current unspent set and a kernel of transactions, and drop the rest.
What the design proposes
- Values sit inside Pedersen commitments. The chain checks that inputs minus outputs sum to zero, plus the fee.
- Spent outputs can be cut through, because only the excess and the kernels need to stay.
- There is no script in the classic Bitcoin sense. The transaction is the proof of balance.
How the mechanism is specified
- Two parties build a transaction by contributing blinding factors so neither learns the other's value, and the combined commitment balances.
- A cut-through of intermediate outputs shrinks what a new node must download, if the kernels remain.
- The note is deliberately small. It does not specify a full peer-to-peer network.
What this page does not treat as proven
- Grin and Beam added consensus, wallets and policy that are not in the 2016 text.
- Removing scripts also removes the easy place to put application logic. That is a constraint, not a footnote.
- Confidentiality here is about amounts and the pruned graph, not a general smart-contract privacy claim.
Why a venture studio still reads it
Relevant when a venture only needs to move value and is about to inherit a general-purpose chain out of habit. Mimblewimble is the argument for storing the unspent set, not the autobiography of every coin.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.