The cryptographic frontier: witness encryption and PIPEs

Wonder

1. Why can Bitcoin verify a signature but not restrict where the resulting coin goes next?
2. What does it cost to prove you know a secret without revealing the secret itself?
3. How do protocols maintain security when the underlying rules remain static and unchangeable?

Explore

Part IThe cryptographic frontier: covenants and witness encryption

1. Bitcoin Script is deliberately limited. It can verify that a signature matches a public key, but it cannot inspect the destination of coins once spent. The restriction keeps Script simple and predictable. However, it also blocks certain designs where spending conditions depend on future transaction structures.
2. Jeremy Rubin’s proposal for OP_CHECKTEMPLATEVERIFY (BIP-119) addresses this gap. The opcode would allow a script to require that the spending transaction match a committed template, fixing its outputs and certain other fields. This enables non-recursive covenants: rules about where coins can go next, such as locking funds into vaults or restricting redemption paths. It remains unactivated and subject to ongoing debate in the Bitcoin community.
3. A separate proposal, OP_CAT (BIP-347), focuses on concatenating data on the stack rather than imposing destination constraints directly, though combined with Schnorr signatures it can also enable covenants. This simple operation enables complex cryptographic constructions, including tree signatures that express very large multisignature policies compactly. It also facilitates post-quantum resistant Lamport signatures by allowing hashes and values to be manipulated directly within the script engine.
4. Beyond new opcodes, research explores witness encryption as an alternative path to programmability. Witness encryption allows a sender to lock data so that only someone who can prove possession of a specific secret (a witness) can unlock it. This could theoretically allow bitcoin keys to be revealed only upon proof of a statement, without requiring the network to verify the computation directly.
5. Early constructions of witness encryption exist in academic literature but remain impractical for Bitcoin deployment. No practical construction for general statements exists yet: known schemes are enormous and rest on cryptographic assumptions that are not yet widely trusted. While the theoretical foundations are sound, the engineering gap between a proof-of-concept and a production-ready protocol remains substantial.
6. The trade-off is clear: covenants add expressiveness but introduce new consensus rules requiring careful review; witness encryption adds privacy and flexibility but imposes heavy storage and computation costs. Both approaches seek to extend Bitcoin’s capabilities without abandoning its core security model of fixed, predictable issuance and limited scripting power.

Part IIGetting bitcoin in and out: PIPEs and witness encryption

7. Shielded Bitcoin, detailed in the previous lesson, handles private transfers within its own note system. It leaves peg-in and peg-out out of scope: how to move value from ordinary, transparent Bitcoin into the shielded layer, and back again. The design plan for these bridges relies on a mechanism called witness encryption, specifically Bitcoin PIPEs v2 (IACR ePrint 2026/186, February 2026).
8. Witness encryption locks data behind a mathematical statement. In this context, a Bitcoin private key is encrypted such that it can only be decrypted if someone presents a valid witness—a proof that the statement is true. The ciphertext is published off-chain, and the key inside stays inaccessible to anyone who cannot produce the corresponding witness.
9. The mechanism shifts programmability from consensus to cryptography. Instead of requiring new opcodes or soft forks to enforce complex spending conditions, the logic lives entirely within the encryption scheme. Whoever presents a valid witness, such as a SNARK proof, recovers the private key and spends the coins using an ordinary Schnorr signature. To Bitcoin’s consensus rules, this is just a standard transaction; the complexity is invisible.
10. This approach can emulate covenant-style restrictions, such as CheckTemplateVerify or vault mechanisms, without altering the protocol. The conditions are enforced by the inability to decrypt the key unless specific criteria are met in the witness. It offers a path to advanced spending conditions that remain compatible with Bitcoin’s existing validation rules, provided the underlying cryptography holds.
11. The primary obstacle is scale. The February 2026 paper estimated each ciphertext at about 338 terabytes; later work by the authors claims about 10 terabytes, still impractical to store and distribute. No implementation exists, so these are estimates, and whether PIPEs can be deployed at all remains an open research question.
12. This remains a research phase, not an implemented feature. There are no dates for deployment, and the conflicting size figures highlight the uncertainty of the field. Until ciphertexts shrink sufficiently, witness encryption serves as a theoretical bridge between Bitcoin’s transparent ledger and complex cryptographic commitments, rather than a functional tool for users.

Key facts

Exercise nine, six, three, one

Fact check

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

• J. Rubin, BIP-119: OP_CHECKTEMPLATEVERIFY (2020)
• E. Heilman & A. Sabouri, BIP-347: OP_CAT in Tapscript (2024)
• S. Garg, C. Gentry, A. Sahai & B. Waters, 'Witness Encryption and its Applications' (STOC 2013)
• bitcoin-dev mailing list archives
• Abdalla, Carmer, El Gebali, Kilinc Alper, Komarov et al., 'Bitcoin PIPEs v2' (IACR ePrint 2026/186, February 2026)
• Shikhelman, Komarov & Moskvin, 'Shielded Bitcoin' ([alloc] init, September 2026)
• S. Garg et al., 'Witness Encryption and its Applications' (2013)