Original title: BIP-327 MuSig 2 in Four Applications: Inscription, Bitcoin Restaking, BitVM Co-sign, and Digital Asset Custody
Original author: Qin Wang (CSIRO), Cynic (Chakra), mutourend (Bitlayer), lynndell (Bitlayer)
This article introduces the application of BIP-327 MuSig 2 multi-signature protocol in the four most popular fields (Inscription, Restaking, BitVM co-sign, Custody).
1 Introduction
Existing Bitcoin transactions use CheckMultiSig to verify n-of-n multi-signatures, which results in the need to publish signatures and public keys proportional to the number of signatories in the transaction on the Bitcoin blockchain. This approach not only reveals the transaction The total number of participants, and the transaction fee will increase with the number of signatories. To solve this problem, in 2018, researchers proposed the Schnorr multi-signature protocol: Musig. However, this protocol requires three rounds of Communication, the user experience is relatively poor, resulting in the protocol not attracting widespread attention and application.
In 2020, with the launch of MuSig 2, interactive signatures have made significant progress: reducing three rounds of communication to two rounds, bringing a better experience to users. In addition, MuSig 2 allows a group of users to jointly generate a single signature. Schnorr multi-signature (MuSig 2) is a blockchain-based blockchain that uses a public key to verify transactions, which improves privacy and significantly reduces transaction fees. After more than three years of continuous improvement, Schnorr multi-signature (MuSig 2) has been implemented on wallets and devices.
The relevant proposals for MuSig 2 are as follows:
2022 Bitcoin BIP-327: MuSig 2 for BIP 340-compatible Multi-Signatures
Recently https://github.com/achow101/bips/commits/musig2/ , it has been merged into the Bitcoin BIP library.
The Bitlayer and Chakra research groups found that with the prosperity of inscriptions, Bitcoin pledge, BitVM and digital asset custody, BIP-327 MuSig 2 has great application potential. In theory, it supports an unlimited number of signatories to participate in transactions, which can save on-chain space, Reduce transaction fees, improve security, privacy and operability, etc.
Inscription: Inscription is the process of writing custom content into the Bitcoin Satoshi. This concept has gained widespread attention due to its ability to create an unalterable and verifiable record of information directly on the blockchain. Inscriptions can be Simple text to complex data structures provide a reliable method to authenticate the authenticity and provenance of digital assets. The permanence and security of blockchain inscriptions make it a great choice for digital identity authentication, proof of ownership, and timeliness of critical information. For inscriptions, MuSig 2 can increase the signing and verification rate, reduce the transaction fees required in the minting process, and provide the necessary security for off-chain indexers, thereby improving The reliability of the overall inscription ecosystem.
Bitcoin staking: A mechanism by which Bitcoin holders redistribute their staked assets to support various blockchain protocols or decentralized finance (DeFi) applications. This process allows Bitcoin to play a variety of roles in the blockchain ecosystem. 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 has promoted a more integrated and efficient blockchain economy. Since Bitcoin lacks the contractual capabilities required to achieve liquidity pledge, and the UTXO architecture is not well compatible with the withdrawal function of any denomination of pledged tokens. Therefore, MuSig 2 is needed to implement liquid staking of Bitcoin.
BitVM: A framework for implementing smart contract functionality on the Bitcoin network. Unlike the Ethereum Virtual Machine (EVM), which natively supports complex smart contracts, BitVM is designed to extend Bitcoins scripting capabilities to allow for more complex programmable transactions. The development of BitVM has opened up new avenues for Bitcoin’s decentralized applications (dApps) and complex financial applications, breaking through the limitations of its simple scripting language. The introduction of BitVM marks an important evolution in Bitcoin’s practicality. It can build a bridge between other more flexible smart contract platforms. Without the need for soft forks, BitVM needs to pre-sign to achieve 1-of-n trust assumptions and permissionless challenge functions. In order to minimize the trust assumptions, Let n be as large as possible. However, the existing CheckMultiSig script requires extremely high transaction fees to verify large-scale multi-signatures, making it infeasible. MuSig 2 can make n as large as possible, so that the value of n is not limited to bits. The blockchain is not limited by the coin block and stack size, but depends on the actual limit on the number of cosigners that can be coordinated, and the fee is low.
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 cyber threats. Threshold signature plays a key role in the security management of digital assets. It manages encryption keys in a distributed manner. This technology divides the private key into multiple shares and distributes them to different participants. To sign a transaction or To access digital assets, a predetermined threshold number of shares must be combined, ensuring that no single party can unilaterally control or abuse the assets. This enhances security by mitigating the risks of key compromise, insider threats, and single points of failure. In addition, threshold signatures It provides 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 MuSig 2 can simultaneously meet the needs of inscription, Bitcoin staking, BitVM co -sign, digital asset custody and other application needs, achieving four benefits with one fish.
2. MuSig 2 Principles and Implementation Specifications
2.1 MuSig 2 Principle
2.2 MuSig 2 Implementation Specification
Recently, Bitcoin Core contributor Andy Chow proposed several BIP proposals:
BIP-328: Derivation Scheme for MuSig 2 Aggregate Keys [Application Layer]: Describes building BIP 32 extended public keys based on BIP 327 MuSig 2 aggregate public key, and using these BIP 32 extended public keys for key derivation.
BIP-373: MuSig 2 PSBT Fields [Application Layer]: Adds fields for random numbers, public keys, and partial signatures in BIP 174 Partially Signed Bitcoin Transaction (PSBT).
BIP-390: musig() Descriptor Key Expression [Application layer]: Provides a method for transaction outputs controlled by a MuSig 2 wallet.
This is a necessary step towards MuSig 2 adoption and wallet integration. These BIPs and specs are all that is needed to integrate MuSig 2 wallets. Additionally, many wallet developers and collaborative custodian solutions (see Getting Taproot ready for multisig ) have long been Request for standardization of the MuSig 2 protocol. Now, with a formal BIP in place, the community can review it themselves, provide feedback, and help raise awareness.
3. MuSig 2: One fish, four ways to eat it
3.1 Inscription
The most typical application of inscriptions is to construct BRC 20, which can be regarded as an NFT token on Bitcoin. Its core design is to burn data on each satoshi through the Ordinals protocol and implement simple operations. , there are three steps here.
The first step is to track the uniqueness of each Satoshi. Since Satoshi is the smallest and indivisible unit of Bitcoin, and the total number of Bitcoins is 21 million, the upper limit of available Satoshi is 2.1 quadrillion. Each satoshi is a unique entity 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 will be used in a first-in, first-out manner. In this way, the satoshis are managed 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 the example shows satoshis #1, #11, and #31.
The second step is to embed messages into Satoshi using JSON format and Taproot script. These messages are stored in SegWit fields, making the process efficient and secure. The script embeds JSON into Satoshi, i.e., into the OP field. OP_IF starts the conditional judgment, and the embedded The content will be arranged after the OP_FALSE field. This condition 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 embedded content shown in Figure 1 contains the deployment of BRC 20 The key parameters of the token. It specifies the protocol as brc-20, the operation type as deploy, the token symbol as ordi, the maximum supply as 21 million, and the minting limit as 1000. Here, this process is supported Key BIPs include Schnorr Signature (BIP 340), Taproot (BIP 314), and Tapscript (BIP 342), as well as SegWit (BIP 141).
The third step, identifying BRC 20 tokens, involves the off-chain state managed by indexers. These indexers parse and interpret the state of BRC 20 tokens based on historical transactions. They parse the on-chain data, check the token state, and update the balance. Ensure that the information is up to date. In addition, the light client consolidates this information, allowing users to seamlessly identify and manage their BRC 20 tokens.
Figure 1. Key steps of BRC 20 tokens
Here, the deployment and minting operations require only one transaction, while the transfer of BRC 20 tokens (i.e., the transfer operation) requires two transactions. In the first transaction, a basic requirement on-chain burn is performed to the sender, which is the same as the minting operation. Very similar. 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 deducts the corresponding amount from the senders balance, and credited to the receiver’s balance.
We can observe that Schnorr signatures have been used in Bitcoins Taproot upgrade, improving the privacy and efficiency of Bitcoin transactions. The upgraded version of Schnorr multi-signature (MuSig 2) can be very intuitively and naturally incorporated into the Taproot upgrade. , and naturally connect to the creation process of inscriptions and similar BRC 20. The newly upgraded inscriptions can improve the signature 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. The current indexer is essentially an off-chain validator, and different service providers provide their own indexer update services. The risk here comes from untrustworthiness, just like many side chains and Like Rollup service providers, users cannot trust relatively centralized service providers. Even if these indexers do not store the user’s natural funds, incorrect or delayed quotations will cause user transactions to fail. MuSig 2 provides a A multi-signature idea. A relatively decentralized and large number of validators can be introduced to jointly maintain the same indexer, and each time they jointly verify the signature at a specific node, similar to the checkpoint mechanism. Users can at least trust the honesty of the indexer before the signature is made. In this way, MuSig 2 provides the necessary security for off-chain indexers, thereby improving the reliability of the overall inscription ecosystem.
3.2 Bitcoin Staking
Unlike Ethereum and other PoS chains that have native staking mechanisms, Bitcoin is a blockchain maintained by the PoW consensus mechanism and requires additional mechanisms to implement the staking function. Currently, the most well-known Bitcoin staking solution is the one proposed by Babylon.
In the Babylon pledge mechanism, users complete the pledge through the BTC pledge script defined by Babylon, which is called a pledge transaction and generates a pledge output. The pledge output is a Taproot output, and the internal key is disabled by setting it to NUMS points. There are three available script paths: Realize the pledge function. They are:
Time lock path: realize the lock function of pledge;
Unstaking path: realize the function of terminating the pledge 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 scheme, which improves the utility of Bitcoin assets. However, this staking has damaged the liquidity of Bitcoin to a certain extent. Years of exploration have paved the way for Bitcoin staking, and this problem can be solved by using liquid staking.
Liquidity staking introduces a new role, namely the custodian of assets. Users deposit assets into the custodian address of the liquidity staking project and receive a corresponding proportion of Liquid Staking Token (LST). The collected assets are staked natively, and LST holders automatically share the staking benefits. In addition, LST holders can directly trade LST in the secondary market, or burn LST in exchange for native staked assets.
Liquidity pledge on Ethereum can be achieved through smart contracts. However, Bitcoin lacks the contractual capabilities required to achieve liquidity pledge, and the UTXO architecture is not well compatible with the LST arbitrary denomination withdrawal function. Currently, due to contracts such as OP_CAT, The opcode is not live, so it is not possible to effectively enforce restrictions on how Bitcoin transaction outputs can be spent in the future. Therefore, MuSig 2 is needed to implement liquidity staking for Bitcoin.
As shown in Figure 2, in Chakra Liquidity Staking, the user first transfers Bitcoin to a multi-signature address supported by MuSig 2. This event is captured by the Indexer, which calls the on-chain contract to mint ckrBTC for the user. The Bitcoin in ckrBTC will be staked in Babylon. While holding ckrBTC, users can also continue to receive the income from Babylon staking. When users want to end the staking, they can destroy ckrBTC. After the indexer detects the destruction event, it will perform the unstaking operation. Return Bitcoin to users. In addition, users can also trade ckrBTC directly in the secondary market and exchange it for Bitcoin.
Figure 2. Chakra liquidity staking process
Compared with self-custody staking, the liquidity staking supported by MuSig 2 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.
3.3 BitVM Cosign
Robin Linus published the BitVM: Compute Anything on Bitcoin white paper in October 2023, using Lamports one-time signature to implement a stateful Bitcoin script. The system can be implemented through an optimistic challenge mechanism without introducing soft forks such as new opcodes. Implementing Turing-complete Bitcoin contracts. The system uses only NAND gate binary circuits built with OP_BOOLAND and OP_NOT opcodes, demonstrating the challenge mechanism for verifying arbitrary calculations on Bitcoin, but the circuits compiled by the program are so large that they are almost impractical. Subsequently, BitVM 1 used RISC-V instructions to express programs, making full use of all opcodes in the Bitcoin system to improve efficiency.
BitVM 2 extends BitVM 1 in two aspects. (1) The challenger in BitVM 1 is a member of the alliance that participated in the initial setup, while the challenger in BitVM 2 is an arbitrary participant. Therefore, the alliance members in BitVM 1 have the possibility of collusion. The risk of malicious behavior is eliminated, while the challenger of BitVM 2 is permissionless, and the alliance members cannot collude to commit malicious acts. (2) BitVM 1 requires multiple rounds of challenges, which takes a long time, while BitVM 2 makes full use of the simplicity of ZK Proof and Taptree scripts. The challenge cycle is only 2 rounds, which reduces the number of transactions required to be pre-signed during peg-in from about 100 to about 10. Specifically, BitVM 1 needs to use the binary search method and multiple rounds of interaction to find the RISC-V instructions that are incorrectly executed in the program; BitVM 2 no longer verifies the program itself, but the ZK proof that the program is executed correctly. The ZK verification algorithm will be divided 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, BitVM 2 requires a large number of n-of-n pre-signatures. Since users do not know which Operator will pay for them, before initiating a Peg-in transaction, the BitVM Alliance needs to check Take 1, Take 2, Assert , Disprove and Burn transactions are pre-signed in n-of-n format. Only after the user confirms that all the descendant transactions have been pre-signed, will the funds be deposited into the n-of-n multi-signature control address through the Peg-in transaction. When a user wants to withdraw funds, he can initiate a Peg-out transaction, and one of the Operators will pay for it, so that the withdrawal can be completed.
The Operator needs to pledge 2 BTC to get reimbursed for the Bitcoins paid in advance. If no one challenges, the Operator can successfully get reimbursed through the Take 1 transaction. If the Operator does something malicious, anyone can raise 1 BTC to challenge. If the Operator does not respond, the Burn transaction is executed, that is, 1.9 BTC is destroyed, and the remaining 0.1 BTC is given to the receiving address in the Burn transaction; if the Operator responds, the Assert transaction is executed.
Case 1: If a sub-function value reveals inconsistency, anyone can initiate a Disprove transaction, which destroys 1 BTC and gives 1 BTC to the receiving address in the Disprove transaction.
Case 2: If the sub-function value disclosure is consistent, then after 2 weeks, the Operator can be successfully reimbursed through the Take 2 transaction.
Figure 3. BitVM 2 process
In the BitVM 2 system, the BitVM Alliance is required to perform n-of-n pre-signatures on the five transactions Take 1, Take 2, Assert, Disprove and Burn. The BitVM trust assumption is 1-of-n, where the larger the n value, the more likely it is that the transaction will be signed. The larger the number of signatures, the lower the trust assumption. However, such a large-scale multi-signature requires extremely high transaction fees, making it almost impossible to implement on Bitcoin. MuSig 2 can aggregate a large number of multi-signatures into one signature, minimizing transaction fees. And the theoretically supported n value is infinite, 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, after the Peg-in is set up, at least one of the n cosigners is required to delete the private key. This makes the funds in the BitVM bridge only After being honestly paid by the Operator, the reimbursement transaction is used for spending, thus improving the security of the BitVM bridge.
3.4 Digital Asset Custody
Aggregate signatures allow multiple signatures to be combined into one signature, thus simplifying the verification process and improving efficiency. As shown in Figure 4, Alice uses the complete private key KeyA to generate the signature SigA, and Bob uses the complete private key KeyB to generate the complete signature SigB. Then SigA is combined with SigB aggregates and generates an 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 Together, Bob and I can achieve safer and more efficient digital asset management, prevent single points of failure and malicious operations, while simplifying 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 one piece. 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 part of the private key fragments are leaked, the attacker Still, a valid signature cannot be generated. In addition, threshold signatures can prevent single point failures and ensure the robustness and continuity 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 (MuSig 2) to multi-sign a transaction, such as the above-mentioned inscriptions, Bitcoin pledges, BitVM co-sign, etc. In this case, it is necessary to combine the aggregate signature with the threshold signature to kill two birds with one stone.
Figure 5. Aggregate signature coupled with threshold signature
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, but only the corresponding private key fragments appear, namely (ShareA 1, ShareA 2, ShareA 3 ) and (ShareB 1, ShareB 2, ShareB 3). At this point, threshold signatures are run based on the private key shards (ShareA 1, ShareA 2, ShareA 3) and (ShareB 1, ShareB 2, ShareB 3) to generate signatures respectively. SigA and signature SigB. Then the signature SigA and signature SigB are aggregated to generate the aggregate signature AggSig. In the whole process, the complete private key KeyA and KeyB do not appear. Therefore, the threshold signature and aggregate signature are coupled to meet multiple application requirements at the same time.
References
