What does a digital signature scheme need to have in order to be used (indirectly) in Bitcoin?

Question

Here (see the comments) Pieter Wuille described digital scheme as a collection of three algorithms:

(key generation, signing, verification)

Since Bitcoin uses ECDSA (pre-Taproot outputs) and Schnorr (Taproot outputs) digital schemes, my question is what does some digital scheme must to have, that is what is the requirement, to be used indirectly in Bitcoin? When I say indirectly, I mean that it does not replace existing schemes (that would require a hard fork or a new segwit version), but is used to create signatures and keys (in order to multi-party signature or something more advanced). Is the requirement just to have the same verification algorithm, i.e. to ensure that the signature and public key match when the network would use normal ECDSA/Schnorr to verify the validity of the transaction and that's it, or something more?

Answer 1

At a technical level, all that matters is the verification equation. If your scheme ends up with keys and signatures on-chain that verify using ECDSA (or BIP340 for Taproot outputs), the transaction is valid. The consensus rules don't know or care how you ended up with that signature.

And perhaps more generally, Bitcoin Script supports more things than just signatures. You can create a transaction output that can be spent without signature at all. Of course, this would be insecure, but nothing prevents you from using this.

So just because any scheme that results in scripts that execute successfully is in theory usable, doesn't mean any of those should be used. What should be used is a much harder question, because it involves concerns like security, practicality (e.g. 2P-ECDSA for ECDSA multisignatures exist, but is fairly complicated), features (e.g. thresholds and multisignatures, ...), standardization/implementation status (just because someone wrote a paper about a particular scheme doesn't mean there is a usable implementation with sufficient review, ...).