• No-Fork Covenants: Bitcoin’s Cryptographic Escape Hatch
  • The Political Context
  • 1. Binohash: FindAndDelete as Feature, Not Bug
    • What It Does
    • How It Works
    • Security Properties
    • The BitVM Connection
    • Limitations
  • 2. Bitcoin PIPEs V2: Witness Encryption Changes Everything
    • What It Does
    • How It Works
    • Concrete Construction
    • What It Enables
    • Limitations
  • 3. ColliderScript: The $50M Proof of Concept
    • What It Does
    • How It Works
    • Why It Matters (And Why It Doesn’t, Yet)
  • Comparison Matrix
  • The BIP-54 Question
  • What This Means for the Covenant Debate
    • The Strong Argument for “No Fork Needed”
    • The Strong Argument for “We Still Need CTV”
  • My Analysis
  • Connections
  • Sources

§No-Fork Covenants: Bitcoin’s Cryptographic Escape Hatch

What if we never needed a soft fork for covenants at all?

Three independent research efforts — Binohash, Bitcoin PIPEs V2, and ColliderScript — are demonstrating that covenant-like behavior can be achieved on Bitcoin today, using nothing but existing consensus rules. With CTV signaling starting in exactly one week (March 30, 2026), the question isn’t just academic anymore: do we even need to change Bitcoin’s consensus layer?

#bitcoin #covenants #scaling #privacy #research

§The Political Context

The covenant soft fork debate has consumed enormous political capital since 2021. CTV activation signaling starts March 30, 2026 — BIP9, bit 5, 90% threshold. Almost certainly it will fail in this window: only ~15-20% of hashrate has expressed support. The CTV+CSFS letter had 60+ developer signatories, but the activation client bundles CTV alone (not CSFS), leaving the strongest use case (LN-Symmetry) on the table.

Meanwhile, three research teams have been quietly building an alternative path.

§1. Binohash: FindAndDelete as Feature, Not Bug

Published: March 2026, Robin Linus ({ideal} team)
Status: Mainnet proof-of-concept transaction mined
Optech coverage: Newsletter #396

§What It Does

Binohash creates a collision-resistant hash of transaction data that is directly readable inside Bitcoin Script — a form of transaction introspection that Bitcoin’s designers never intended.

§How It Works

The core trick exploits FindAndDelete, a legacy quirk in OP_CHECKMULTISIG:

1. Nonce pool: The locking script embeds 120 small (9-byte) dummy signatures, crafted using the SIGHASH_SINGLE bug (input index ≥ number of outputs → deterministic z=1).

2. Subset selection: The spender selects 8 signatures from the pool. OP_CHECKMULTISIG’s FindAndDelete pass removes these from the scriptCode before computing the sighash — so different subsets produce different sighashes.

3. Puzzle grinding: The spender grinds until finding a subset where the resulting sighash allows creating a compact puzzle signature (verified by OP_SIZE). This is proof-of-work: ~2^42 operations per puzzle, costing <$50 on modern GPUs.

4. Two rounds: Repeat with a second independent nonce pool. The concatenated indices from both rounds form the Binohash digest.

5. One-time signing: The indices can be committed to using a HORS-like subset preimage scheme (more efficient than Lamport signatures in opcodes).

§Security Properties

The 84-bit collision resistance comes from the birthday bound: an attacker needs ~2^39.6 samples, each costing ~2^43.6 work (re-grinding both puzzles + pinning), totaling ~2^83.2 effort.

§The BitVM Connection

This is why Robin Linus built it. Binohash enables BitVM bridges without trusted light clients:

• Current BitVM bridges need oracles or light clients to verify on-chain transaction properties — introducing trust assumptions.
• With Binohash, the transaction digest is readable in-script and Lamport-signable, so BitVM’s off-chain VM can verify actual transaction data trustlessly.
• This potentially eliminates the existential honesty assumption for BitVM bridge safety.

For the BitVM ecosystem (Bitlayer $360M+ TVL, Citrea Clementine, GOAT Network), removing light client trust would be a significant security improvement.

§Limitations

• Legacy-only. Requires pre-SegWit transactions with FindAndDelete. Won’t work with Taproot/Schnorr.
• Non-standard. The ~8KB locking script violates standardness rules. Needs cooperative miners or custom generateblock RPC. Can’t propagate through normal mempool.
• Near opcode limits. 199 of 201 allowed non-push opcodes. Almost no room for additional logic.
• Fragile to consensus changes. If FindAndDelete behavior is ever modified or banned, the construction breaks.
• Below 128-bit security. 84 bits is adequate for many applications but not at modern cryptographic strength. Increasing it would exceed script/opcode limits.

§2. Bitcoin PIPEs V2: Witness Encryption Changes Everything

Published: February 5, 2026, [alloc] init team (ePrint 2026/186)
Status: Cryptographic construction, no mainnet deployment yet
Team: Michel Abdalla, Brent Carmer, Mikhail Komarov, and 6 others

§What It Does

PIPEs V2 uses witness encryption to enforce arbitrary spending conditions on Bitcoin without any consensus changes. The result: programmable covenants and SNARK-verifiable conditions, entirely within existing rules.

§How It Works

The fundamental primitive is the Witness Signature (WS):

1. A Bitcoin private key is encrypted under an NP statement using a witness encryption scheme.
2. The key can only be recovered by providing a valid witness (e.g., a SNARK proof) satisfying that statement.
3. Once unlocked, the mechanism produces a standard Schnorr signature — indistinguishable from any normal Bitcoin transaction.
4. From Bitcoin’s perspective, nothing unusual happened. The consensus layer sees an ordinary P2TR spend.

The key insight: enforcement happens at the cryptographic layer, not the consensus layer. The spending conditions are embedded in the key generation process, not in the script.

§Concrete Construction

PIPEs V2 explores Arithmetic Affine Determinant Programs (AADPs) as the witness encryption backend — an explicit arithmetic framework for enforcing SNARK-verifiable NP predicates within the PIPE architecture. This is the upgrade from V1, which used Polynomial Inner Product Encryption (FH-MIPE).

§What It Enables

• zkRollups on Bitcoin L1 — trustless state verification without fraud proofs
• Trustless bridges — no federation, no 1-of-N honesty assumption, no BitVM challenge-response
• Programmable vaults — arbitrary spending conditions, time locks, multisig policies
• SNARK verification — if OP_CAT could enable ZK verification, PIPEs V2 claims to do the same without touching consensus

§Limitations

• Exotic cryptography. Witness encryption based on AADPs is cutting-edge. The security assumptions are less battle-tested than standard ECDSA/Schnorr.
• No implementation yet. This is a cryptographic paper, not deployed software. The gap between theory and production is enormous.
• Computational cost unclear. The paper doesn’t provide concrete benchmarks for witness encryption operations. Likely expensive.
• New trust assumptions. Instead of trusting Bitcoin’s consensus rules (well-understood), you’re trusting novel cryptographic assumptions (less understood). The attack surface shifts, not disappears.

§3. ColliderScript: The $50M Proof of Concept

Published: November 2024, Ethan Heilman, Victor Kolobov, Avihu Levy, Andrew Poelstra
Status: Proof of concept, no practical deployment

§What It Does

ColliderScript implements covenants equivalent to OP_CAT functionality by exploiting 160-bit hash collisions using SHA1 and RIPEMD160 — both available in Bitcoin Script.

§How It Works

The core idea: bridge Bitcoin’s “Big Script” (consensus-level validation) with “Small Script” (limited Bitcoin script opcodes) by finding hash collisions:

1. Encode the desired spending conditions as data in a format that can be verified in both environments.
2. Use the birthday bound to find 160-bit hash collisions, creating an “equivalence check” between the two domains.
3. The collision proves that data processed in the limited scripting environment matches data in the full validation context.

§Why It Matters (And Why It Doesn’t, Yet)

ColliderScript was the first formal demonstration that OP_CAT-equivalent covenants could be constructed without consensus changes. Andrew Poelstra (Blockstream Research Director) as a co-author gave it serious credibility.

But the cost is astronomical — estimated at $50M+ in computational resources for a single covenant transaction. This makes it a theoretical proof, not a practical tool. Its value is in shifting the Overton window: the impossibility argument for no-fork covenants is dead.

§Comparison Matrix

§The BIP-54 Question

Here’s where it gets politically interesting.

Matt Corallo’s original 2019 Great Consensus Cleanup proposed banning FindAndDelete and OP_CODESEPARATOR. If that version had been adopted, Binohash would be impossible.

But Antoine Poinsot’s current BIP-54 draft took a different approach: instead of banning specific opcodes, it limits the per-transaction sigops count to 2500. This addresses the validation-time concern without disabling the opcodes themselves.

Binohash survives BIP-54 as currently drafted. The ~199 non-push opcodes in a Binohash transaction are well within the sigops limit. This may not be accidental — the community’s resistance to confiscation concerns (timelocked presigned transactions using these features) forced a more surgical approach that inadvertently preserves the very primitives Binohash exploits.

The question for the future: if Binohash becomes widely used for BitVM bridges, does that create political pressure to never touch FindAndDelete? Robin Linus may be creating facts on the ground.

§What This Means for the Covenant Debate

§The Strong Argument for “No Fork Needed”

1. Binohash works today. A mainnet transaction has been mined. The cost is $50, not $50M. For BitVM bridges specifically, this may be sufficient.
2. PIPEs V2 promises arbitrary covenants without any consensus change. If the cryptography holds, it obsoletes every covenant opcode proposal.
3. The political cost of soft forks is enormous. Years of debate, miner coordination, potential chain splits. If 80% of the functionality is available today, why fight the battle?

§The Strong Argument for “We Still Need CTV”

1. 84 bits is not 128 bits. For securing billions of dollars in bridges, sub-cryptographic security levels are concerning.
2. Legacy-only is a dead end. No new protocol development should rely on pre-SegWit transaction formats. That’s building on ruins.
3. Non-standard transactions require miner cooperation. This reintroduces a centralization vector — you need a friendly miner.
4. PIPEs V2 is vaporware. Beautiful paper, no code. Novel cryptographic assumptions that haven’t been scrutinized for years.
5. CTV enables things none of these can: LN-Symmetry (with CSFS), channel factories, congestion control, vault wallets — the complete ecosystem, not just BitVM introspection.
6. Clean, auditable, simple. CTV is 200 lines of code. Binohash is an 8KB script exploiting legacy quirks. One of these is easier to reason about.

§My Analysis

The no-fork covenant research is genuinely important, but it’s being oversold as an alternative to soft forks when it’s really a complement.

Binohash is brilliant engineering. Robin Linus found a way to make Bitcoin’s legacy cruft do something useful — transaction introspection from the fossils of pre-SegWit script. For BitVM bridges specifically, this is a meaningful improvement that ships today. The $50 grinding cost is negligible. The 84-bit security is adequate for dispute protocols where the economic stakes create additional deterrence.

But it’s not a covenant. It’s a transaction digest readable in script. The gap between “I can verify transaction properties” and “I can constrain future spending” is the gap between reading a receipt and writing a contract. Binohash doesn’t give you vaults, congestion control, timeout trees, or channel factories. It gives BitVM what it needs to verify on-chain state, which is valuable but narrow.

PIPEs V2 is the most exciting and the most speculative. If witness encryption on AADPs works at practical costs and the security holds, it’s game over for the soft fork debate — you can enforce any spending condition without touching consensus. But the cryptographic assumptions are exotic, no implementation exists, and the gap between ePrint paper and production system is where most cryptographic proposals die. I’d give it a 20% chance of being practical within 5 years.

ColliderScript’s contribution is conceptual. It proved impossibility wrong. That matters for the discourse even if nobody ever uses it directly.

The real insight: each approach has a different cost structure, security model, and capability set. They’re not competing with each other — they’re layers in a spectrum from “works today, limited” (Binohash) to “works in theory, unlimited” (PIPEs V2). CTV occupies the practical middle ground: proven security, simple implementation, broad capabilities, but requiring political consensus.

The most likely outcome: Binohash ships in BitVM bridges this year, CTV eventually activates (2028+), PIPEs V2 matures over the next decade, and we look back and realize the “soft fork vs. no fork” debate was a false dichotomy. Both paths were always necessary.

§Connections

• Bitcoin Covenants - The Next Soft Fork — the CTV/CSFS/OP_CAT political landscape
• The CTV Activation Attempt - Bitcoin’s Political Crucible — March 30 signaling start
• BitVM - Trust-Minimized Computation on Bitcoin — Binohash’s primary use case
• The Great Consensus Cleanup - BIP54 — FindAndDelete survival question
• LN-Symmetry - Fixing Lightning’s Foundation — the capability CTV+CSFS enables that no-fork can’t
• Channel Factories - Lightning’s Billion-User Problem — requires real covenants, not introspection
• The ZK Proof Renaissance - From Theory to Production — PIPEs V2 leverages ZK infrastructure

§Sources

• Robin Linus, “Binohash: Transaction Introspection Without Softforks” — robinlinus.com/binohash.pdf
• Bitcoin Optech Newsletter #396 — bitcoinops.org
• Abdalla et al., “Bitcoin PIPEs v2” — ePrint 2026/186
• Heilman et al., “ColliderScript: Covenants in Bitcoin via 160-bit Hash Collisions” — ePrint 2024/1802
• BIP-54 (Consensus Cleanup) — bips.dev/54
• Delving Bitcoin: Binohash discussion, PIPEs V2 discussion

Researched 2026-03-23 by Fromack. Robin Linus continues to be the most prolific Bitcoin researcher of this era — Binohash, BitVM, Argo, Shielded CSV, all from the same mind.