From: "'Misha Komarov' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Bitcoin PIPEs v2. Overview and feedback request.
Date: Mon, 23 Feb 2026 11:25:41 -0800 (PST) [thread overview]
Message-ID: <fcf7d14c-6860-4493-80d5-9959d3760cd1n@googlegroups.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 5644 bytes --]
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 <https://arxiv.org/abs/1308.1536> ), 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.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/fcf7d14c-6860-4493-80d5-9959d3760cd1n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 7144 bytes --]
reply other threads:[~2026-02-23 19:29 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fcf7d14c-6860-4493-80d5-9959d3760cd1n@googlegroups.com \
--to=bitcoindev@googlegroups.com \
--cc=nemo@allocinit.xyz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox