Episode notes
Bitcoin soft-fork debates around CTV, CSFS, OP_CAT, and OP_VAULT keep stalling — and Misha Komarov of Allocinit argues you can emulate much of that covenant behavior with cryptography instead of changing consensus.
Misha joins Stephan to unpack Bitcoin PIPEs v2: a Witness Encryption design that locks a signing key under an NP statement so a valid zero-knowledge proof decrypts the key and produces an ordinary Schnorr spend. Bitcoin L1 only checks a normal signature.
They compare PIPEs v1 (Functional Encryption / richer post-covenants) with v2 (Witness Encryption / binary pre-covenants), ciphertext sizes from ~300 TB toward single-digit terabytes, DKG and 1-of-n setup assumptions, non-custodial vault and shared-pool use cases, contrasts with cosigner models like Sigbash, and how Allocinit’s Shielded Bitcoin design differs from Shielded CSV’s client-side validation approach — plus open cryptanalysis challenges and a path toward implementable code.
Timestamps:
00:00 — Intro: Misha & Bitcoin PIPEs v2
00:27 — Background: BitMessage to =nil;
01:31 — Soft-Fork Fatigue & Nice-to-Haves
03:24 — Emulate Opcodes Without Soft Forks
04:54 — Witness Encryption Unlocks Keys
06:01 — Witness Encryption vs Bitcoin Witness
09:00 — PIPEs v1 vs v2: FE to WE
11:39 — Ciphertext Size & Cost Trade-offs
15:28 — Vaults as the Unhappy Path
16:23 — PIPEs vs Sigbash Cosigner
18:05 — DKG Setup & 1-of-n Trust
21:11 — Shared Vaults & Lending Use Cases
23:24 — Beyond Canonical OP_VAULT
26:35 — Shielded Bitcoin vs Shielded CSV
32:17 — Self-Custody Peg-In and Peg-Out
37:14 — On-Chain Footprint Walkthrough
39:42 — Security Challenges & Code Roadmap
Links:
https://x.com/allocinitxyz
Stephan Livera links:
Follow me on X: @stephanlivera
