What exactly is bound in CSFS, IK+CSFS, and CHECKSIG?

Implementation
1

I’ve been running a small set of experiments to make the differences between three Tapscript constructions more observable.

Pattern Binding target Replayable?
OP_CHECKSIGFROMSTACK Message (stack-supplied) Yes
OP_INTERNALKEY + OP_CHECKSIGFROMSTACK Identity (internal key) Yes, same key
OP_CHECKSIG Transaction sighash No

A tentative framing: IK+CSFS changes where authorization is sourced from, but not what the signature commits to — same opcode family, different binding surface.

Repo (offline harness + Signet anchors + checked-in outputs):

Does this framing match how others think about it?

2

Follow-up after running some APO experiments:

Adding SIGHASH_ANYPREVOUT to the table:

Pattern Binding target Replayable?
OP_CHECKSIGFROMSTACK Message (stack-supplied) Yes
OP_INTERNALKEY + OP_CHECKSIGFROMSTACK Identity (internal key) Yes, same key
OP_CHECKSIG Transaction sighash No
SIGHASH_ANYPREVOUT (BIP118) Transaction sighash minus outpoint Yes, same script + amount

APO seems to sit somewhere between CHECKSIG and CSFS in terms of what gets bound. It removes the outpoint commitment but keeps the rest — amount, script, outputs. So the same signature can be reused across different prevouts, as long as those match. Not “unbound,” just selectively unbound on the input side.

One thing this made concrete for me: APO + CTV split the commitment problem across two surfaces — APO relaxes the input side (no outpoint), CTV fixes the output side (template). Neither is sufficient on its own, but together they form a workable constraint system.

This came up directly while building a Braidpool-style covenant demo — APO handles Eltoo-style RCA updates and CTV commits the UHPO payout template per round.

Maybe the question is not just what is bound, but what is fixed vs what is left open — and on which side. The table above is one attempt to make that more explicit.

See the construction here:：https://delvingbitcoin.org/t/challenge-covenants-for-braidpool/1370/2

3

Building on the framing above, one additional angle that became clearer to me:

Ordinals/Brc20 look like message/data publication, but the reveal is not message-bound — it is ownership-bound.

The data is fully exposed in the witness, but a third party still cannot front-run the reveal, because they cannot produce a valid signature for the committed UTXO.

Also, the data envelope is not executed, but it is still committed via the TapLeaf. Changing even one byte breaks the reveal.

So it seems to separate:

• CHECKSIG → who can spend

• TapLeaf → what is committed

This may also explain why CSFS is not used here. CSFS would bind a message, But it seems these data-embedding constructions need to bind the right to publish the data, not just the data itself.

One way I’m starting to think about this is as a spectrum:

CSFS → message-bound (replayable)

IK+CSFS → identity-influenced

CHECKSIG → transaction-bound (not replayable)

There’s a concrete Ordinals example here that helped me reason about this:

Ordinals and BRC-20 — Data Envelopes in Single-Leaf Script Paths