Bitcoin PIPEs v2 is a cryptographic primitive. It is a path forward for expanding what Bitcoin can enforce without changing Bitcoin consensus. Using witness encryption, PIPEs make control of a Bitcoin signing key conditional on satisfying an arbitrary computational statement — enabling binary covenants, non-interactive zero-knowledge proofs, programmable security vaults, and Bitcoin metaprotocols. No soft forks, no trusted operators, and no separate consensus.
This post introduces the core idea behind Bitcoin PIPEs v2: moving spending conditions out of Bitcoin Script and into cryptography. We cover the move from functional encryption to witness encryption, binary covenants, non-interactive ZKPs, programmable security vaults, and metaprotocols, along with the security and setup assumptions that remain active areas of research.
Bitcoin’s intentionally constrained scripting environment is one of its defining properties, but it also limits the spending conditions that can be expressed directly in Script. Covenants, arbitrary ZK-proof verification, and conditions based on external protocol state have therefore motivated proposals such as OP_CAT, OP_CTV, OP_CSFS, and OP_VAULT, all of which require changes to Bitcoin consensus.
Bitcoin PIPEs v2 explores a complementary approach: rather than expanding what Bitcoin Script can evaluate, can we expand what Bitcoin can enforce through cryptography?
The core mechanism is cryptographically conditional signing-key release. A Bitcoin private key is encrypted under an NP statement using witness encryption. Provide a valid witness—such as a ZK proof—and the key can be recovered and used to produce an ordinary Schnorr signature. Bitcoin itself does not execute the underlying computation or understand the condition; miners and nodes ultimately verify a standard Bitcoin transaction under existing consensus rules.
This creates a useful separation: a protocol defines what must be true, a proof can establish that it is true, PIPEs control whether the signing capability becomes available, and Bitcoin verifies and settles the resulting spend.
At a high level, a PIPE encrypts a Bitcoin signing key under a computational statement. BTC can be sent normally to the corresponding public key, while the private key remains inaccessible until the required condition is satisfied.
Once a valid witness is produced, the signing key can be decrypted and used to authorize the spend. To Bitcoin, nothing unusual has happened: nodes simply verify a Schnorr signature under the public key to which the BTC was originally sent.
This is the basic inversion behind PIPEs: instead of asking Bitcoin to evaluate a new condition, put the condition behind the ability to produce the signature.
Witness encryption allows information to be encrypted to a statement rather than a public key. Anyone possessing a valid witness demonstrating that the statement is true can decrypt the ciphertext.
PIPEs apply this primitive to Bitcoin signing keys. For example, the statement might require that a particular ZK proof verifies. A valid proof makes the key recoverable; without it, the key remains inaccessible. This turns arbitrary NP predicates into potential Bitcoin authorization conditions without requiring Bitcoin Script to implement those predicates.
The current PIPEs research uses Arithmetic Affine Determinant Programs (AADPs) as a candidate witness encryption construction. AADPs operate directly over arithmetic constraints, making them substantially better suited to arithmetic-heavy operations such as SNARK verification than earlier Boolean ADP approaches.
PIPEs v1 explored functional encryption as a way of enforcing spending conditions. The attraction was persistent enforcement: the cryptographic mechanism could evaluate a policy and produce signatures without revealing the underlying private key. In practice, efficiently computing Schnorr signatures inside these constructions proved difficult.
PIPEs v2 makes a different tradeoff. Rather than computing a signature inside the encrypted mechanism, witness encryption protects the signing key and releases it when the required witness exists. This is simpler and better aligned with existing Bitcoin primitives, but means PIPEs v2 provide witness-gated key release rather than persistent per-signature enforcement.