<p>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.</p>
<p>And perhaps more generally, Bitcoin Script supports more things than just signatures. You <em>can</em> 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.</p>
<p>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, ...).</p>

CC BY-SA 4.0
2023-11-10T18:14:35.560Z
So, **Bitcoin and its consensus only involve the verification algorithm from the (key generation, sing, verification) digital signature scheme** (specifically the verification algorithm for ECDSA and Schnorr)? Algorithms for key generation and signature generation are not important and are not even part of the consensus rules, that is, part of Bitcoin?
LeaBit
CC BY-SA 4.0
2023-11-10T18:18:52.273Z
I disagree that key generation and signing are unimportant - they're standardized, and individual wallet security very much depends on doing it right. They're just aspects of the wallet side of things, and not part of the consensus rules.
Pieter Wuille
CC BY-SA 4.0
2023-11-10T18:22:28.260Z
I wanted to say that they are not important to Bitcoin in the context of the consensus because they are not part of it. However, they are important from the security aspect, as you said, for wallets, creating the transaction in a secure way, etc.
LeaBit
CC BY-SA 4.0
2023-11-10T13:39:07.497Z
2023-11-10T13:39:07.497Z
Pieter Wuille
<p><a href="https://bitcoin.stackexchange.com/a/120376/145749">Here</a> (see the comments) <em>Pieter Wuille</em> described digital scheme as a collection of three algorithms:</p>
<p>(key generation, signing, verification)</p>
<p>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 <em>indirectly</em>, 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). <strong>Is the requirement <code>just to have the same verification algorithm</code>, 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?</strong></p>

<public-key><signature><ecdsa><schnorr-signatures>
What does a digital signature scheme need to have in order to be used (indirectly) in Bitcoin?
LeaBit
# What does a digital signature scheme need to have in order to be used (indirectly) in Bitcoin?

(Asked by: username_0 on 2023-11-09)

[Here](https://bitcoin.stackexchange.com/a/120376/145749) (see the comments) *username_1 username_1* 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?**

**Tags:** public-key, signature, ecdsa, schnorr-signatures


---

## 1 answers

### Answer by username_1 on 2023-11-10. Score: 1 | Accepted answer

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, ...).

> **Comments:**
> **username_0**: So, **Bitcoin and its consensus only involve the verification algorithm from the (key generation, sing, verification) digital signature scheme** (specifically the verification algorithm for ECDSA and Schnorr)? Algorithms for key generation and signature generation are not important and are not even part of the consensus rules, that is, part of Bitcoin?  
> **username_1**: I disagree that key generation and signing are unimportant - they're standardized, and individual wallet security very much depends on doing it right. They're just aspects of the wallet side of things, and not part of the consensus rules.  
> **username_0**: I wanted to say that they are not important to Bitcoin in the context of the consensus because they are not part of it. However, they are important from the security aspect, as you said, for wallets, creating the transaction in a secure way, etc.  

---

