# What exactly is bound in CSFS, IK+CSFS, and CHECKSIG? **URL:** \ **Category:** Implementation\ **Created:** [March 23, 2026, 1:41am UTC](https://delvingbitcoin.org/t/what-exactly-is-bound-in-csfs-ik-csfs-and-checksig/2351 "2026-03-23T01:41:09Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![AaronZhang](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/aaronzhang/32/1823_2.png) [@AaronZhang](https://delvingbitcoin.org/u/AaronZhang)\ **Post date:** [March 23, 2026, 1:41am UTC](https://delvingbitcoin.org/t/what-exactly-is-bound-in-csfs-ik-csfs-and-checksig/2351/1 "2026-03-23T01:41:09Z")
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): > **[GitHub - aaron-recompile/bitcoin-signature-binding: Tapscript Schnorr “what verifies against”...](https://github.com/aaron-recompile/bitcoin-signature-binding)** > > Tapscript Schnorr “what verifies against” experiments — CSFS, IK+CSFS, CHECKSIG — with checked-in outputs. Does this framing match how others think about it? ---
**Author:** ![AaronZhang](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/aaronzhang/32/1823_2.png) [@AaronZhang](https://delvingbitcoin.org/u/AaronZhang)\ **Post date:** [April 2, 2026, 7:22pm UTC](https://delvingbitcoin.org/t/what-exactly-is-bound-in-csfs-ik-csfs-and-checksig/2351/2 "2026-04-02T19:22:13Z")
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](https://Challenge:%20Covenants%20for%20Braidpool%20(post%20#2)) ---
**Author:** ![AaronZhang](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/aaronzhang/32/1823_2.png) [@AaronZhang](https://delvingbitcoin.org/u/AaronZhang)\ **Post date:** [April 9, 2026, 8:34pm UTC](https://delvingbitcoin.org/t/what-exactly-is-bound-in-csfs-ik-csfs-and-checksig/2351/3 "2026-04-09T20:34:32Z")
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](https://github.com/aaron-recompile/mastering-taproot/blob/e9067dbeebb60d3ac054ce503d1dfc0168adbba5/book/manuscript/Chapter%2009%20Ordinals%20and%20BRC-20%20-%20Data%20Envelopes%20in%20Single-Leaf%20Script%20Paths.md) ---
**Author:** ![AaronZhang](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/aaronzhang/32/1823_2.png) [@AaronZhang](https://delvingbitcoin.org/u/AaronZhang)\ **Post date:** [April 24, 2026, 5:30pm UTC](https://delvingbitcoin.org/t/what-exactly-is-bound-in-csfs-ik-csfs-and-checksig/2351/4 "2026-04-24T17:30:27Z")
Adding a fifth row to the binding framework, now that I have on-chain results for both ladder rebinding and APO rebinding side-by-side. | Pattern | Binding target | Cross-prevout reusable? | Witness scaling | | --- | --- | --- | --- | | OP\_CHECKSIGFROMSTACK | Message (stack-supplied) | Yes | O(1) | | OP\_INTERNALKEY + OP\_CHECKSIGFROMSTACK | Identity (internal key) | Yes (same key) | O(1) | | OP\_CHECKSIG (default sighash) | Full transaction sighash | No | O(1) | | OP\_CHECKSIG with APO (BIP-118) | Sighash minus prevouts | Yes (same script + amount) | O(1) | | CSFS rekey ladder | Delegated key chain | No (per-channel) | O(n) in state count | A few observations from the empirical side, just from staring at TxIDs: 1. APO and the CSFS ladder both achieve eltoo-style state replacement, but along different binding axes. APO loosens what the signature commits to; the ladder threads authority through fresh keys derived per state. 2. The witness-scaling difference matters in practice. APO’s O(1) keeps a long-running channel cheap regardless of state count; the ladder’s O(n) makes it unattractive past roughly ten states. So the ladder is a “primitives-first” alternative for short state chains, not a structural replacement for APO in long-lived protocols. 3. Cross-prevout reuse — APO’s distinguishing feature — is what lets the same signature spend a fee-bumped funding tx variant without re-signing. The ladder cannot do this because each ladder is anchored to one channel’s funding outpoint at script creation time. So if anything, the ladder strengthens the case for APO in the “long-running, fee-volatile channel” use case, while showing that short-state-chain eltoo can run today on already-activated opcodes. References: Post :APO+CTV eltoo, 6 txs: > [@Eltoo State Chain on Signet: Three Rounds, Six Transactions (APO + CTV)](https://delvingbitcoin.org/t/eltoo-state-chain-on-signet-three-rounds-six-transactions-apo-ctv/2413): > > In a previous post ([BIP 118 signing from scratch + on-chain rebinding proof](https://delvingbitcoin.org/t/bip-118-signing-from-scratch-on-chain-rebinding-proof/2411)) I demonstrated an independent Python implementation of the BIP 118 sighash, and two confirmed transactions that demonstrate the rebinding property. That post covered the signing primitive. This one covers what we can build with it. I ran a three-round Eltoo-style state chain on Inquisition 29.2 signet. Construction Each state UTXO is a three-leaf Taproot tree: leaf 1 — ctv\_settle: \ OP\_CHECKTEMPLATEV… Post: CSFS+CTV ladder, 2 txs: > [@Eltoo State Chain on Signet Again: Three Rounds, Two Transactions (CSFS + CTV, with rekey and ladder, no CAT)](https://delvingbitcoin.org/t/eltoo-state-chain-on-signet-again-three-rounds-two-transactions-csfs-ctv-with-rekey-and-ladder-no-cat/2430): > > Last week I posted [Eltoo State Chain on Signet: Three Rounds, Six Transactions (APO+CTV)](https://delvingbitcoin.org/t/eltoo-state-chain-on-signet-three-rounds-six-transactions-apo-ctv/2413). This post is a counterpart to that experiment – same 3-round Alice/Bob/Carol scenario, switching the primitive to CSFS+CTV. The result is two on-chain transactions instead of six. No new opcode, no OP\_CAT – only CSFS and CTV, both already activated on Inquisition signet. What I did Encoded 3 rounds of state progression into a single CSFS delegation chain (a ladder), with CTV enforcing the final 3-output se…