Schnorr Signatures: What, When & Why?

The last few months have seemingly been particularly fruitful when it comes to development activity surrounding second-layer Bitcoin technologies, with recent news pointing towards great progress for both the Liquid and Lightning networks. However, recent activity from prominent Bitcoin developer Pieter Wuille looks towards a set of changes to an area of the core Bitcoin protocol, namely the signature scheme. Wuille submitted a draft BIP (Bitcoin Improvement Proposal) last month outlining a proposed specification for a Schnorr signature scheme, with a view towards its eventual utilisation within the Bitcoin codebase. After some years since first being discussed, this is the first of many steps in actually moving towards adding Schnorr signatures to Bitcoin. This was made possible by the segregated witness upgrade which was completed last year, or more specifically the script versioning capabilities enabled by the changes.

Schnorr signatures were developed by Claus P Schnorr and subsequently protected by U.S. Patent 4,995,082 up until late 2008. As a result of the patent, Schnorr signatures had not been standardised or widely used in open-source crypto libraries at the time of Bitcoin’s inception. The signing algorithm used in Bitcoin is ECDSA (Elliptic Curve Digital Signature Algorithm), and although Schnorr was believed by some to be a more elegant signature solution with a simple mathematical proof when Bitcoin was first established, it’s protected status resulted in far greater adoption and standardisation of ECDSA across the computer science world when Bitcoin was being developed by Satoshi Nakamoto.

The BIP outlines a specification for 64-byte Schnorr signatures with the elliptic curve parameters: secp256k1. This is the same elliptic curve parameters that are currently used in Bitcoin with the ECDSA signatures. Schnorr signatures offer a number of benefits which indicate that using it within Bitcoin would be an overwhelmingly positive endeavour. The purported benefits of Schnorr include an on-chain size advantage for transactions, with Schnorr signatures capped at 64 bytes, compared to around 71-75 bytes for ECDSA. With an average of around 200,000 transactions sent every day, this small reduction in signature size has the ability to make quite a significant impact on the data added to the blockchain on a daily basis.

Schnorr also enables more compact multi-signature capabilities, wherein multiple signatures can be combined into one single Schnorr signature of 64 bytes. It is in multi-signature transactions that the largest efficiency gains will be made with Schnorr, and the proportional costs of these transactions will be brought in line with a standard 1-to-1 transaction.  This could be a great development for custodians and wallet-providers that routinely utilise multisig transactions for security, as large multi-signature setups currently require all signatures to be included in a transaction, greatly increasing the size and cost of making such transactions. Schnorr signatures also offer batch validation capabilities with an associated computational advantage, wherein a great many signatures may be validated at once, whilst requiring less computation than if they were verified individually.

There are also a number of additional applications of Schnorr which are mentioned by Wuille in the draft BIP, such as adaptor signatures which could be utilised for a new atomic swap mechanism and a wide variety of so-called “scriptless scripts” which utilise the linear nature of the Schnorr signatures to craft script-like behaviours without using actually using Bitcoin Script Opcodes.

Schnorr signatures have been reasonably widely discussed within the Bitcoin development community over the last few years, but an implementation is now possible through the use of the script-versioning feature which was introduced with segwit last year. This means the necessary opcodes for Schnorr can be added via a soft-fork, without causing any serious issues for nodes that are not using the most up-to-date software client.

However, as one of the more serious proposed changes since segwit, Wuille acknowledges that whilst it is a reasonably straightforward change to make from a technical standpoint, the challenging nature of politicking within the Bitcoin space may mean that achieving a community consensus could prove difficult. Hopefully this is not the case, as most participants in Bitcoin are likely able to see the direct benefits of using a more compact cryptographic proof across the network, particularly during the next somewhat inevitable period of rising on-chain transaction fees when block space demand increases. It is important to remember that this is only the first in a number of stages in bringing Schnorr signatures to Bitcoin, but it is exciting to finally see the wheels in motion on such a positive improvement which has been discussed widely over the years.