From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 23 Feb 2026 11:29:19 -0800 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vubcM-0003nl-Im for bitcoindev@gnusha.org; Mon, 23 Feb 2026 11:29:19 -0800 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-40edeb2e7fdsf53711911fac.3 for ; Mon, 23 Feb 2026 11:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1771874952; x=1772479752; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:message-id:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=Tl1ouqLWhA+mxFB+9+eB4N+RDi4Xa4GHTAraLOjJD9k=; b=a187rnLGNJT1VRUbxNbmuXrMzgRJZfNRQSFZU8rP3jZpyH2GAxhlF6OgvFdhIxaYnT iIicxVXTf8dcGJ/KahRIVCbM+DNQQS4tS6jzwl/EqIycW6izAkuZYuyhPE46zht1xOJ3 CNzlUaoUQf30nsqQuqKYvexW4Go/s1llRmcESJoHVsscwyE6dcXaWRCkpfk61SNr60sO AGX9epROyuhv3BqIJDRjGP8JSL5oTunt9CYBD6fdgon3oYNIk9nxZJgPFFEnR07t/uGY 6cOH/VlmhMkkQcGKvJe6V8BMNNvsiOQbZAaUxpibs+OVBKo2LO7MJhtHM35BlOVLK6uP ZwUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771874952; x=1772479752; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:message-id:to:from:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Tl1ouqLWhA+mxFB+9+eB4N+RDi4Xa4GHTAraLOjJD9k=; b=D2EMj1R3p7+4cCmR/urs/bEqw+UB8kNergsElIOUW7XNyheDLopT5zrGK0SoLGeSxH vZJfzkC5JqxOUbkRUR4WIFxtLcBp/4hB8oDEcQEatCdG+ZxLptKhk8/yo7rqn5isZtUf F60dOvcUOWMY/dgShW5a50dAdUdS/SrXNYFUKu465aN+K9T3ZaSEOfgf0rKtcsHo7eLz F6xqFq3AdyXEicdJS9ZZAM0tVKGRqJG4vJF1QuAizvLA3ZpYXXmXiwOaQ93cLr6fdBpv Qv91tY/zzP3NGJem5x20nl1sYxEtK4q+sRwrklYRTbDp3BQRQma5PWqcZ2GBIQUu74nu lp1Q== X-Forwarded-Encrypted: i=1; AJvYcCVgGxXtSTPVrrpdZuyO3xvM6GmtTqQAXo4eATW7jfjgXcyI9lMxXkr3kopS1jDstsCKqfYAU3U+5wRn@gnusha.org X-Gm-Message-State: AOJu0Yxc0Bfpl9Gusg7XQpAtYIGD/w+mF+aKV6rMyT1iLyxxNTe+mvZq 5lph8ZWfU0KBO4hVpLXu3x++x2Lq6zAiMfPISqwTxTSUiwAlKgiSd7mM X-Received: by 2002:a05:6871:154:b0:3fa:aa1:5b1c with SMTP id 586e51a60fabf-4157b0c874fmr5986277fac.30.1771874952515; Mon, 23 Feb 2026 11:29:12 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+ED4rdyVAAGReliAgBa/FvpFilsblIDPlsTJ9ne4jnpuw==" Received: by 2002:a05:6870:d153:b0:40e:e4dd:d0b0 with SMTP id 586e51a60fabf-40ee4ddd79fls6326613fac.1.-pod-prod-06-us; Mon, 23 Feb 2026 11:29:08 -0800 (PST) X-Received: by 2002:a05:6808:4fc7:b0:45e:d128:168d with SMTP id 5614622812f47-464463aeddemr4817309b6e.57.1771874948126; Mon, 23 Feb 2026 11:29:08 -0800 (PST) Received: by 2002:a05:690c:450f:b0:797:d142:b0fa with SMTP id 00721157ae682-797d142c176ms7b3; Mon, 23 Feb 2026 11:25:42 -0800 (PST) X-Received: by 2002:a05:690c:dc6:b0:798:3a6:3f4 with SMTP id 00721157ae682-7982902a4d6mr89728617b3.43.1771874741624; Mon, 23 Feb 2026 11:25:41 -0800 (PST) Date: Mon, 23 Feb 2026 11:25:41 -0800 (PST) From: "'Misha Komarov' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: Subject: [bitcoindev] Bitcoin PIPEs v2. Overview and feedback request. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_448064_1580534764.1771874741204" X-Original-Sender: nemo@allocinit.xyz X-Original-From: Misha Komarov Reply-To: Misha Komarov Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) ------=_Part_448064_1580534764.1771874741204 Content-Type: multipart/alternative; boundary="----=_Part_448065_441366572.1771874741204" ------=_Part_448065_441366572.1771874741204 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Heya list, We recently published Bitcoin PIPEs v2 ( https://x.com/alloc_init_/status/2019411470232989918?s=3D20)(or an IACR lin= k=20 if anybody is interested: https://eprint.iacr.org/2026/186). TL;DR: Bitcoin PIPEs v2 is an approach to induce covenants (by emulating=20 missing opcodes) and pessimistic, single-transaction ZKPs verification on= =20 Bitcoin L1 without a softfork. The way it works is a DKG committee=20 generates a key nobody knows (under 1-of-n assumption), issues a ciphertext= =20 which unlocks the private key only upon the successful verification of a=20 ZKP. The existence of a transaction signed with a released private key is= =20 effectively attesting the successful verification of a ZKP to the Bitcoin= =20 L1. We=E2=80=99ve shifted from the Functional Encryption-based PIPEs v1 des= ign ( https://x.com/nemothenoone/status/1843382870901235907?s=3D20) to an AADP=20 Witness Encryption-based v2 design ( https://x.com/nemothenoone/status/2019431538207948812?s=3D20). This allowed= =20 us to move from =E2=80=9CWe can potentially run this in the future=E2=80=9D= to =E2=80=9CWe can run=20 this for every block (~10 minutes), provided enough storage.=E2=80=9D The c= ost is=20 that each ciphertext currently requires approximately 330 TB of storage,=20 though it is known how to decrease this number to around 100 GB in the near= =20 future. This approach still supports so-called =E2=80=9Cpre-covenants=E2=80= =9D. There is also some discussion on Delving Bitcoin:=20 https://delvingbitcoin.org/t/bitcoin-pipes-v2/2249. The point of this email is to: 1. *Revisit and potentially consolidate certain BIP proposals.* Several= =20 BIPs propose new opcodes that many would like to see in Bitcoin Script= =20 (e.g., OP_CTV, OP_VAULT, OP_CAT). However, given the lack of broad=20 consensus around these changes, PIPEs v2 may offer a way to deprecate or= =20 supersede proposals such as the OP_CSFS BIP and vault-related BIPs=20 (including alternatives that aim to replicate vault functionality). We= =20 would also like to explore which other proposals could reasonably be=20 deprecated or streamlined through this approach. 2. *Clarify what improvements this enables =E2=80=94 and how.* We would = like to=20 better understand which systems could benefit from this design (e.g.,=20 BitVM, Lightning liquidity efficiency, private transaction constructions= =20 such as shielded CSV-style designs), and in what ways. For example, it= =20 appears that BitVM can be improved via OP_VAULT-style emulation under th= is=20 framework. 3. Gather feedback in general. So, which covenants can PIPEs emulate? PIPEs v2 enforces binary covenants =E2=80=94 i.e., whether funds are author= ized to=20 be spent or not =E2=80=94 by gating key recovery on an NP condition. It doe= s not=20 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=20 eligibility condition is proven (thus BitVM get stripped from its=20 interactivity properties and operators liquidity requirements, Lightning= =20 channel liquidity fragmentation can be reduced). - *Exit and Escape Conditions:* Off-chain protocol exits or rescue paths= =20 unlocked upon proof. - *ZKPs:* Zero-knowledge proofs attesting to the correctness of=20 statements can gate spendability. - *Optimistic Protocol Finalization*: PIPEs allow such finalization=20 conditions to be enforced non-interactively; the existence of a valid pr= oof=20 directly unlocks funds, without on-chain disputes or timing assumptions. - What else? *Practicality & Performance* Witness Encryption is often characterized as impractical. However, recent= =20 advances suggest that PIPEs v2 based on AADP WE ( https://eprint.iacr.org/2026/175) may be both practical and economically=20 feasible. In our estimates, the scheme can be computed within Bitcoin=E2=80= =99s 10=20 minute block interval given parallelization and ongoing efficiency=20 improvements. Computationally, the dominant cost arises from determinant computation. If= =20 properly parallelized (e.g., following the approach in [1308.1536] A=20 Parallel Algorithm for Calculation of Large Determinants with High Accuracy= =20 for GPUs and MPI clusters ), the=20 determinant can be computed within approximately one Bitcoin L1 block=20 interval (~10 minutes) using 48 CPU machines, each equipped with 256 CPU=20 cores and approximately 7 TB of storage. Memory requirements are=20 comparatively modest and do not constitute a primary bottleneck. At current cloud services pricing, renting such infrastructure amounts to= =20 approximately $100-200 per covenant execution, plus a negligible on-chain= =20 cost for signature verification. This makes the approach economically=20 viable for near=E2=80=93real-time covenant emulation. Moreover, these execu= tion=20 costs can likely be further reduced (e.g. the ciphertext can theoretically= =20 be shrank to ~100 GB) through batching and more circuit reduction. We invite BIP authors and Bitcoin contributors to help us evaluate where=20 PIPEs v2 may reduce complexity, improve efficiency, or offer alternative=20 design paths. If your proposal could benefit from this direction, we value= =20 your feedback. --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= fcf7d14c-6860-4493-80d5-9959d3760cd1n%40googlegroups.com. ------=_Part_448065_441366572.1771874741204 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Heya list,

=

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

TL;DR: Bitcoin PIPEs v= 2 is an approach to induce covenants (by emulating missing opcodes) and pes= simistic, single-transaction ZKPs verification on Bitcoin L1 without a soft= fork. The way it works is a DKG committee generates a key nobody knows (und= er 1-of-n assumption), issues a ciphertext which unlocks the private key on= ly upon the successful verification of a ZKP. The existence of a transactio= n signed with a released private key is effectively attesting the successfu= l verification of a ZKP to the Bitcoin L1. We=E2=80=99ve shifted from the F= unctional Encryption-based PIPEs v1 design (https://x.com/nemothenoone/status= /1843382870901235907?s=3D20) to an AADP Witness Encryption-based v2 des= ign (https://x.com/nemothenoone/status/2019431538207948812?s=3D20). This = allowed us to move from =E2=80=9CWe can potentially run this in the future= =E2=80=9D to =E2=80=9CWe can run this for every block (~10 minutes), provid= ed enough storage.=E2=80=9D The cost is that each ciphertext currently requ= ires approximately 330 TB of storage, though it is known how to decrease th= is number to around 100 GB in the near future. This approach still supports= so-called =E2=80=9Cpre-covenants=E2=80=9D.

There is also some discussion on Delving B= itcoin:=C2=A0https://delvingbitcoin.org/t/bitcoin-pipes-v2/2249.

The point of this email is to= :

  1. Revisit and potentially consolidate certain BIP proposals.=C2= =A0Several BIPs propose new opcodes that many would like to see in Bitcoin = Script (e.g.,=C2=A0OP_CTV,=C2=A0OP_VAULT,=C2=A0OP_CAT). However, given the = lack of broad consensus around these changes, PIPEs v2 may offer a way to d= eprecate or supersede proposals such as the=C2=A0OP_CSFS=C2=A0BIP and vault= -related BIPs (including alternatives that aim to replicate vault functiona= lity). We would also like to explore which other proposals could reasonably= be deprecated or streamlined through this approach.
  2. Clarif= y what improvements this enables =E2=80=94 and how.=C2=A0We 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 app= ears that BitVM can be improved via=C2=A0OP_VAULT-style emulation under thi= s framework.
  3. Gather feedback in general.

So, which covenants can PIPEs e= mulate?

PIP= Es v2 enforces binary covenants =E2=80=94 i.e., whether funds are authorize= d to be spent or not =E2=80=94 by gating key recovery on an NP condition. I= t does not constrain transaction format or outputs once the private key is = released.

U= se cases aligning with binary authorization include:

  • Vaults:=C2= =A0Funds unlock only when a beneficiary, recovery, or eligibility condition= is proven (thus BitVM get stripped from its interactivity properties and o= perators liquidity requirements, Lightning channel liquidity fragmentation = can be reduced).
  • Exit and Escape Conditions:=C2=A0= Off-chain protocol exits or rescue paths unlocked upon proof.
  • ZKPs:=C2=A0Zero-knowledge proofs attesting to the correctness o= f statements can gate spendability.
  • Optimistic Protocol Fin= alization: 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?

    • Prac= ticality & Performance

    Witness Encryption is often characterized as impra= ctical. 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, th= e scheme can be computed within Bitcoin=E2=80=99s 10 minute block interval = given parallelization and ongoing efficiency improvements.

    Computationally, the domina= nt cost arises from determinant computation. If properly parallelized (e.g.= , following the approach in=C2=A0[1308.1536] A Parallel Algorithm for Calculation of Large Determinants wi= th High Accuracy for GPUs and MPI clusters=C2=A0), 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 c= onstitute a primary bottleneck.

    At current cloud services pricing, renting such infras= tructure amounts to approximately $100-200 per covenant execution, plus a n= egligible on-chain cost for signature verification. This makes the approach= economically viable for near=E2=80=93real-time covenant emulation. Moreove= r, 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 PI= PEs v2 may reduce complexity, improve efficiency, or offer alternative desi= gn 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 &= quot;Bitcoin Development Mailing List" group.
    To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
    To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/fcf7d14c-6860-4493-80d5-9959d3760cd1n%40googlegroups.com.
    ------=_Part_448065_441366572.1771874741204-- ------=_Part_448064_1580534764.1771874741204--