Digital signatures can rightfully be considered the foundation of online sovereignty. In 1976, the first public-key cryptographies appeared, paving the way for the creation of the Internet and, consequently, a new form of money, Bitcoin. Even though the fundamental properties of such cryptography have not changed very much, today there are many different open-source digital signature schemes. When Nakamoto first started working on Bitcoin, he had to choose which signature scheme to use for an open and publicly accessible financial system. He understood the requirements: it was necessary to create a popular, sought-after, secure algorithm with a source code. At that time, the most suitable option was the Elliptic Curve Digital Signature Algorithm, or ECDSA. At that time, the native support for ECDSA was provided by OpenSSL, which is an open set of encryption tools developed by experienced crypto punkers to increase the secrecy of online communications. If we compare ECDSA with other well-known schemes, we can say that this option has huge advantages: low computing resource requirements, as well as short key lengths. It also provides a proportional level of security to the RSA scheme. Here is a simple example: A 256-bit ECDSA key has a comparable level of security to a 3072-bit RSA key, even though its key is much smaller. P. Vuille and his colleagues did a lot of hard work to improve the elliptic curve, which everyone is used to calling secp256k1. Thanks to this ECDSA, Bitcoin is now much faster and more efficient. However, ECDSA still has drawbacks that could easily lead to its complete replacement. After several years of research, experimenters have developed a new signature scheme that significantly increases the secrecy and efficiency of transfers in the Bitcoin network. It is called the Schnorr digital signature scheme. In this article, you will learn about the multiple implementations of Schnorr signatures, as well as the advantages of such signatures. We will also look at MuSig, which is a new multi-signature standard that serves as a basis for implementing new Bitcoin technologies, such as Taproot. And finally, we will learn how the full implementation of Schnorr signatures can disrupt the heuristics used in blockchain analytics, and at the same time help develop a strong commission market on the main Bitcoin layer.
How Schnorr signatures appeared
As we have already mentioned, the Schnorr digital signature scheme has a number of advantages compared to ECDSA, and it is far from new. It was invented back in 1980 by a cryptographer and academic from Germany named Klaus-Peter Schnorr. By the way, at that time, he was still a professor and leading researcher at the University of Frankfurt. Schnorr relied on the scientific works of D. Chaum, T. El-Gamal, A. Fiat, and A. Shamir. And yet, before publishing the new scheme, he had to fill out a large number of patents, and they, in turn, prevented its direct application for many years. It is quite interesting that the DSA algorithm, which is the predecessor of ECDSA, was essentially a hybrid of Schnorr and El-Gamal’s schemes, which was created only to circumvent Schnorr’s patents. In fact, only 60 days after Schnorr was granted the U.S. patent, the progenitor of DSA, the National Institute of Standards and Technology of the United States, also managed to get a patent for its own solution. Schnorr then began to defend his patents more thoroughly, responding sternly to critics in the Coderpunks newsletter. Twenty years after Schnorr’s signature scheme was presented, Klaus’s patent expired in 2008. Coincidentally, that same year, S. Nakamoto introduced the world to Bitcoin. At that time, Schnorr’s signatures were not yet in demand or standardized, but they could already be used. Most likely, this is why Nakamoto decided to choose ECDSA. Surprisingly, modern mathematicians and cryptographers claim that this algorithm is terrible, but ECDSA is still widely used, and it was the most secure option for Bitcoin at the time.
Schnorr signatures in Bitcoin
If we look at the Schnorr signature scheme today, the picture looks a little less esoteric, and its standardized implementations, such as ed25519, have already become a popular option for certain altcoins. Informal conversations about the possible implementation of Schnorr signatures in the Bitcoin network date back to a certain branch of the BitcoinTalk forum, which dates back to 2014. However, this proposal was formalized only after several years of research and experimentation, when P. Vuille created the Schnorr BIP. Now let’s look at the entire specification, as well as some technical aspects of the future implementation of Schnorr signatures, which potentially have the following advantages over ECDSA:
- Security proof – Schnorr signatures are easy to prove if a random hash function is used, as well as the required complexity of the discrete logarithmization task in a group of points on an elliptical curve. ECDSA does not require such a proof;
- inflexibility – ECDSA signatures are considered to be quite flexible, so a 3rd party that does not have access to the confidential key can change the existing real signature and use the means 2 times. Schnorr signatures, on the other hand, are not flexible;
- linearity – Schnorr signatures have one remarkable property: several parties can simultaneously create a signature valid for the sum of their public keys. This approach is seen as a building block for various higher-level constructions that significantly increase the privacy and efficiency of multisignatures, as well as various smart contracts.
These points can rightfully be considered the advantages of Schnorr signatures over ECDSA. Proving security and inflexibility is, in fact, a very significant reason for soft forking. However, the most unique property is still linearity. Basically, it allows some people to sign transfers using a multisignature and combine all public keys into one single key that represents the entire group. This property is called key aggregation. The benefits of such an association should not be underestimated. Since there is no native support for multi-signatures in ECDSA, they need to be implemented on the Bitcoin network using a standardized smart contract called Pay-to-ScriptHash. It allows users to add spending conditions, called encumbrances, to show how the funds can be spent. The main difficulty with P2SH is that it requires knowledge of the public keys of absolutely all participants in the multisignature, and this is definitely not an efficient system. The process of aggregating these keys would make it possible to optimize verification, as the network would only need to verify 1 key. Another significant problem with P2SH is that it provides little guarantee of secrecy and privacy. The BIP13 stated that P2SH transfers require that each address begin exclusively with the number 3. Thanks to this approach, blockchain analysts can quickly recognize all P2SH transfers in the network, as well as identify the addresses directly involved in the multisignature with amazing accuracy. In this example, the network will know both that a multisignature transfer exists and how many addresses are involved, as well as who specifically signed the transaction. From a privacy perspective, this is not good for 2FA, for example. On the other hand, key aggregation can preserve the anonymity of the participants in a multisignature, and it will not compromise operational security by disclosing the keys that are needed to lift the balance lock. Importantly, key aggregation will make it possible to perform multisignature transfers that are indistinguishable from regular transactions. The first iteration of Schnorr signatures in Bitcoin will significantly simplify the OP_CHECKSIG and OP_CHECKMULTISIG opcodes currently used in ECDSA in favor of an updated class of opcodes called OP_CHECKDLS. DLS is a discrete logarithmic signature that allows signatures to be verified much more efficiently and with a minimum number of opcodes. At the beginning of last year, G. Maxwell, E. Poelstra, J. Seurin, and P. Vuille published a whitepaper on a new multisignature scheme called MuSig, which is based on the Schnorr signature. Then they began to work on translating the proposed multisignature scheme into a special code that would be suitable for use. The most interesting thing about MuSig (in terms of key aggregation) is the ability to create private smart contracts outside the blockchain. In fact, MuSig allows multisignature participants to use encumbrances to such keys offline, without disclosing all the conditions, and separately from the existing Bitcoin consensus rules. Last winter, E. Townes became the first Bitcoin Core developer to prepare a special semi-formalized proposal on the activation of Schnorr signatures. It was even presented in a newsletter for Bitcoin network developers. It is likely that the next few months will see an increase in the number of conversations about a possible soft fork in the future. As a result of all of the above, the first iteration of MuSig in Bitcoin will be able to support key aggregation, which will immediately improve the privacy of multisignatures, increase the efficiency of transfer verification, and make security more reliable by eliminating all the complexities inherent in ECDSA. It will also create an opportunity to integrate smart contracts, such as Taproot.
Cross-aggregation of transaction inputs is one of the next steps towards increasing Bitcoin’s privacy
As you may have already realized, key aggregation is a very significant and useful feature for multi-signature transactions. Since Bitcoin transactions have more than one input, we can say that potential iterations of Schnorr signatures can be used as an element of creating an interactive aggregated signature scheme. In this scheme, each input of a transaction can be verified simultaneously with each other, as well as with a common signature. Once again, mutual actions between the participants of the multisignature are performed offline, but at the moment, one signature can be used to spend each transaction input. Absolutely all inputs will have their own public key, but it can be used with the interactive aggregated Schnorr signature. G. Maxwell, P. Vuille, and E. Townes worked on the evolution of a smart contract scheme called “Taproot” to make this functionality easier to access. They nicknamed this scheme “Generalized Taproot” or G’root. It will make it easier to move from key aggregation to cross-aggregation of transaction inputs in the near future. Cross-aggregation of inputs also increases the efficiency of Bitcoin transactions. However, it is important that it helps to open up opportunities for the implementation of certain mechanisms aimed at preserving the privacy of participants at the level of the Bitcoin protocol. Cross-aggregation of inputs has a key aspect, the essence of which is that it can significantly improve CoinJoin transactions on the Bitcoin network. CoinJoin is an effective way to maintain privacy. It combines recipients and senders in a single transaction. The idea is to make it much more difficult for blockchain analysts to establish the relationship between senders and recipients of funds. This allows users of CoinJoin transactions to directly deny their involvement in a particular transfer. It was G. Maxwell who proposed this technique on BitcoinTalk back in 2013. Since that time, it has been included in the list of services offered by JoinMarket, CoinShuffle, ShufflePuff, SharedCoin, and DarkWallet. Variations of CoinJoin, such as Chaumian CoinJoin, have greatly improved the original model. But since privacy is not against the company, they also want to have a significant number of users in order to mix the balances of absolutely all participants in the transfer as efficiently as possible. Today, there is an additional problem with CoinJoin, and it is the future tendency to censor this type of transfer. It should also be taken into account that the essence of the heuristic rule, which is often used in blockchain analytics, is to track all transaction inputs in order to determine the number of actors to whom the addresses may belong. For example, if player A transferred, say, 1.982723 bitcoins to player B, a blockchain analysis program will be able to track even decimal fractions of this input in order to be able to place a transaction graph or history of splits into certain fractions, as well as transfers of UTXO management rights. To prevent this, different inputs to a CoinJoin transaction can be denominated, and in the end, all participants in this transfer will have to send the same amount to an external observer. Here’s another example: if a Wasabi Wallet user nominally sends 0.1 bitcoin as part of a CoinJoin transaction of one hundred participants. Although this does not establish a strong relationship between a particular recipient and sender, a blockchain analyst will still be able to recognize transactions that have nominally different inputs and recommend that their clients censor each address directly involved in it. This problem can be solved by cross-aggregating transaction inputs, namely by introducing a certain mechanism for hiding information right at the protocol level. In fact, this will make it possible to create CoinJoin transactions based on Schnorr signatures with multiple participants. An external observer will perceive them as regular transfers with 1 participant. This approach will make it easier to implement CoinJoin in the most popular wallets, which will increase the total anonymous set of the network, or, in other words, the number of users using this method of maintaining anonymity. Special techniques can also solve the problem of denominating to equal parts, for example, Pay-to-EndPoint, which combines the very first developments of S. Nakamoto in privacy issues with CoinJoin, and the inputs of transfers are issued to both senders and recipients. Summarizing all of the above, we can say that P2EP technology is compatible and reverse compatible, and if used in conjunction with Schnorr signatures, it can significantly increase the privacy of Bitcoin, even at a basic level.
One shot at two birds with one stone
It can be assumed that the mass adoption and spread of Bitcoin will depend on the reliability of its privacy guarantees. At the same time, the popularity of the Lightning Network, as well as its potential for confidential transfers, has created uncertainty about the potential demand for online payments after the mining of the Bitcoin edge. Thus, the importance and need for privacy guarantees, as well as the long-term sustainability of Bitcoin, provided that there is no block reward, will be the most significant issues related to Bitcoin. It is encouraging to see that the privacy mechanisms provided by Schnorr signatures potentially solve both of these problems at once. Those who are seriously engaged in this field have thoroughly studied the most complex privacy technologies, including various implementations of ring signatures, such as MimbleWimble, Confidential Transactions, zk-STARK, zk-SNARK, Bulletproof signatures. Of course, some of them are now mature enough to be included in the Bitcoin core layer, but they are also still interconnected with risks and compromises that are rare in history. Also, Bitcoin is not at all prone to emerging hard forks, which gives rise to doubts about the possibility of introducing support for any of these technologies into Bitcoin. The concern that is sometimes expressed about the use of homomorphic encryption or non-interactive proof-of-work systems with zero disclosure is essentially that they do not fully ensure the preservation of absolute transparency and auditability of the Bitcoin cash reserve base. To put it another way, when transfer amounts are hidden by encryption, it is not clear whether the 21 million bitcoin limit was actually met. It is also difficult to distinguish between inflationary errors and so-called double spending. Such a shortcoming can be considered quite significant, and the implementation of a compromise on the Bitcoin core layer is quite capable of dividing the community. But what if there is a way to achieve excellent privacy without implementing these technologies on the Bitcoin core layer? Implementing support for Schnorr signatures could help with this. If we imagine that the majority of Bitcoin transactions used the function of cross-aggregation of inputs in conjunction with Pay-to-EndPoint, then it is impossible to calculate certain recipients and senders using blockchain analytics methods. The volume of Bitcoin issuance could still be verified, however, with more robust privacy guarantees. If there is a demand for privacy, then it can be assumed that users and businesses will want to take a passive role in CoinJoin transactions so that their wallets can constantly shuffle the coins on their balance in the background. The demand for privacy will then lead to higher fees for online transfers. Just like with SegWit, users will be the first to adopt the technology, but companies will need to start following the trend at some point. This is necessary in order not to lose their market position. After a while, the adoption of these technologies will inevitably lead to the obsolescence of blockchain analytics, as well as the removal of blockchain companies from the list of required KYC-AML procedures, just like with cash. At the moment when you deposit cash into your personal bank account, this organization never checks the bills for traces of drugs, and if it finds them by accident, it will not prevent the crediting of these bills. Today, there is no real reason why the same should happen with Bitcoin, except for the prevalence of blockchain analytics combined with the negative aspects of methods such as CoinJoin transactions without Schnorr signatures. At the moment when the implementation of KYC/AML procedures for certain addresses, as well as UTXO, loses its relevance, and the focus shifts from account balances to users, then Bitcoin companies will be able to adopt a new level of privacy. As a rule, the field of this, privacy and coin fungibility will become an important part of the offer of potential Bitcoin companies. As a result, the process of adopting the strongest privacy mechanisms on the Bitcoin core layer will maximize the opportunities for its users and will also contribute to the formation of a dynamic payment market. This will happen only after users have mined the last BTC. Most likely, this process will begin with the activation of Schnorr’s signatures.
Feedback (0)
Leave a review