Blockstream’s MuSig schemes hopes to develop efficient, secure multisignature transaction capability for Bitcoin in the future.
Following the launch of working code last month, blockchain technology firm Blockstream hopes to successfully develop a new multisignature standard for Bitcoin transactions in the future.
Alongside this, Blockstream also released its latest version of its Bitcoin scaling software c-lightning at the beginning of March, marking a busy period for the highly regarded development house.
Upgrades to the Bitcoin protocol
Historically, potential upgrades to the Bitcoin protocol (BTC) have been a big point of contention since its inception back in 2009.
Satoshi Nakamoto’s original Bitcoin white paper is treated as something of a sacred text, and any changes to the way in which the technology works has been met with skepticism and opposition.
Nevertheless, the Bitcoin protocol has had its fair share of teething problems over the years due to a massive increase in the amount of users and the network’s ability to process transactions in a timely and cost-effective way.
Given that there must be consensus for any potential changes to the code, Bitcoin has been improved by implementations like SegWit, which has slowly rolled out over the past two years.
Any changes that aren’t agreed upon by the majority of the community have led to contentious hard forks, which have given birth to the likes of Bitcoin Cash.
Thus, any potential changes to the Bitcoin protocol take an extensive amount of time, research, development and testing before they can be rolled out to the wider community for consideration and implementation.
MuSig
Blockstream’s new Schnorr-based multisignature scheme (MuSig) has been rolled out for public testing and feedback in order to create working, fault-free code in the future.
To the layman, MuSig is an improvement that could potentially help scale Bitcoin’s blockchain by reducing transaction size by improving performance and user privacy. The groundwork for this code was laid by Blockstream cryptographers Pieter Wuille and Andrew Poelstra, as well as Yannick Seurin and Gregory Maxwell, in a research paper released in 2018.
Just over a year later, Blockstream released working code for testing by the wider cryptocurrency community on GitHub in the hopes that it could eventually be merged into the Bitcoin Core code and other projects.
Schnorr signatures
Digital signatures provide a cryptographic proof that a transaction was authorized by the owner of a particular private key. Most individual Bitcoin users send transactions with one signature that comes from the owner of the private key of the sending address.
Multisignatures provide the same kind of cryptographic proof when there are multiple owners of a wallet. In this case, the various owners need to produce their own individual signatures in order to generate a multisignature that authorizes a transaction.
Schnorr signatures are a specific type of multisignature that provide a couple of important benefits. The name Schnorr comes from the creator of the multisignature algorithm, Claus Schnorr.
Cointelegraph reached out to Blockstream cryptographer Andrew Poelstra to get a better understanding of the intricacies of the proposed MuSig upgrade. As he explains, the algorithm provides a number of benefits:
“Schnorr multisignatures are one specific type of multisignature which are small (64 bytes regardless of signer set size), which can be verified very efficiently, and which avoid exposing the number of signers to the blockchain.”
The reason why this implementation could have a dramatic effect on how the Bitcoin protocol works is due to the current form of multisignature that is used today.
Once again, Poelstra explains that the current multisignature, Elliptic Curve Digital Signature Algorithm (ECDSA), is simplistic in that it requires all signers to produce individual signatures that are then included in the relevant transaction.
“This means that for 2 signers, twice the blockchain space and twice the verification time are needed to process the transaction. If Bitcoin supported Schnorr signatures rather than ECDSA, this would enable several new technologies – most importantly, Schnorr multisignatures.”
For the network of miners that verifies Bitcoin transactions, these Schnorr-based multisignatures are identical to ordinary signatures. This means they are the same size and take the same amount of time to verify, but they are also more private.
According to Poelstra, they don’t reveal the original set of signers, or even provide the number of signers for a multisignature transaction. This should increase the anonymity and privacy of multisignature transactions.
MuSig
Bitcoin currently uses the ECDSA signature algorithm to verify ownership and transfer of BTC on the blockchain. As Blockstream explained in their original announcement, the ECDSA signature has a number of limitations.
The biggest concern is the difficulty of creating multisignatures using ECDSA due to the complexity of the structure of the signatures produced.
Blockstream’s main concern with ECDSA and other current multisignature schemes is that they assume signers of transactions have control of how and when their keys are generated and that they have a reliable and secure memory.
In reality, many Bitcoin users don’t have access to their keys and how they are generated, and they also have no control over third parties and how they use the keys. Blockchain’s proposed MuSig scheme hopes to address this in two ways.
Firstly, MuSig creates short, consistently sized signatures that look the same to verifiers, no matter how many signers are involved. This aims for efficiency, by relieving the burden of signer details while maintaining security.
Secondly, MuSig wants to provide provable security using plain public keys. They are aiming to give signers flexibility in the way they produce and provide multisignatures to transactions without having to provide extra information on how the keys were produced.
It is noted that this is still an area of difficulty when it comes to Bitcoin key generation due to the variety of key management policies in the ecosystem.
Extensive testing needed
While Blockstream hopes to provide a workable solution to improved multisignature transactions, they are under no illusion of the challenges of doing so.
Ensuring the security of multisignature transactions is far more complicated, as it cannot simply use the same hashing method to ensure uniform randomness of signatures through cryptographic hashing.
Subsequent signers of a multisignature transaction could use other signers’ “nonce” (a hashed number that can only be used once in a cryptographic transaction) for more than one signature.
The current solution is to use a session ID for a signing session of a multisignature transaction, which is a temporary one until Blockstream develops a more robust solution.
Replay attacks are still a concern for multisiganture transactions, given the number of steps involved in verifying a transactions that requires signatures from multiple participants.
Considering all of this, Poelstra tells Cointelegraph that the security of Schnorr signatures and their use in MuSig is not a concern:
“Schnorr signatures are algebraically simple to reason about, and provably secure under the same cryptographic assumptions that underlie ECDSA. Of course, as with any proposed change to Bitcoin, the introduction of Schnorr signatures would require a substantial amount of testing and review.”
The way forward
Putting a timeline on the testing and potential implementation of MuSig is not a straightforward concept. Given the complexity of ensuring the security and efficacy of multisignature transactions, a working and trustable solution will take a considerable amount of time to produce.
As Poelstra explains, developing and implementing MuSig will require collaboration with the wider Bitcoin community:
“The first step is putting together a concrete, specific proposal, and sending this to the bitcoin-dev mailing list for community review. The review process will likely take many months, during which time the proposal could undergo many changes. In parallel to this, and continuing afterward, code needs to be written, tested and reviewed. The software then needs to be widely deployed before the changes can be activated. It is hard to say how long this entire process will take.”
In the event that the code is approved and implemented by the wider Bitcoin community, it won’t be necessary to undergo any sort of hard fork to implement changes, according to Poelstra:
“The introduction of Segwit in 2017 also introduced a versioning mechanism for changes to Bitcoin Script (such as the introduction of new signature schemes), which allows such upgrades to happen in a softfork. Prior to Segwit it would also have been possible to introduce Schnorr signatures in a softfork, though with more engineering effort to ensure a smooth transition as users update at different times.”
The wider Bitcoin development community is being encouraged to test Blockstream’s code on GitHub in order to facilitate the development of fully usable code in the next few months and years.
