SIP - Schnorr signatures#56
Conversation
| This SIP describes the addition of Schnorr signature structure and validation to the account model for the Stacks blockchain. | ||
|
|
||
| ## Introduction | ||
|
|
There was a problem hiding this comment.
Formatting nitpick: can you make sure all lines are about ~100 characters long, so that when someone submits a patch it doesn't create a ton of merge conflicts?
|
|
||
| ## Introduction | ||
|
|
||
| The Stacks blockchain signing system was initially built on ECDSA, similar to how the Bitcoin blockchain was. However, it is widely acknowledged that Schnorr is the better signing algorithm over ECDSA. The primary reason it wasn’t used in the Bitcoin blockchain for many years is that Schnorr was patented until 2008, the same year Bitcoin was invented. At the time, Satoshi Nakomoto decided that Schnorr signatures lacked the popularity and testing required to secure a system as critical as Bitcoin. |
There was a problem hiding this comment.
However, it is widely acknowledged that Schnorr is the better signing algorithm over ECDSA
By whom? I don't doubt that many cryptographers might prefer a Schnorr signature schema over ECDSA, but can this text point to specific technical arguments for Schnorr over ECDSA? Maybe there's something in here for further reading: https://en.wikipedia.org/wiki/Schnorr_signature#Security_argument
The primary reason it wasn’t used in the Bitcoin blockchain for many years is that Schnorr was patented until 2008
Is there a source for this? Bitcoin was released in 2009, so I'm surprised to learn that this was indeed the motivating reason for omitting Schnorr signatures.
|
|
||
| The Stacks blockchain signing system was initially built on ECDSA, similar to how the Bitcoin blockchain was. However, it is widely acknowledged that Schnorr is the better signing algorithm over ECDSA. The primary reason it wasn’t used in the Bitcoin blockchain for many years is that Schnorr was patented until 2008, the same year Bitcoin was invented. At the time, Satoshi Nakomoto decided that Schnorr signatures lacked the popularity and testing required to secure a system as critical as Bitcoin. | ||
|
|
||
| 13 years later, Schnorr now has been tested and popularised through the Bitcoin Taproot upgrade in November 2021. Now that Schnorr has been implemented on Bitcoin, I believe we should adopt it for Stacks too. |
There was a problem hiding this comment.
Phrasing: this is a technical document, so the first-person voice should not be used.
Also, I'd recommend dropping this paragraph. If there are specific, principled reasons to add Schnorr signatures to Stacks' consensus rules, we should just use them to arguing for this change (like how you do below).
|
|
||
| Schnorr signatures have many advantages over ECDSA ones: | ||
|
|
||
| - **Better privacy**, by making different multisig spending policies indistinguishable on-chain. Used in Stacks transactions, these spending policies become a single signature on-chain, regardless of number of participants in an account. This opens up opportunities for decentralised organisations (DAOs) such as the Syvita Guild to coordinate Stacks transaction activity offchain, as the compute cost to verify a Schnorr signature on Stacks made from one or a million people is identical. |
There was a problem hiding this comment.
I think you're confusing signature aggregation with the Schnorr signature scheme here. They're not the same thing.
| - **Better privacy**, by making different multisig spending policies indistinguishable on-chain. Used in Stacks transactions, these spending policies become a single signature on-chain, regardless of number of participants in an account. This opens up opportunities for decentralised organisations (DAOs) such as the Syvita Guild to coordinate Stacks transaction activity offchain, as the compute cost to verify a Schnorr signature on Stacks made from one or a million people is identical. | ||
| - Enabling **simpler higher-level protocols**, which can be used to build more efficient payment channel constructions (such as [Stacks subnets](https://gist.github.com/jcnelson/06dedca12f7121349936b1b5bc853d5a)). | ||
| - Improving **verification speed**, by supporting batch validation of all signatures in a block at once (for a fraction of the speed of validating them individually). | ||
| - Switching to a **provably secure construction**, perhaps preventing [an exploit against ECDSA in the future](https://eprint.iacr.org/2019/023.pdf). |
There was a problem hiding this comment.
This no longer applies to modern ECDSA implementations, which use RFC 6979 to ensure that the nonce k is randomly-chosen.
|
|
||
| This specification inherits the current transaction authorization structure from SIP-005 and expands it to incorporate Schnorr signatures, which are implemented as single-signature spending policies | ||
|
|
||
| ### Transaction Authorization |
There was a problem hiding this comment.
Instead of copying and pasting the text from SIP 005, can you instead just describe the specific changes you'd want to make to it? Thanks!
2 participants
This SIP describes the addition of Schnorr signature structure and validation to the account model for the Stacks blockchain.