Schnorr signature, with its first BIP draft recently introduced by Bitcoin developer Pieter Wuille, affects the core of Bitcoin rules and can potentially make transactions faster, cheaper and smaller in size.
Many believe that Schnorr signature is the next big change in the code of Bitcoin after SegWit (Segregate Witness), which tore the community apart resulting in the rise of Bitcoin Cash. The most recent development in years of extensive work on Schnorr is the Bitcoin Improvement Proposal (BIP) draft. It was introduced by Pieter Wuille, a Bitcoin developer and Blockstream co-founder. The point of the BIP draft is to create in the end a standardized version of Schnorr to avoid ambiguity in the process of integration by merchants, exchanges, and wallets in Bitcoin.
As an upgrade, the digital signature algorithm Schnorr will be an on-chain scaling of Bitcoin which would require a soft fork because it carries a change to the consensus rules. On-chain scaling refers to changes in the blockchain layer. A hard fork would only be required if old-style ECDSA outputs are spent using Schnorr. With a soft fork, users will be able to apply the old-style signature format.
Benefits from using Schnorr signatures in Bitcoin
One of the biggest benefits of Schnorr is that MultiSig transactions will be indistinguishable from normal transactions due to the Signature Aggregation. Schnorr allows multiple signatures to be combined into one. This means that there is one signature for an entire transaction. Thus the privacy of MultiSig will be greatly improved.
Other benefits are that on-chain transactions will potentially be smaller in size, cheaper and faster. This will increase transaction throughput and will greatly help in times of big demand as we saw in the end of 2017 when transaction fees became extremely high. Validation of transactions is expected to be faster which will result in a more secure and more scalable Bitcoin. Pieter Wuille estimated that with Signature Aggregation the blockchain of Bitcoin would shrink with around 25% in size.
Important to note is that those benefits will be realized only when using Signature Aggregation on Schnorr. The current BIP is only designed to integrate Schnorr and not Signature Aggregation (or Key Aggregation). Integrating Schnorr is the first step towards those benefits and Signature Aggregation will be up to the wallets to use.
ECDSA vs Schnorr
The current cryptographic algorithm in Bitcoin is the Elliptic Curve Digital Signature Algorithm (ECDSA) which belongs to the Elliptic Curve Cryptography (ECC) class. It is used for the creation of public keys and for the signing of transactions. ECC is a form of public-key cryptography where public keys are produced through elliptic curve multiplication. Such cryptographic functions are impossibly hard to reverse with today’s computers. “The security of elliptic curve cryptography rests on the assumption that the elliptic curve discrete logarithm problem is hard.” (Lauter & Stange, 2009, p. 309), which means that it is impossibly hard to compute the private key from the public key.
The problem with ECDSA is that it is not possible to be proven secure mathematically, whereas Schnorr which also belongs to the class of ECC, can (Pointcheval & Stern, 2000, p. 34). Even though ECDSA is not proven secure, Wuille commented that he believes if there is an eventual break of ECDSA it will be an Elliptic Curve Discrete Logarithm Problem (ECDLP) break - the ability to invert the crypto function.
In other words, he believes if there is a break in ECDSA it will be a break of the whole EC-class, so there is no need to fear from using ECDSA specifically.
Bitcoin uses the “secp256k1” standard for its elliptic curve to produce keys. Secp256k1 is rarely used outside of Bitcoin (Narayanan, Bonneau, Felten, Miller, & Goldfeder, 2016, p. 40). The decision to use “secp256k1” was made in the early days of Bitcoin without any fundamental reason behind that choice. The common thing between Schnorr and ECDSA in Bitcoin is that the new cryptographic scheme (Schnorr) will be made to use the same elliptic curve (secp256k1) for calculating public keys.
Wuille said in a tweet that:
This means that people who would like to use the old-style signatures will be able to do so.
There was a short-lived discussion online about the BLS (Boneh–Lynn–Shacham) signature scheme, also part of the EC family. However, using BLS will require using a different curve.
So, there is no way to translate all secp256k1 public keys into BLS public keys.
Some of the reasons why BLS was interesting for developers was because, as mentioned by Wuille, it offers “a strictly stronger (and newer) security assumption. On the other hand, it lets you do cooler things too :)”
Schnorr signatures are easier to deploy than BLS, which will require a complete rewriting of the code in Bitcoin and it will use a different curve than secp256k1.
Schnorr is still far from being integrated into Bitcoin and the BIP draft is just one step in the process towards eventual integration, if the users are willing to adopt it. Similarly to the SegWit upgrade it is up to the users to decide if they want Schnorr or not.
Now the BIP is in the hands of developers to smoothen out the code and gather comments from its community. It is not a draft for integration or a plan for deployment as the actual integration will require the consensus of the whole community. This time the community is expected to accept it without any in-fights, unlike the SegWit soft fork.