Blockstream’s new MuSig proposal, based on Schnorr signatures, that was originally drafted over a year ago on 15th January 2018, has just been released. The scheme if accepted would replace the existing ECDSA signatures and claims to be more efficient and offer:
“Provable security, even against colluding subsets of malicious signers, and produces signatures indistinguishable from ordinary single-signer Schnorr signatures.”
The change would make signatures used within multi-sig transactions much more consistently sized and shorter saving time on validation and space within each block. It would also introduce greater flexibility into the system something not currently allowed with ECDSA.
“ECDSA signatures have a complex algebraic structure that makes them inflexible and difficult to work with, forcing developers to use Bitcoin Script for applications such as cross-chain atomic swaps or Lightning, which could be implemented more compactly and privately using a more flexible signature scheme.”
The new code has been merged into secp256k1-zkp, a fork of secp256k1, the high-assurance cryptographic library used by Bitcoin Core, making it available for other developers outside of blockstream to test and scrutinise. The team hope the change will eventually be approved and merged upstream making it publicly available and active on the network however they are aware of issues that would most definitely need addressing first. Since diving into the realm of digital signatures for bitcoin and cryptocurrencies, they report discovering that many other similar schemes, including an early version of their own MuSig was insecure.
“Further, since announcing MuSig, we have learned that many published signature schemes, including an earlier unpublished version of MuSig, are actually insecure! We will explore this further in a future post.”
There are also concerns around replay attacks of these new signatures, where an attacker might be able to extract the individuals secret key, something Blockstream are upfront with:
“To protect signers who may serialize stale states and restart from them, our API simply does not support serialization of signing sessions. What this means in practice is that users of our code who want to support signing sessions that can survive across power resets or interruptions — which is a reasonable goal for a hardware wallet — must maintain secure persistent memory.”
This isn’t the only area the team are aware that needs improving and they plan on writing further papers on how to improve the MuSig proposal. Topics of discussion will include extending support to threshold signatures, how to make the nonce randomness safer and more verifiable by using a technique called sign-to-contract, along with leveraging zero knowledge proofs to mitigate the threats of replay attacks.