Schnorr signatures: following in the steps of SegWit?
On Monday, Bitcoin Core released a highly anticipated software upgrade designed to provide substantial performance improvements to the Bitcoin protocol. Version 0.16.0 of Bitcoin Core adds full support for Segregated Witness and lays the foundation for future scaling concepts, which includes implementations for Lightning. While this is only one piece to the grander scaling puzzle, SegWit is nonetheless a means to supplement the Bitcoin blockchain with additional room for transactions.
Given this news, I’d like to shine light over to a developing signature scheme that has been slowly gaining attention — notably from Charlie Lee and Pieter Wuille — that’ll eventually provide Bitcoin with an alternative to its current digital signature setup. While this would by no means be a direct scaling solution, Schnorr signatures nonetheless reduce the digital signature footprint and will further improve the overall protocol.
NOTE: Pieter Wuille’s BPASE Speech or the Blockstream WP may interest you should you seek something more mathematically informative.
Digital signatures…
To properly understand Schnorr signatures, we should briefly recap the current digital signature setup. Recall Bitcoin’s cryptographic backbone, public key cryptography, is what allows an individual to be associated with a given public/private key pair. The link of these two keys is established after a private key (which is just a randomly generated 256 bit of numbers) goes through a particular algorithm (ECDSA in Bitcoin’s case) and spits out the associated public key. The public key is then hashed with base58 to remove lookalike characters, (i.e. O and 0 or 1 and I) to generate an address.
Then, once you spend some BTC, you show the network you are indeed the rightful owner by revealing your associate private key to make a digital signature (without actually revealing the private key). Through this paired setup, the network is able to attain two properties: authentication, allowing others to verify someone is indeed the owner of the paired private key, and encryption, with only the private key owner being able to decrypt the message.
However, while this is a straightforward approach, there still remains a problem… signatures take up space. And given Bitcoin’s UTXO model, it grows linearly as you accumulate more inputs from previous transactions, as all inputs require their own signature to be spent. Given such, this is where Schnorr signatures could offer a potential solution…
Schnorr signatures
Named after the (expired) patent holder Claus-Peter Schnorr, Schnorr signatures are simply another scheme of digital signatures which are compatible with Bitcoin’s current elliptic curve (secp256k1). They enable several improvements over the current setup, while simultaneously preserving the current features and security assumptions.
One immediate advantage is their size. The current Bitcoin signature ranges between 71–73 bytes, while Schnorr signatures (generated through the ed25519 algorithm) is 64 bytes in size. This equates to fewer CPU cycles and faster verification. Simply by being more compact, they already reduce the number of bytes stored by a few percent. However, this is not why developers and cryptographers favor Schnorr…
Signature Aggregation
The value of Schnorr lies with how signatures can be aggregated across multiple inputs (UTXOs) of a transaction. Instead of having to provide multiple signatures for each input (like we currently do), a transaction with Schnorr allows for a single signature on ALL inputs.
Recall the current UTXO (Unspent Transaction Output) model Bitcoin uses is based on all of the unspent transactions. Here, our unspent outputs are used as inputs into the next transaction. So once someone decides to send Bitcoin, their unspent outputs become inputs into the transaction, are deleted, and passed off to the recipient as new UTXOs.
For example, let’s say we receive one Bitcoin from friend 1 and one Bitcoin from friend 2. If we decide to make a purchase worth two Bitcoin, we need to provide a signature for each of those previous inputs before storing them both onto the Bitcoin blockchain. With Schnorr, we can aggregate the needed signatures down to just one signature per transaction (instead of 1 signature per UTXO).
In his January speech at BPASE, Wuille estimated that purely from aggregating signatures for each transaction (and leaving everything else the same), the Bitcoin blockchain would be anywhere between 25% to 30% smaller. Maybe wishful thinking, yet it still poses the desire for such implementation, simply as a means to reduce fees as well as the resources miners need in order to run such a setup.
We can see aggregation also being prime in the case of multi-sig transactions‒ transactions involving multiple people in which a single input requires several signatures. With more signers being added to the multi-sig, more signatures come as a consequence. This would mean a 5–20 transaction and 15–20 transaction input could be given the same weight (given we don’t care who signs it) while keeping the authority of the original signatures and without burdening the network or incurring additional costs. A win-win.
And a case to be made for privacy…
While signature aggregation is its primary advantage, there is also room to capitalize on incentivized privacy.
With multi-signature transactions becoming more economical, it would incentivize participants of the network enough to improve network privacy as it would become more challenging to determine who was responsible for spending a given amount under a multi-sig transaction. Said differently, Schnorr signatures avoid leaking info to whether or not a transaction was a multi-sig or not in the first place.
Additionally, Schnorr sigs could incentivize the usage of privacy-enhancing tools such as CoinJoin (which has seen several flaws). But by aggregating multiple transactions and effectively sharing the fee for transaction space with others, it would improve the network’s privacy as a whole.
While additional research is needed (especially given they were once held under patent), what else may entice the adoption? Well, once adopted, Schnorr sig’s would only require a soft fork (as SegWit gave versioning for Bitcoin script)…
If you want to dig deeper into how Schnorr signatures work, check out this post! Additionally, should you want to write a story for Badger Blockchain (UW-Madisons student blockchain org), don’t hesitate to reach out via Slack. We’d love to hear from you.
