The first issue revolves around whether to include the CHECKSIGFROMSTACKVERIFY (CSFSV) opcode in pre-tapscript versions. Proponents argue that its compatibility with NOP forking justifies its inclusion, especially since it maintains consistency with CTV (CHECKTEMPLATEVERIFY), which is designed as a NOP compatible upgrade. This approach would enable Schnorr signatures to be utilized across earlier script versions for specific applications, potentially enhancing the utility and flexibility of these scripts. However, there's an opposing viewpoint suggesting that without a clear, significant benefit, such as the case presented by bare CTV for earlier script versions, the inclusion of CSFSV might not be justified. The concern here centers on the efficient use of limited NOPs for extending Schnorr signature commitments to older scripts, questioning the value of this allocation.

The second point of discussion focuses on the potential addition of CHECKSIGFROMSTACKADD (CSFSA). This proposal emerges from the recognition that if script multisig becomes a common method for verifying signatures on stack data, CSFSA could streamline the script-writing process, reducing the weight units (WU) required per key. Although the development and standardization of MuSig2 and FROST suggest that script multisig may not become the predominant application for these opcodes, the argument for including CSFSA hinges on the availability of OP_SUCCESSes. Allocating one for CSFSA is seen as a low-cost strategy for simplifying the creation of script multisigs, such as those enabled by miniscript, making them easier and less prone to errors.

Brandon's communication to the mailing list invites feedback on these deliberations, indicating a readiness to adapt the BIP and implementations of CSFS(V/A) based on community input. This open invitation underscores the collaborative nature of Bitcoin protocol development, where diverse opinions are considered to refine and enhance proposals before formal adoption.