The issue pertains to whether this operation should exclusively support BIP340 Schnorr signatures, which utilize 32-byte keys, or if it should also accommodate ECDSA signatures characterized by 33-byte keys prefixed with 0x02 or 0x03. This debate was further examined during a session on the Optech review platform.

There is a division among developers regarding the necessity and benefits of including ECDSA. Notably, some are considering whether the support, if included, should be limited to legacy and witnessv0 scripts only or extended to tapscript designated by 0xc0. Among the community, there seems to be a consensus leaning towards excluding ECDSA; this is reflected in the positions held by multiple developers, including @murch. Only @JeremyRubin appeared somewhat open to the idea of integrating ECDSA, although without a solid argument in its favor.

This technical inquiry is central to the development process, as it affects how Bitcoin scripting will evolve and function in the future. The decision to include or exclude ECDSA support in OP_CHECKSIGFROMSTACKVERIFY has implications for script flexibility, security considerations, and backward compatibility with existing systems. Thus, it's a matter that warrants careful deliberation by the developer community.