Jesse’s grant is generously supported by Nexo.
The promise of Bitcoin is only as secure as the cryptographic keys that authenticate its operations: they are the keys to freedom in the digital age. However, the requirements for Bitcoin key management are becoming more demanding with innovative off-chain protocols such as the Lightning Network and Discreet Log Contracts that introduce new roles and responsibilities for keys.
Off-chain protocols facilitate smart contracts that are highly scalable and private, which enable a vast array of new markets and financial instruments. However, many of these protocols present challenges from a key management perspective because they rely on “hot” keys that must be readily accessible and frequently reused, unlike safer “cold” keys that are rarely accessed and never reused. With the introduction of Taproot, we can begin to bridge this divide between a “hot” and “cold” key by leveraging distributed key generation and threshold signing.
Distributed key generation is a cryptographic protocol in which parties use secure multi-party computation (MPC) to generate a public/private key pair in such a way that no party learns the private key. Instead, each party learns a “share” of the private key, and when a threshold of these parties cooperate they can use their shares to generate signatures for the key. The threshold is configured by the parties when the key is generated. For example, if 5 parties generated a key with a threshold of 3, then at least 3 of the parties would need to cooperate to produce a signature (i.e. 3-of-5).
This means that for the entire lifecycle of the private key–from generation to expiration–it is never constructed or represented on any device in any form (assuming a threshold of shares has not been compromised). With Taproot, we can leverage the linearity of Schnorr signatures to perform signing with 3 communication rounds (or 2 rounds with limited concurrency). This is in contrast to ECDSA multisignature schemes, which are complex and require many more rounds. And with the recent invention of Flexible Round-Optimized Schnorr Threshold Signatures (FROST), signing can even be done in a single round, with unlimited concurrency.
With FROST, a single Schnorr signature is generated that is indistinguishable from a signature that is generated by a single party. An outside observer, solely by analyzing the data in the blockchain, cannot detect that a multi-party scheme was used to generate the signature. This makes FROST favorable from a scaling perspective because regardless of how many parties were involved in signature generation, the blockchain only stores a single signature that is always the same size. In this way, privacy and scalability work hand in hand.
FROST is a relatively new scheme yet some notable open-source implementations have already been developed, such as frost and frost-dalek, two Rust implementations using the Ristretto group, frost-ed25519, a Go implementation using Ed25519, and redjubjub, a Rust implementation using Jubjub. However, none of these implementations are currently compatible with Bitcoin, which uses secp256k1 and BIP-340 Schnorr signatures. My plan is to implement a Bitcoin-compatible FROST in C built on secp256k1-zkp.
I’m currently in the early stages of the project and I’m focusing on gathering feedback and drafting specifications. I will be sharing a detailed roadmap and timeline soon. Follow Brink and subscribe to the newsletter for updates, and follow me on GitHub to track my progress!
Keep in touch
Subscribe to the Brink newsletter for future blog posts.