Is CSFS+CAT already a general covenant primitive? Three on-chain demonstrations, and an observation for discussion

Protocol Design
, ,
1

I’d like to float an observation and ask people to poke holes in it.

The observation (tentative). CSFS+CAT — both already activated on Inquisition signet — seems, in practice, to behave like a general covenant primitive: on the introspection axis (committing to, or reading, transaction fields), the dedicated-opcode family (CTV, TXHASH, OP_VAULT, OP_TEMPLATEHASH, OP_PAIRCOMMIT) looks largely reachable on top of it. I don’t think this is new as a theoretical claim — Poelstra (2021) and Harding (2023) argued CAT-composition is broadly powerful years ago. What I tried to add is concreteness: I built three of these and confirmed them on chain, rather than asserting “CAT can do it.”

What I actually did — three confirmed Inquisition-signet spends:

  1. Output binding = CTV’s output template. Forces sha_outputs to a hardcoded value. tx 2f345180…f37e6 (block 300379). Writeup: Delving /t/2483/3.
  2. Input binding — something neither CTV nor APO does. Forces the spend to consume a specific prevout set (sha_prevouts): i.e. “spend A only if B is co-spent” (the BitVM-bridge connector). tx 7311da6e…3558. Writeup: Delving /t/2483.
  3. Eltoo state replacement — APO’s use-case, not APO’s primitive. A CSFS+CTV delegation ladder reaches the eltoo topology. Note this is O(n) delegation, not APO’s O(1) rebinding — I’m reproducing the use-case, not the primitive. txs 92efc475… (fund) + b96324da… (settle). Writeup: Delving /t/2430.

The mechanism behind all three is the same: same-signature binding (one signature must pass both OP_CHECKSIG against the node’s sighash and OP_CHECKSIGFROMSTACK against a witness-supplied preimage — so the witness preimage has to be the real one) + preimage decomposition (slice out and check any field). OP_VAULT, OP_TEMPLATEHASH, and OP_PAIRCOMMIT (which is a restricted CAT) follow by the same composition — I have not demonstrated those on chain, and I mark them as reasoned, not experiments.

Three things I’m deliberately NOT claiming:

  • This is capability, not efficiency. My scripts and witnesses are bigger; the dedicated opcodes are far cheaper, and that’s exactly their point.
  • It covers signer-participating spends only — same-signature binding needs a spending signature, so genuinely keyless covenants are out of scope.
  • I’m not arguing CAT is harmless. The constructions actually show the feared capabilities are real. My only point there is a consistency one: those same capabilities are reachable via the alternatives too, so singling out CAT isn’t obviously consistent. And the narrow opcodes’ narrowness is often a deliberate, valuable safety/review feature — I’m not dismissing it.

I’m not advocating for or against activating anything. I’d genuinely like to know where this breaks: where does “largely reachable” fail? Which covenant patterns are not reachable with CSFS+CAT for signer-participating spends?

Full paper (byte-level constructions, every txid inline and clickable): btcaaron/examples/csfs_cat_covenant_parity/Capability_Parity_CSFS_CAT_Covenants.pdf at c6e6ce84adb81c9a05d15c4559625372f085ef22 · aaron-recompile/btcaaron · GitHub . Critique very welcome.

1 Like