Four applications of BIP-327 MuSig2: inscriptions, Bitcoin re-staking, BitVM co-signing, digital asset custody

Original Title: "BIP-327 MuSig2 in Four Applications: Inscription, Bitcoin Restaking, BitVM Co-sign, and Digital Asset Custody"

Authors: Qin Wang (CSIRO), Cynic (Chakra), mutourend (Bitlayer), lynndell (Bitlayer)

Introduction

Existing Bitcoin transactions use CheckMultiSig to verify n-of-n multi-signatures, resulting in the need to publish signatures and public keys proportional to the number of signers in the transaction on the Bitcoin blockchain. This method not only reveals the total number of participants in the transaction but also increases transaction fees as the number of signers grows. To address this issue, researchers proposed the Schnorr multi-signature protocol: MuSig in 2018. However, this protocol required three rounds of communication between signers, leading to a relatively poor user experience and preventing widespread attention and application.

In 2020, the introduction of MuSig2 made significant progress in interactive signing: reducing the communication rounds from three to two, providing a better experience for users. Additionally, MuSig2 allows a group of users to jointly generate a single signature and public key to verify transactions, enhancing privacy and significantly reducing transaction fees. After more than three years of continuous improvement, Schnorr multi-signatures (MuSig2) have been implemented in wallets and devices.

Proposals related to MuSig2 are as follows:

• 2022 Bitcoin BIP-327: MuSig2 for BIP340-compatible Multi-Signatures

• Recently https://github.com/achow101/bips/commits/musig2/, currently merged into the Bitcoin BIP repository.

The Bitlayer and Chakra research groups found that with the flourishing of inscriptions, Bitcoin restaking, BitVM, and digital asset custody, BIP-327 MuSig2 has immense application potential, theoretically supporting an unlimited number of signers participating in transactions, saving on-chain space, reducing fees, and improving security, privacy, and operability.

Inscriptions: Inscriptions are the act of engraving custom content into Bitcoin's satoshis. Due to their ability to create immutable and verifiable records of information directly on the blockchain, this concept has garnered widespread attention. Inscriptions can range from simple text to complex data structures, providing a reliable method to authenticate the authenticity and provenance of digital assets. The permanence and security of blockchain inscriptions make them highly valuable in applications such as digital identity verification, proof of ownership, and timestamping of critical information. For inscriptions, MuSig2 can improve the signing and verification rates, reduce the transaction fees required during the minting process, and provide the necessary security for off-chain indexers, thereby enhancing the overall reliability of the inscription ecosystem.

Bitcoin Restaking: Bitcoin holders reallocate their staked assets to support various blockchain protocols or decentralized finance (DeFi) applications. This process allows Bitcoin to play multiple roles within the blockchain ecosystem, enhancing its utility and yield potential. By participating in restaking, users can contribute to the security and functionality of other networks while maintaining their Bitcoin holdings. This innovative approach leverages Bitcoin's liquidity and security, promoting a more integrated and efficient blockchain economy. Due to Bitcoin's lack of contract capabilities needed for liquid staking and the UTXO architecture's inability to adequately support arbitrary denomination withdrawals of staking tokens, MuSig2 is needed to achieve liquid staking for Bitcoin.

BitVM: A framework for implementing smart contract functionality on the Bitcoin network. Unlike Ethereum's virtual machine (EVM), which natively supports complex smart contracts, BitVM aims to extend Bitcoin's scripting capabilities for more complex programmable transactions. This development opens new avenues for decentralized applications (dApps) and complex financial applications on Bitcoin, breaking through the limitations of its simple scripting language. The introduction of BitVM marks a significant evolution in Bitcoin's utility, bridging the gap between Bitcoin and other more flexible smart contract platforms. Without requiring a soft fork, BitVM necessitates pre-signing to achieve a 1-of-n trust assumption and permissionless challenge functionality. To minimize the trust assumption, the value of n needs to be as large as possible. However, the existing CheckMultiSig script verification for large-scale multi-signatures incurs extremely high transaction fees, rendering it impractical. MuSig2 allows for a large n value, making the value of n not limited by Bitcoin block and stack size restrictions, but rather by the actual number of coordinable cosigners, with low fees.

Digital Asset Custody: Using blockchain to securely store and manage digital assets such as cryptocurrencies, NFTs (non-fungible tokens), and other tokenized assets. This involves protecting private keys, ensuring access control, and providing protection against network threats. Threshold signatures play a key role in the secure management of digital assets by achieving distributed management of cryptographic keys. This technology divides private keys into multiple shares and distributes them to different participants. To sign a transaction or access digital assets, a predetermined threshold number of shares must be combined, ensuring that no single party can unilaterally control or misuse the assets. This enhances security by mitigating the risks of key leakage, insider threats, and single points of failure. Additionally, threshold signatures provide a more robust and flexible governance model for digital asset management, allowing for secure collaboration and decision-making in decentralized organizations and multi-party systems. Combining threshold signatures with MuSig2 can simultaneously meet the application needs of inscriptions, Bitcoin staking, BitVM co-signing, and digital asset custody, achieving multiple benefits.

MuSig2 Principles and Implementation Specifications

MuSig2 Principles

MuSig2 Implementation Specifications

Recently, Bitcoin core contributor Andy Chow proposed several BIP proposals:

• BIP-328: Derivation Scheme for MuSig2 Aggregate Keys【Application Layer】: Describes the construction of BIP 32 extended public keys based on the BIP 327 MuSig2 aggregate public key and uses these BIP 32 extended public keys for key derivation.

• BIP-373: MuSig2 PSBT Fields【Application Layer】: Adds fields for random numbers, public keys, and partial signatures in BIP174 Partially Signed Bitcoin Transaction (PSBT).

• BIP-390: musig() Descriptor Key Expression【Application Layer】: Provides a method for transaction outputs controlled by MuSig2 wallets.

These are necessary steps for the adoption and wallet integration of MuSig2. These BIPs and specifications encompass everything needed to integrate MuSig2 into wallets. Additionally, many wallet developers and collaborative custody solutions (see Getting Taproot ready for multisig) have long called for the standardization of the MuSig2 protocol. Now, with formal BIPs in place, the community can review, provide feedback, and help raise awareness.

MuSig2 Achieving Multiple Benefits

Inscriptions

The most typical application of inscriptions is the construction of BRC20, which can be seen as NFTs on Bitcoin. Its core design is to engrave data on each satoshi through the Ordinals protocol and implement simple operations. Overall, there are three steps.

The first step is to track the uniqueness of each satoshi. Since a satoshi is the smallest indivisible unit of Bitcoin, and the total supply of Bitcoin is 21 million, the maximum number of available satoshis is 2.1 quadrillion. Each satoshi in Bitcoin is a unique entity, which is the underlying logic for establishing NFTs on Bitcoin. Each satoshi will be assigned a forward serial number (via the Ordinals protocol) and managed in a first-in, first-out manner to ensure precise tracking and orderly processing. As shown in the figure, each satoshi is part of a complete sequential series, with examples showing satoshis #1, #11, and #31.

The second step is to embed messages into satoshis using JSON format and Taproot scripts. These messages are stored in the SegWit field, making the process efficient and secure. The script embeds JSON into the satoshi, specifically within the OP field. OPIF begins the conditional judgment, while the embedded content is arranged after the OPFALSE field, ensuring that subsequent content is not executed but stored. Thus, the embedded JSON is fully preserved on this satoshi. The JSON embedded content shown in Figure 1 includes key parameters for deploying BRC20 tokens. It specifies the protocol as "brc-20," the operation type as "deploy," the token symbol as "ordi," the maximum supply set at 21 million, and the minting limit at 1000. Key BIPs supporting this process include Schnorr Signature (BIP340), Taproot (BIP314), Tapscript (BIP342), and SegWit (BIP141).

The third step involves recognizing BRC20 tokens, which involves off-chain state management by indexers. These indexers parse and interpret the state of BRC20 tokens based on historical transactions. They parse on-chain data, check token status, and update balances to ensure information is current. Additionally, lightweight clients integrate this information, allowing users to seamlessly identify and manage their BRC20 tokens.

Figure 1. Key Steps for BRC20 Tokens

Here, the deployment and minting operations require only one transaction, while transferring BRC20 tokens (i.e., the transfer operation) requires two transactions. In the first transaction, a basic requirement for on-chain engraving is performed for the sender, which is very similar to the minting operation. In the second transaction, another transaction completes the transfer from the sender to the receiver. The off-chain indexer then updates the state. If conditions are met, the indexer deducts the corresponding amount from the sender's balance and credits it to the receiver's balance.

We can observe that Schnorr signatures have been used in Bitcoin's Taproot upgrade, enhancing the privacy and efficiency of Bitcoin transactions. The upgraded version of Schnorr multi-signatures (MuSig2) can be intuitively and naturally integrated into parts of the Taproot upgrade and seamlessly connect to processes such as inscriptions and the creation of BRC20. The newly upgraded inscriptions can improve signing and verification rates on the existing foundation and further reduce the transaction fees required during the minting process.

Another application comes from the off-chain indexer part. The current indexers essentially act as off-chain validators, with different service providers offering their own indexer update services. The risks arising here come from untrustworthiness, just like many sidechain and Rollup service providers, where users cannot trust relatively centralized service providers. Even if these indexers do not store users' native funds, erroneous or delayed quotes can lead to transaction failures for users. MuSig2 provides a multi-signature approach. A relatively decentralized and large number of validators can be introduced to jointly maintain the same indexer, performing joint verification at specific nodes to sign checkpoints, similar to a checkpoint mechanism. Users can at least trust that the indexers submitted on-chain inscriptions and transaction flows honestly and reliably before the checkpoints. Thus, MuSig2 provides the necessary security for off-chain indexers, enhancing the overall reliability of the inscription ecosystem.

Bitcoin Staking

Unlike PoS chains like Ethereum that have native staking mechanisms, Bitcoin is maintained by a PoW consensus mechanism and requires additional mechanisms to achieve staking functionality. Currently, the most well-known Bitcoin staking solution is proposed by Babylon.

In the Babylon staking mechanism, users complete staking through a BTC staking script defined by Babylon, called a staking transaction, which generates staking outputs. Staking outputs are Taproot outputs, with internal keys disabled by setting them to NUMS points, and there are three available script paths to achieve staking functionality:

• Time-lock path: Implements the locking function for staking;

• Unstaking path: Implements the function to end staking early;

• Penalty path: Implements the system's punishment function for malicious actions.

The Bitcoin staking mechanism provides Bitcoin holders with a relatively secure yield scheme, enhancing the utility of Bitcoin assets. However, this staking somewhat compromises the liquidity of Bitcoin. Nevertheless, years of exploration of Ethereum's staking mechanism have paved the way for Bitcoin staking, allowing the use of liquid staking to address this issue.

Liquid staking introduces a new role, that of the custodian of assets. Users deposit assets into the custodian address of the liquid staking project and receive corresponding liquid staking tokens (Liquid Staking Token, LST). The liquid staking project will natively stake the collected assets, and LST holders automatically share the staking rewards. Additionally, LST holders can directly trade LST in the secondary market or burn LST to exchange for the original staked assets.

Liquid staking on Ethereum can be achieved through smart contracts. However, Bitcoin lacks the contract capabilities required for liquid staking, and the UTXO architecture does not adequately support arbitrary denomination withdrawals of LST. Currently, due to the absence of contract opcodes like OP_CAT, it is not possible to effectively impose restrictions on the future spending methods of Bitcoin transaction outputs. Therefore, MuSig2 is needed to achieve liquid staking for Bitcoin.

As shown in Figure 2, in Chakra's liquid staking, users first transfer Bitcoin to a multi-signature address supported by MuSig2. This event is captured by the indexer, which calls the on-chain contract to mint ckrBTC for the user. The Bitcoin in the multi-signature address will be staked in Babylon. While holding ckrBTC, users can continue to earn rewards from Babylon staking. When users want to end staking, they can destroy ckrBTC, and after the indexer detects the destruction event, it performs the unstaking operation to return Bitcoin to the user. Additionally, users can also directly trade ckrBTC in the secondary market to exchange for Bitcoin.

Figure 2. Chakra Liquid Staking Process

Compared to self-custodied staking, liquid staking supported by MuSig2 introduces multiple participants to maintain the security of digital asset custody while simultaneously releasing the liquidity of staked Bitcoin, allowing LST to play a greater role in BTCFi, thus providing users with more returns.

BitVM Co-sign

In October 2023, Robin Linus released the white paper BitVM: Compute Anything on Bitcoin, which uses Lamport one-time signatures to implement stateful Bitcoin scripts. This system can achieve Turing-complete Bitcoin contracts through an optimistic challenge mechanism without introducing new opcodes or soft forks. The system constructs NAND gate binary circuits using only OPBOOLAND and OPNOT opcodes, demonstrating a challenge mechanism for verifying arbitrary computations on Bitcoin. However, the size of the circuits compiled from the program is enormous and nearly impractical. Subsequently, BitVM1 expressed programs using RISC-V instructions, fully utilizing all opcodes in the Bitcoin system to improve efficiency.

BitVM2 expanded on BitVM1 in two aspects. (1) In BitVM1, the challengers are members of the alliance participating in the initial setup, while in BitVM2, challengers can be any participant. Therefore, there is a risk of collusion among alliance members in BitVM1, while the challengers in BitVM2 are permissionless, preventing collusion among alliance members. (2) BitVM1 requires multiple rounds of challenges, resulting in a longer cycle, while BitVM2 fully utilizes the simplicity of ZK Proof and the scripting capabilities of Taptree, reducing the challenge cycle to only 2 rounds and decreasing the number of pre-signed transactions required during peg-in from about 100 to around 10. Specifically, BitVM1 needs to use binary search and multiple rounds of interaction to find the erroneous RISC-V instruction in the program; whereas BitVM2 verifies not the program itself but the ZK proof that the program executes correctly. BitVM2 will break the ZK verification algorithm into multiple sub-functions, each corresponding to a Tapleaf. When challenged, the Operator must reveal the values of each sub-function; if there are inconsistencies, anyone can initiate a Disprove transaction to penalize them.

As shown in Figure 3, BitVM2 requires a large number of n-of-n pre-signatures. Since users do not know which Operator will advance their payment, the BitVM alliance must pre-sign n-of-n transactions for Take1, Take2, Assert, Disprove, and Burn before initiating the Peg-in transaction. Users will only deposit funds into the n-of-n multi-signature controlled address after confirming that all child transactions have been pre-signed. When users want to withdraw funds, they can initiate a Peg-out transaction, where one Operator advances the payment, allowing the withdrawal to be completed.

Operators need to stake 2 BTC to reimburse the advanced Bitcoin. If no one challenges, the Operator can successfully reimburse through the Take1 transaction. If the Operator acts maliciously, anyone can initiate a challenge after crowdfunding 1 BTC. In the face of a challenge, if the Operator does not respond, the Burn transaction will be executed, destroying 1.9 BTC, with the remaining 0.1 BTC going to the receiving address in the Burn transaction; if the Operator responds, the Assert transaction will be executed.

• Situation 1: If a value of a sub-function revealed is inconsistent, anyone can initiate a Disprove transaction, destroying 1 BTC, with 1 BTC going to the receiving address in the Disprove transaction.

• Situation 2: If the values of the sub-functions revealed are consistent, then after 2 weeks, the Operator can successfully reimburse through the Take2 transaction.

Figure 3. BitVM 2 Process

In the BitVM2 system, the BitVM alliance needs to pre-sign n-of-n transactions for Take1, Take2, Assert, Disprove, and Burn. The trust assumption for BitVM is 1-of-n, where a larger n value results in a lower trust assumption. However, such a large-scale multi-signature requires extremely high fees, making it nearly impractical on Bitcoin. MuSig2 can aggregate a large number of multi-signatures into a single signature, minimizing fees and theoretically supporting an unlimited n value, depending on the actual number of coordinable cosigners, such as n values of 1000 or even larger.

During the deployment of BitVM, to prevent the BitVM alliance from colluding to spend through n-of-n multi-signatures, it is required that at least one cosigner among the n cosigners deletes their private key after the Peg-in setup is completed. This ensures that the funds in the BitVM bridge can only be spent through reimbursement transactions after the Operator honestly advances the payment. Thus, it enhances the security of the BitVM bridge.

Digital Asset Custody

Aggregated signatures allow multiple signatures to be combined into a single signature, simplifying the verification process and improving efficiency. As shown in Figure 4, Alice generates a signature SigA using her complete private key KeyA, while Bob generates a complete signature SigB using his complete private key KeyB. Then, SigA and SigB are aggregated to produce the aggregated signature AggSig. This method not only ensures the independence and accountability of each participant but also enhances the overall security of the system, as both parties' participation is required for any authorization operation. Through this collaboration, Alice and Bob can achieve more secure and efficient digital asset management, preventing single points of failure and malicious actions while simplifying the complexity of transactions and verification costs.

On the other hand, when Alice and Bob both use threshold signatures to manage their respective digital assets and need to use aggregated signatures (MuSig2) for a transaction, such as the aforementioned inscriptions, Bitcoin staking, BitVM co-signing, etc., it is necessary to combine aggregated signatures with threshold signatures to achieve multiple benefits.

Figure 5. Coupling of Aggregated Signatures and Threshold Signatures

As shown in Figure 5, when Alice and Bob use threshold signatures for digital asset custody, the complete private keys KeyA and KeyB do not appear, and only the corresponding private key shares appear, namely (ShareA1, ShareA2, ShareA3) and (ShareB1, ShareB2, ShareB3). At this point, threshold signatures are run based on the private key shares (ShareA1, ShareA2, ShareA3) and (ShareB1, ShareB2, ShareB3) to generate signatures SigA and SigB, respectively. Then, the signatures SigA and SigB are aggregated to produce the aggregated signature AggSig. Throughout the process, the complete private keys KeyA and KeyB do not appear. Therefore, the coupling of threshold signatures and aggregated signatures is achieved, simultaneously meeting multiple application needs.