Schnorr Signatures & The Inevitability of Privacy in Bitcoin
By: Lucas Nuzzi
Tags: Cryptocurrency, Bitcoin, Cryptography, Privacy, Blockchain

Thanks to Pieter Wuille for generously providing feedback on this article and educating me on Schnorr. Since his review, I’ve made lots of changes to simplify key concepts presented here. *Any errors & opinions found herein are my own*

Digital signatures are the backbone of online sovereignty. The advent of Public-key cryptography in 1976 paved the way for the creation of a global medium of communication, the internet, and an entirely new form of money, bitcoin. While the fundamental properties of public key cryptography have not changed much since then, there are now dozens of open-source digital signature schemes available in the cryptographer’s toolbox.

When Satoshi Nakamoto began to work on Bitcoin, one of the key design choices to be considered was which signature scheme to use in this open, permissionless financial system. The requirements were clear; Satoshi needed an algorithm that was widely-used, well-understood, sufficiently secure, lightweight, and, most importantly, open-source. Out of all options available at the time, he went with the one that fit that criteria the most: the Elliptic Curve Digital Signature Algorithm, or ECDSA.

Back then, ECDSA was natively supported by OpenSSL, a set of open-source encryption tools developed by cypherpunk veterans to improve the privacy of online communications. Relative to other popular schemes, ECDSA carried the benefits of leaner computational requirements and shorter key lengths; useful attributes for a digital form of money. At the same time, it also provided a proportionate level of security to schemes like RSA: a 256-bit ECDSA key, for example, has equivalent security to a 3,072-bit RSA key, but it is a fraction of its size.

The hard work of Pieter Wuille and others on an improved curve (as in Elliptic Curve) called secp256k1 made Bitcoin’s ECDSA faster and more efficient. However, there are still inherent deficiencies in ECDSA that justify replacing it all along. After a couple of years of research and experimentation, a new signature scheme is set to increase the privacy and efficiency of Bitcoin transactions: the Schnorr Digital Signature Scheme.

In this article, I provide a general overview of the multiple implementations of Schnorr signatures and their corresponding benefits. Then, I explore MuSig, a new multi-signature standard that serves as a building block for novel Bitcoin technologies like Taproot. Lastly, I describe how the fully realized version of Schnorr can break the heuristics used in blockchain analysis and, at the same time, help develop a strong fee market in Bitcoin’s main layer.

THE RISE OF SCHNORR SIGNATURES

Even though the Schnorr digital signature scheme carries many benefits over ECDSA, it is certainly not new. It was invented by Claus-Peter Schnorr, a German cryptographer and academic, while he was a professor and researcher at the University of Frankfurt in the 1980s. His proposed signature scheme was an amalgamation of the research and work of David Chaum, Taher EIgamal, Amos Fiat and Adi Shamir. Nevertheless, before publishing it, Claus Schnorr filed multiple patents for his newly invented scheme, which, for years, prevented its direct use.

Interestingly enough, ECDSA’s predecessor, DSA, was a hybrid of the ElGamal and Schnorr schemes that was solely devised to circumvent Claus Schnorr’s patents. In fact, only two months after Schnorr’s U.S. patent was issued, DSA’s progenitor, the U.S. National Institute of Standards and Technology (NIST), also filed a patent for its workaround. And here’s a bit of prime cypherpunk history: after that happened, Claus Schnorr became very defensive of his patents, and directly responded to his critics in the Coderpunks mailing list; an offshoot of the original Cypherpunks mailing list. His responses can be read here and here. An internal NIST memo describing Patent Issues can also be found here.

In 2008, nearly two decades after the introduction of the Schnorr signature scheme, Claus Schnorr’s patent expired. Coincidentally, 2008 was also the year our favorite cypherpunk, Satoshi Nakamoto, was implementing Bitcoin. Even though Schnorr signatures could have been used at the time, they were not standardized nor widely used, which was probably Satoshi’s motivation to go with ECDSA instead. Although frequently described as atrocious by cryptographers and mathematicians alike, ECDSA was (and still is) widely used and it provided safer option for Bitcoin back then.

SCHNORR ON BITCOIN

Fast forward another decade and Schnorr’s scheme is much less esoteric today, with standardized implementations like ed25519 becoming a popular option for some altcoins. Informal talks about potentially implementing Schnorr on Bitcoin date back to this 2014 BitcoinTalk thread, but a proposal was only formalized after years of research and experimentation, when Pieter Wuille wrote the Schnorr BIP. This draft BIP describes the specifications and technicalities of a potential Schnorr implementation, which would carry the following benefits over ECDSA:

· Security proof: The security of Schnorr signatures is easily provable when a sufficiently random hash function (random oracle model) is used and the elliptic curve discrete logarithm problem (ECDLP) used in the signature is sufficiently hard. Such a proof does not exist for ECDSA. · Non-malleability: ECDSA signatures are inherently malleable, which may enable a third party without access to the private key to alter an existing valid signature and double-spend funds. This issue was formally discussed in BIP62. In comparison, Schnorr signatures are provably non-malleable. · Linearity: Schnorr signatures have the remarkable property that multiple parties can collaborate to produce a signature that is valid for the sum of their public keys. This is the building block for various higher-level constructions that improve efficiency and privacy, such as multi-signatures and other smart contracts.

The security proofs provided by Schnorr, as well as its non-malleability guarantees, offer clear benefits over ECDSA. A soft-fork could be justified solely on the basis of these two benefits. However, it is Schnorr’s Linearity property that is particularly exciting. In essence, this enables multiple signers in a multi-signature (multisig) transaction to combine their public keys into an aggregated key that represents the group; a property that has been called key aggregation.

While the ability to fuse keys may sound trivial, the benefits of key aggregation should not be underestimated. Since multisigs are not natively supported by ECDSA, they had to be implemented in Bitcoin via a standardized smart contract (yes, Bitcoin has smart contracts too) called Pay-to-ScriptHash (P2SH). This enables users to add spend conditions called encumbrances to specify how funds can be spent e.g. “only unlock balance if both Alice and Bob sign this message.”

The first problem with P2SH is that it requires knowledge of the public keys of all signers participating in the multisig, which is not an efficient system. Aggregating these keys would allow for more efficient validation as only one key needs to be verified by the network, rather than n keys. That also means less footprint on the blockchain, lower transaction costs, and improved bandwidth.

The second problem with P2SH is that it offers very little privacy guarantees. As specified by BIP 13, P2SH transactions require different addresses that begin with the number 3. This allows blockchain observers to not only identify all P2SH transactions in the network, but also pin point the identities within the multisig: