Skip to content

LibraryPrivacy2018Design paperCorpus record

Bulletproofs: Short Proofs for Confidential Transactions and More

Bulletproofs. Benedikt Bünz, Jonathan Bootle, Dan Boneh, Andrew Poelstra, Pieter Wuille and Greg Maxwell.

Range proofs whose size grows logarithmically, with no trusted setup. They made confidential amounts practical to verify. They are not, by themselves, a private payment system.

Bulletproofs are short range proofs with no trusted setup. Size grows with the logarithm of the range's bit length, and several proofs can be aggregated. They do not hide who paid whom.

The five-minute read

The setup is the absence

Groth16 needs a ceremony per circuit. Bulletproofs use an inner-product argument that does not. Losing a trapdoor is not the failure mode. A bug in the argument still is.

Logarithmic size

A 64-bit range does not need a proof that lists every bit in the clear. The prover sends a short transcript. Verification does more work than a pairing check of a Groth16 proof.

Aggregation is the deployment reason

A transaction with many outputs can fold their range proofs. Monero's later adoption is about that saving. The proof system does not become a ring signature by being aggregated.

Statement, not brand

A Bulletproof proves the circuit you built, usually a range. It does not prove reserves, solvency, or a program unless someone encoded that statement and you check the encoding.

One action, walked through

  1. The prover holds a committed value and wants to show it lies in a range without opening it.
  2. The constraint is written as an inner-product relation.
  3. The prover and the verifier, or a Fiat-Shamir transcript, run the inner-product argument.
  4. The verifier accepts or rejects a logarithmic-size proof.
  5. If several values are batched, one transcript covers the vector of them.

The argument, unpacked

No setup is not free verification

The paper spends prover and verifier time to avoid a ceremony and to shrink the bytes. A system that needs millions of verifications per second may still prefer a setup-based SNARK. That is an engineering choice the paper makes visible.

Aggregation changes who must be online

Batching proofs across outputs is a normal use. Batching across users introduces a coordination problem the cryptography does not solve.

What has to be true

  • The discrete-log assumptions used by the inner-product argument hold in the chosen group.
  • Fiat-Shamir, if used, is bound to the right transcript. A reusable challenge breaks soundness.
  • The commitment scheme the range is proved against is the one the ledger checks. A proof about a different commitment is irrelevant.
  • Implementations do not reuse nonces. That failure mode sits outside the paper and inside every deployment.

What happened after the paper

Monero switched its confidential amounts to Bulletproofs and later to a smaller variant. Other chains use the same argument inside larger transparent proofs. Halo then studied recursion over this family. The 2018 paper is the citation for setup-free logarithmic range proofs, not for a currency.

What to check before you use the idea

  • Is there a trusted setup for this proof or not?
  • What statement is encoded: a range, a circuit, or something broader?
  • Are proofs aggregated, and across whose outputs?
  • Is verification cost acceptable on the intended chain?

Terms

Inner-product argument
A short proof that two committed vectors have a claimed inner product, without revealing the vectors.
Aggregation
One proof covering many range statements, so the size does not grow in proportion to the count.

The problem the paper names

A confidential transaction needs a proof that a committed value sits in a range. Older proofs were large. Bulletproofs compress that proof, and can aggregate several ranges.

What the design proposes

  • An inner-product argument replaces a linear-sized circuit proof.
  • No structured reference string. The setup toxic waste of Groth16 is not here.
  • A single proof can cover many outputs, which is how Monero later batched them.

How the mechanism is specified

  • The prover convinces a verifier that a committed vector satisfies an inner-product relation, without sending the vector.
  • Verification cost is higher than a SNARK of the same statement. The saving is size and the missing setup.
  • The proof hides the amount. The surrounding transaction still decides whether the sender is hidden.

What this page does not treat as proven

  • A Bulletproof does not prove a program, a solvency claim, or a reserve. It proves the statement that was encoded.
  • Aggregation changes verification scheduling. It does not change the trust model into a setup-free SNARK for arbitrary circuits. That is a different paper.
  • Later transparent SNARKs are not this construction. Do not swap the names.

Why a venture studio still reads it

Ask what statement is being proved, and whether there was a setup. Bulletproofs are the reference for the setup-free range proof, not a synonym for zero knowledge.

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.