Bitcoin PIPEs v2. Overview and feedback request.

[Misha Komarov]

Heya list,

We recently published Bitcoin PIPEs v2 (https://x.com/alloc_init_/status/2019411470232989918?s=20)(or an IACR link if anybody is interested: https://eprint.iacr.org/2026/186).

TL;DR: Bitcoin PIPEs v2 is an approach to induce covenants (by emulating missing opcodes) and pessimistic, single-transaction ZKPs verification on Bitcoin L1 without a softfork. The way it works is a DKG committee generates a key nobody knows (under 1-of-n assumption), issues a ciphertext which unlocks the private key only upon the successful verification of a ZKP. The existence of a transaction signed with a released private key is effectively attesting the successful verification of a ZKP to the Bitcoin L1. We’ve shifted from the Functional Encryption-based PIPEs v1 design (https://x.com/nemothenoone/status/1843382870901235907?s=20) to an AADP Witness Encryption-based v2 design (https://x.com/nemothenoone/status/2019431538207948812?s=20). This allowed us to move from “We can potentially run this in the future” to “We can run this for every block (~10 minutes), provided enough storage.” The cost is that each ciphertext currently requires approximately 330 TB of storage, though it is known how to decrease this number to around 100 GB in the near future. This approach still supports so-called “pre-covenants”.

There is also some discussion on Delving Bitcoin: https://delvingbitcoin.org/t/bitcoin-pipes-v2/2249.

The point of this email is to:

1. Revisit and potentially consolidate certain BIP proposals. Several BIPs propose new opcodes that many would like to see in Bitcoin Script (e.g., OP_CTV, OP_VAULT, OP_CAT). However, given the lack of broad consensus around these changes, PIPEs v2 may offer a way to deprecate or supersede proposals such as the OP_CSFS BIP and vault-related BIPs (including alternatives that aim to replicate vault functionality). We would also like to explore which other proposals could reasonably be deprecated or streamlined through this approach.
2. Clarify what improvements this enables — and how. We would like to better understand which systems could benefit from this design (e.g., BitVM, Lightning liquidity efficiency, private transaction constructions such as shielded CSV-style designs), and in what ways. For example, it appears that BitVM can be improved via OP_VAULT-style emulation under this framework.
3. Gather feedback in general.

So, which covenants can PIPEs emulate?

PIPEs v2 enforces binary covenants — i.e., whether funds are authorized to be spent or not — by gating key recovery on an NP condition. It does not constrain transaction format or outputs once the private key is released.

Use cases aligning with binary authorization include:

• Vaults: Funds unlock only when a beneficiary, recovery, or eligibility condition is proven (thus BitVM get stripped from its interactivity properties and operators liquidity requirements, Lightning channel liquidity fragmentation can be reduced).
• Exit and Escape Conditions: Off-chain protocol exits or rescue paths unlocked upon proof.
• ZKPs: Zero-knowledge proofs attesting to the correctness of statements can gate spendability.
• Optimistic Protocol Finalization: PIPEs allow such finalization conditions to be enforced non-interactively; the existence of a valid proof directly unlocks funds, without on-chain disputes or timing assumptions.
• What else?

Practicality & Performance

Witness Encryption is often characterized as impractical. However, recent advances suggest that PIPEs v2 based on AADP WE (https://eprint.iacr.org/2026/175) may be both practical and economically feasible. In our estimates, the scheme can be computed within Bitcoin’s 10 minute block interval given parallelization and ongoing efficiency improvements.

Computationally, the dominant cost arises from determinant computation. If properly parallelized (e.g., following the approach in [1308.1536] A Parallel Algorithm for Calculation of Large Determinants with High Accuracy for GPUs and MPI clusters ), the determinant can be computed within approximately one Bitcoin L1 block interval (~10 minutes) using 48 CPU machines, each equipped with 256 CPU cores and approximately 7 TB of storage. Memory requirements are comparatively modest and do not constitute a primary bottleneck.

At current cloud services pricing, renting such infrastructure amounts to approximately $100-200 per covenant execution, plus a negligible on-chain cost for signature verification. This makes the approach economically viable for near–real-time covenant emulation. Moreover, these execution costs can likely be further reduced (e.g. the ciphertext can theoretically be shrank to ~100 GB) through batching and more circuit reduction.

We invite BIP authors and Bitcoin contributors to help us evaluate where PIPEs v2 may reduce complexity, improve efficiency, or offer alternative design paths. If your proposal could benefit from this direction, we value your feedback.