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

Original author: 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 transaction participants, but also the transaction fee increases with the number of signers. To solve this problem, in 2018, researchers proposed the Schnorr multi-signature protocol: Musig. However, the protocol requires three rounds of communication between signers, and the user experience is relatively poor, which has led to the protocol not attracting widespread attention and application.

In 2020, with the launch of MuSig2, interactive signatures have made significant progress: reducing three rounds of communication to two rounds, bringing a better experience to users. In addition, MuSig2 allows a group of users to jointly generate a single signature and public key to verify transactions, which improves privacy and significantly reduces transaction fees. After more than three years of continuous improvement, Schnorr multi-signature (MuSig2) has been implemented on wallets and devices.

MuSig2 related proposals are as follows:

· In 2022, Bitcoin BIP-327: MuSig2 for BIP340-compatible Multi-Signatures

· Recently https://github.com/achow101/bips/commits/musig2/, which has been merged into the Bitcoin BIP library.

Bitlayer and Chakra research groups found that with the prosperity of inscriptions, Bitcoin staking, BitVM and digital asset custody, BIP-327 MuSig2 has great application potential. In theory, it supports an unlimited number of signatories to participate in transactions, which can save on-chain space, reduce handling fees, and improve security, privacy and operability.

Inscription:Inscription is the process of writing customized content into the satoshi of Bitcoin for inscription. This concept has received widespread attention due to its ability to create tamper-proof and verifiable information records directly on the blockchain. Inscriptions can range from simple text to complex data structures, providing a reliable way 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 authentication, proof of ownership, and timestamping of key information. For inscriptions, MuSig2 can increase the signing and verification rates, reduce the transaction fees required during the casting process, and provide the necessary security for off-chain indexers, thereby improving the reliability of the overall inscription ecosystem.

Bitcoin Restaking:A mechanism by which Bitcoin holders reallocate their staked assets to support various blockchain protocols or decentralized finance (DeFi) applications. This process allows Bitcoin to play multiple roles in the blockchain ecosystem, enhancing its utility and earnings 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 to promote a more integrated and efficient blockchain economy. Since Bitcoin lacks the contractual capabilities required to achieve liquidity staking, and the UTXO architecture is not well compatible with the withdrawal function of any denomination of staked tokens. Therefore, MuSig2 is needed to achieve liquidity staking of Bitcoin.

BitVM:A framework for implementing smart contract functions on the Bitcoin network. Unlike the Ethereum Virtual Machine (EVM), which natively supports complex smart contracts, BitVM is designed to extend Bitcoin's scripting capabilities to allow for more complex programmable transactions. This development opens new avenues for decentralized applications (dApps) and complex financial applications of Bitcoin, breaking through the limitations of its simple scripting language. The introduction of BitVM marks an important evolution in the practicality of Bitcoin, building a bridge between Bitcoin and other more flexible smart contract platforms. Without the need for a soft fork, BitVM requires pre-signing to implement the 1-of-n trust assumption and permissionless challenge function. In order to make the trust assumption as small as possible, the value of n needs to be as large as possible. However, the existing CheckMultiSig script verifies large-scale multi-signatures, which requires extremely high transaction fees, making it infeasible. MuSig2 allows n to be as large as possible, so that the value of n is not limited by the Bitcoin block and stack size limits, but depends on the actual limit on the number of cosigners that can be coordinated, and the fee is low.

Digital Asset Custody:Securely store and manage digital assets such as cryptocurrencies, NFTs (non-fungible tokens), and other tokenized assets using blockchain. This involves protecting private keys, ensuring access control, and providing protection against cyber threats. Threshold signatures play a key role in the secure management of digital assets, which enables the management of cryptographic keys in a distributed manner. This technology divides private keys into multiple shares and distributes them to different participants. To sign a transaction or access a digital asset, a predetermined threshold number of shares must be combined to ensure that no single party can unilaterally control or abuse the asset. This enhances security by mitigating the risks of key leakage, internal threats, and single points of failure. In addition, threshold signatures provide a more robust and flexible governance model for digital asset management, allowing secure collaboration and decision-making in decentralized organizations and multi-party systems. Combining threshold signatures with MuSig2 can simultaneously meet the application requirements of inscription, Bitcoin staking, BitVM co-sign, digital asset custody, etc., achieving four goals with one stone.

MuSig2 Principle and Implementation Specification

MuSig2 Principle

MuSig2 Implementation Specification

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

· BIP-328: Derivation Scheme for MuSig2 Aggregate Keys [Application Layer]: Describes a new BIP protocol based on the MuSig2 protocol. BIP 327 MuSig2 aggregate public key, build BIP 32 extended public keys, and use these BIP 32 extended public keys for key derivation.

· BIP-373: MuSig2 PSBT Fields【Application layer】: Added 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 way to control transaction outputs from a MuSig2 wallet.

This is a necessary step for MuSig2 to be adopted and integrated with wallets. These BIPs and specs are all that is needed to integrate a MuSig2 wallet. Additionally, many wallet developers and collaborative custodial solutions (see Getting Taproot ready for multisig) have long requested standardization of the MuSig2 protocol. Now, with a formal BIP in place, the community can review it themselves, provide feedback, and help raise awareness.

MuSig2 One Fish Four Ways

Inscription

The most typical application of inscription is to construct BRC20, a token that can be regarded as an NFT on Bitcoin. Its core design is to burn data on each Satoshi through the Ordinals protocol and implement simple operations. In general, there are three steps.

The first step is to track the uniqueness of each Satoshi. Since Satoshi is the smallest and indivisible unit of Bitcoin, and the total amount of Bitcoin is 21 million, the upper limit of available Satoshi is 2.1 quadrillion. Each Satoshi in Bitcoin is a unique existence with uniqueness, which is the underlying logic of building NFT on Bitcoin. Here, each Satoshi will be assigned a forward serial number (through the Ordinals protocol) and managed in a first-in-first-out manner to ensure accurate tracking and orderly processing. As shown in the figure, we can see that each satoshi is part of a complete sequential sequence, and in the example, satoshi #1, #11, and #31 are shown.

In the second step, the messages are embedded in the satoshi using the JSON format and the Taproot script. These messages are stored in the SegWit field, making the process efficient and secure. The script embeds the JSON in the satoshi, i.e., in the OP field. The OP_IF starts the conditional judgment, and the embedded content will be arranged after the OP_FALSE field, which ensures that the subsequent content will not be executed and is only stored. Therefore, the newly embedded JSON is completely saved on this satoshi. The JSON embed shown in Figure 1 contains the key parameters for deploying the BRC20 token. It specifies the protocol as "brc-20", the operation type as "deploy", the token symbol as "ordi", the maximum supply is set to 21 million, and the minting limit is 1000. Here, the key BIPs supporting this process include Schnorr Signature (BIP340), Taproot (BIP314) and Tapscript (BIP342), as well as SegWit (BIP141).

The third step, identifying BRC20 tokens involves the off-chain state managed by indexers. These indexers parse and interpret the state of BRC20 tokens based on historical transactions. They parse the on-chain data, check the token status, and update the balance to ensure that the information is up to date. In addition, light clients integrate this information to make it seamless for users to identify and manage their BRC20 tokens.

Figure 1. Key steps of BRC20 tokens

Here, the deployment and minting operations only require one transaction, while transferring BRC20 tokens (i.e., transfer operations) requires two transactions. In the first transaction, a basic required on-chain burn is performed to 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. Then, the off-chain indexer updates the state. If the conditions are met, the indexer will deduct the corresponding amount from the sender's balance and credit it to the receiver's balance.

We can observe that Schnorr signatures have been used in Bitcoin's Taproot upgrade, improving the privacy and efficiency of Bitcoin transactions. The upgraded version of Schnorr multi-signature (MuSig2) can be very intuitively and naturally merged into the Taproot upgrade, and naturally connects to the creation process of inscriptions and similar BRC20. The newly upgraded inscriptions can increase the signing and verification rate on the existing basis, and further reduce the transaction fees required in the minting process.

Another application comes from the off-chain indexer part. The current indexer is essentially an off-chain validator, and different service providers provide their own indexer update services. The risk caused here comes from untrustworthiness. Just like many sidechain and Rollup service providers, users cannot trust relatively centralized service providers. Even if these indexers do not store users' natural funds, incorrect quotations or delayed quotations will cause users' transactions to fail. MuSig2 provides a multi-signature idea. A relatively decentralized and large number of validators can be introduced to jointly maintain the same indexer, and jointly verify the signature at a specific node each time, similar to the checkpoint mechanism. Users can at least trust that the indexer before the signature submits the on-chain inscription and transaction flow honestly and reliably. In this way, MuSig2 provides the necessary security for the off-chain indexer, thereby improving the reliability of the overall inscription ecosystem.

Bitcoin Staking

Unlike Ethereum and other PoS chains that have native staking mechanisms, Bitcoin is a blockchain maintained by the PoW consensus mechanism, and an additional mechanism is needed to implement the staking function. Currently, the most well-known is the Bitcoin staking scheme proposed by Babylon.

In the Babylon staking mechanism, users complete the staking through the BTC staking script defined by Babylon, which is called a staking transaction and generates a staking output. The staking output is a Taproot output, and the internal key is disabled by setting it to NUMS points. There are three available script paths to implement the staking function. They are:

· Time lock path: implement the lock function of the staking;

· Unstaking path: implement the staking function in advance;

· Confiscation path: implement the system's punishment function when doing evil.

The Bitcoin staking mechanism provides Bitcoin holders with a relatively safe interest-earning solution and improves the utility of Bitcoin assets. However, this staking has damaged the liquidity of Bitcoin to a certain extent. However, the years of exploration of the Ethereum staking mechanism have found a way for Bitcoin staking, and liquidity staking can be used to solve this problem.

Liquidity staking introduces a new role, namely the custodian of assets. Users deposit assets into the custodian address of the liquidity staking project and obtain a corresponding proportion of Liquid Staking Tokens (LST). The liquidity staking project will natively stake the collected assets, and LST holders will automatically share the staking income. In addition, LST holders can directly trade LST in the secondary market, or burn LST in exchange for native staked assets.

Liquidity staking on Ethereum can be achieved through smart contracts. However, Bitcoin lacks the contract capabilities required to achieve liquidity staking, and the UTXO architecture is not well compatible with the LST arbitrary denomination withdrawal function. Currently, since contract opcodes such as OP_CAT are not online, it is impossible to effectively implement restrictions on the future spending methods of Bitcoin transaction outputs. Therefore, MuSig2 is needed to implement Bitcoin liquidity staking.

As shown in Figure 2, in Chakra liquidity staking, the user first transfers Bitcoin to a multi-signature address supported by MuSig2. This event is captured by the indexer, and the on-chain contract is called to mint ckrBTC for the user. The Bitcoin in the multi-signature address will be staked into Babylon. While holding ckrBTC, users can also continue to receive the benefits of Babylon staking. When the user wants to end the staking, he can destroy ckrBTC. After the indexer detects the destruction event, it will perform the unstaking operation and return the Bitcoin to the user. In addition, users can also trade directly in the secondary market to exchange ckrBTC for Bitcoin.

Figure 2. Chakra Liquidity Staking Process

Compared with self-custody staking, the liquidity staking supported by MuSig2 introduces multiple participants to maintain the security of digital asset custody, and at the same time releases the liquidity of pledged Bitcoin, allowing LST to play a greater role in BTCFi, thereby providing more benefits to users.

BitVM Cosign

Robin Linus released the BitVM: Compute Anything on Bitcoin white paper in October 2023, using Lamport one-time signatures to implement stateful Bitcoin scripts. The system can implement Turing-complete Bitcoin contracts through an optimistic challenge mechanism without introducing soft forks such as new opcodes. The system only uses NAND gate binary circuits constructed with OP_BOOLAND and OP_NOT opcodes to demonstrate a challenge mechanism for verifying arbitrary calculations on Bitcoin, but the circuit compiled by the program is large in scale and almost impossible to use in practice. Subsequently, BitVM1 uses RISC-V instructions to express programs, making full use of all opcodes in the Bitcoin system to improve efficiency. BitVM2 extends BitVM1 in two aspects. (1) The challenger in BitVM1 is a member of the alliance who participated in the initial setup, while the challenger in BitVM2 is an arbitrary participant. Therefore, the alliance members in BitVM1 are at risk of collusion to commit evil, while the challenger in BitVM2 is permissionless and the alliance members cannot collude to commit evil. (2) BitVM1 requires multiple rounds of challenges, which takes a long time, while BitVM2 makes full use of the simplicity of ZK Proof and the script expression ability of Taptree. The challenge cycle is only 2 rounds, reducing the number of transactions required to be pre-signed during peg-in from about 100 to about 10. Specifically, BitVM1 needs to use the binary search method and find the RISC-V instructions that are incorrectly executed in the program after multiple rounds of interaction; BitVM2 no longer verifies the program itself, but the ZK proof that the program is executed correctly. BitVM2 will cut the ZK verification algorithm into multiple sub-functions, each of which corresponds to a Tapleaf. When challenged, the Operator needs to reveal the values of each sub-function. If there is any inconsistency, anyone can initiate a Disprove transaction to punish it.

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 the payment for them, before initiating a Peg-in transaction, the BitVM Alliance needs to perform n-of-n pre-signatures on the five transactions of Take1, Take2, Assert, Disprove, and Burn. Only after the user confirms that the pre-signature of each descendant transaction is completed, the funds will be deposited into the n-of-n multi-signature control address through the Peg-in transaction. When the user wants to withdraw funds, he can initiate a Peg-out transaction, and one of the Operators will advance the payment for him, so that the withdrawal can be completed.

The Operator needs to pledge 2 BTC before it can reimburse the Bitcoins that were advanced. If no one challenges, the Operator can successfully reimburse through the Take1 transaction. If the Operator does evil, anyone can initiate a challenge after crowdfunding 1BTC. In the face of the challenge, if the Operator does not respond, the Burn transaction is executed, that is, 1.9BTC is destroyed, and the remaining 0.1BTC is given to the receiving address in the Burn transaction; if the Operator responds, the Assert transaction is executed.

· Case 1: If the value of a sub-function is inconsistent, anyone can initiate a Disprove transaction, that is, 1BTC is destroyed, and 1BTC is given to the receiving address in the Disprove transaction.

· Case 2: If the value of the sub-function is consistent, then after 2 weeks, the Operator can be successfully reimbursed through the Take2 transaction.

Figure 3. BitVM 2 process

In the BitVM2 system, the BitVM alliance is required to perform n-of-n pre-signatures on the five transactions Take1, Take2, Assert, Disprove and Burn. The BitVM trust assumption is 1-of-n, where the larger the n value, the lower the trust assumption. However, such a large-scale multi-signature requires extremely high handling fees, making it almost infeasible on Bitcoin. MuSig2 can aggregate a large number of multi-signatures into one signature, minimize handling fees, and theoretically support an infinite value of n, depending on the number of cosigners that can actually be coordinated, such as n value of 1000 or even larger.

When BitVM is deployed, in order to prevent the BitVM alliance from spending through n-of-n multi-signature collusion, at least one of the n cosigners is required to delete the private key after the Peg-in is set up. This allows the funds in the BitVM bridge to be spent only through reimbursement transactions after the Operator has paid honestly. Therefore, the security of the BitVM bridge is improved.

Digital Asset Custody

Aggregate signatures allow multiple signatures to be combined into one signature, thereby simplifying the verification process and improving efficiency. As shown in Figure 4, Alice uses the full private key KeyA to generate the signature SigA, and Bob uses the full private key KeyB to generate the full signature SigB. SigA is then aggregated with SigB to generate the aggregate signature AggSig. This approach not only ensures the independence and responsibility of each participant, but also enhances the security of the overall system because the participation of both parties is required for any authorized operation. Through this collaboration, Alice and Bob are able to achieve safer and more efficient digital asset management, prevent single points of failure and malicious operations, and simplify transaction complexity and verification costs.

On the other hand, Alice uses threshold signatures to generate and manage digital signatures using distributed devices, and no single device can have full signing capabilities. Specifically, the threshold signature scheme divides the private key into several pieces, and each device stores a piece of the private key. A valid signature can only be generated when and only when a certain number of devices (i.e., reaching the threshold value) cooperate. This mechanism greatly improves the security of digital assets, because even if some private key shards are leaked, the attacker still cannot generate a valid signature. In addition, threshold signatures can prevent single points of failure and ensure the robustness and sustainability of the system. Therefore, threshold signatures provide an efficient and secure solution for distributed management of digital assets.

Figure 4. Aggregate signature, threshold signature

When Alice and Bob both use threshold signatures to manage their respective digital assets, and need to use aggregate signatures (MuSig2) to perform multiple signatures on a transaction, such as the above-mentioned inscriptions, Bitcoin pledges, BitVM co-sign and other applications. In this case, it is necessary to combine aggregate signatures with threshold signatures to achieve one-fish-two-kills-two-kills.

Figure 5. Coupling of Aggregate Signature and Threshold Signature

As shown in Figure 5, when Alice and Bob use threshold signature for digital asset custody, the complete private keys KeyA and KeyB do not appear, but only the corresponding private key fragments appear, namely (ShareA1, ShareA2, ShareA3) and (ShareB1, ShareB2, ShareB3). At this time, threshold signatures are run based on private key fragments (ShareA1, ShareA2, ShareA3) and (ShareB1, ShareB2, ShareB3) to generate signatures SigA and SigB respectively. Then, signatures SigA and SigB are aggregated to generate aggregate signature AggSig. In the whole process, the complete private keys KeyA and KeyB do not appear. Therefore, the coupling of threshold signature and aggregate signature is realized to meet multiple application requirements at the same time.

References

2021. MuSig2: Simple Two-Round Schnorr Multi-Signatures

2022. BIP-327: MuSig2 for BIP340-compatible Multi-Signatures

2020. BIP-340 : Schnorr Signatures for secp256k1

2023. Forgery with a fake key in MuSig2

2023. BitVM whitepaper

2024. BitVM 2: Permissionless Verification on Bitcoin

2024. Chakra x Babylon Staking Testnet: Technical Overview & Security Analysis

「Original source」

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方账号：https://twitter.com/BlockBeatsAsia