Zero knowledge on bitcoin: proofs and shielded transfers

Wonder

1. How can encrypted value move on a public chain without changing the consensus rules?
2. What does a nullifier reveal about a spent note, and what does it hide?
3. Why would a protocol rely on an indexer rather than full nodes to validate its core state?

Explore

Part IShielded Bitcoin: private transfers without a soft fork

1. Clara Shikhelman, Mikhail Komarov, and Aleksei Moskvin published ‘Shielded Bitcoin’ on September 24, 2026. The 56-page paper proposes a design that borrows the architecture of Zcash’s Sapling and Orchard pools for use on Bitcoin. Value is held as encrypted notes rather than standard UTXOs. Spending a note reveals a nullifier to prevent double-spending, but this identifier does not link back to the specific note or its original source.
2. Each transfer consists of an ordinary Bitcoin transaction carrying one OP_RETURN output. This output contains an envelope holding a Groth16 zero-knowledge proof, approximately 192 bytes in size. The proof demonstrates that the transfer is valid and balances without exposing the underlying data. A standard two-input, two-output envelope occupies about 610 bytes, and the OP_RETURN output about 625 vB. Bitcoin consensus rules ignore this data entirely; it is treated as unspendable payload.
3. Because full nodes do not validate the OP_RETURN contents, indexers must replay these envelopes in block order to reconstruct the note tree, nullifier set, and Merkle roots. If an invalid transfer appears in a block, indexers simply ignore it rather than rejecting the block. This shifts verification from full nodes to indexer software. A dishonest indexer can serve stale or incomplete state but cannot take funds, and anyone can run their own.
4. The design hides amounts, senders, receivers, and graph positions from chain analysis. However, timing, fees, carrier structure, and input/output counts remain visible on-chain. Relay of these transactions depends on Bitcoin Core v30’s larger default data-carrier limit, a policy change rather than a consensus upgrade. If many operators set stricter limits, such transactions would be harder to relay, though miners willing to accept them could still include them.
5. The paper explicitly leaves peg-in and peg-out mechanisms out of scope for this initial design. The authors plan to build these components on Bitcoin PIPEs v2, using witness encryption to lock private keys behind cryptographic statements. This approach allows programmability through existing Schnorr signatures rather than new opcodes. Currently, the project has no implementation, users, or funds in circulation; it remains a theoretical specification.
6. The design has known limits. Groth16 needs a one-time trusted setup, safe if at least one ceremony participant was honest. A new pool starts with an anonymity set of zero, so early users are easier to tell apart. A transfer is reported at around 700 vB, several times an ordinary payment. The proofs rest on elliptic curves that a large quantum computer could break. And until indexers can prove their state cheaply, light wallets must trust the indexer they query, though it cannot take their funds.

Part IIZero-knowledge proofs on Bitcoin today

7. Bitcoin Script was designed for simplicity and security, limiting its ability to execute arbitrary code. A standard zero-knowledge proof, such as a Groth16 SNARK, requires pairing-based elliptic curve arithmetic that Bitcoin’s current opcode set cannot perform at reasonable cost. This computational gap means the network itself cannot natively verify these proofs without a soft fork or significant resource expenditure per transaction.
8. BitVM-style protocols solve this through optimistic verification. Instead of checking every proof immediately, they assume correctness and only trigger expensive verification if a dispute arises. If no one challenges the state transition within a set period, it is accepted as valid. Security rests on incentives: operators post collateral they lose if they cheat, and anyone watching can challenge.
9. Citrea’s Clementine bridge reached mainnet in January 2026 using this BitVM2 architecture. Its dispute path verifies a Groth16 proof with a Script verifier of about 1 GB (down from early estimates near 3 GB), split into chunks that run only when a challenge is filed. This design allows complex state transitions to be secured by Bitcoin under a one-honest-party assumption, without requiring every full node to run the heavy cryptographic checks for routine transactions.
10. Alpen’s Glock project demonstrated an alternative approach using garbled circuits, reaching a signet testnet in July 2026. Glock uses garbled circuits to make verifying a proof during a dispute far cheaper on-chain. It is still dispute-based but with a far smaller on-chain footprint, and both approaches acknowledge that native Script verification of advanced cryptography remains prohibitively expensive for general use.
11. Client-side validation offers another path where proofs are checked by users or indexers rather than the base layer. Protocols like RGB and Taproot Assets rely on participants to verify ownership proofs locally. Similarly, Shielded Bitcoin designs involve indexers replaying transaction envelopes to rebuild note trees, with invalid transfers ignored by consensus but detectable by monitoring software that runs the full verification logic outside the node.
12. These systems carry specific trade-offs. Groth16 requires a trusted setup, where a ceremony must ensure no one retains toxic secrets that could invalidate proofs. Dispute transactions in optimistic systems are large and complex, creating relay challenges. Furthermore, the pairing-friendly curves behind Groth16, like Bitcoin’s own secp256k1, are vulnerable to a large quantum computer, so a quantum computer could forge proofs and break ECDH-based note encryption, though Groth16 proofs themselves reveal no secrets.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• Shikhelman, Komarov & Moskvin, 'Shielded Bitcoin' ([alloc] init, September 24, 2026)
• D. Hopwood et al., Zcash Protocol Specification (Sapling and Orchard)
• Bitcoin Core v30 release notes
• news.bitcoin.com coverage of Shielded Bitcoin (2026)
• R. Linus et al., 'BitVM2: Bridging Bitcoin to Second Layers' (2024)
• Citrea documentation and mainnet announcement (2026)
• Alpen, 'Glock is here' (July 2026)