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

The exploration of Tapscript constructions reveals nuanced differences in their operation and application. A detailed analysis was conducted to compare three specific Tapscript patterns: OP_CHECKSIGFROMSTACK, OP_INTERNALKEY + OP_CHECKSIGFROMSTACK, and OP_CHECKSIG. Each pattern is distinguished by its binding target and whether it can be replayed. Specifically, OP_CHECKSIGFROMSTACK targets a message supplied by the stack and allows for replayability. The combination of OP_INTERNALKEY and OP_CHECKSIGFROMSTACK shifts the focus towards the identity (via an internal key) while retaining the possibility of replay using the same key. In contrast, OP_CHECKSIG is bound to the transaction's sighash and does not permit replay.

This investigation provides a tentative framing that suggests while OP_INTERNALKEY + OP_CHECKSIGFROMSTACK alters the source of authorization, it does not change the commitment of the signature, maintaining adherence to the same opcode family but with a different binding surface. To support this analysis and facilitate further discussion, a repository containing an offline harness, Signet anchors, and checked-in outputs has been made available at https://github.com/aaron-recompile/bitcoin-signature-binding. This initiative seeks to align with or challenge the community's understanding of how these Tapscript constructions are conceptualized and applied within Bitcoin's scripting landscape.