introduction

Existing Bitcoin transactions use CheckMultiSig to verify n-of-n multi-signatures, which requires publishing 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 increases transaction fees as the number of signers increases. 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, improving privacy and significantly reducing transaction fees. After more than three years of continuous improvement, Schnorr multi-signature (MuSig2) has been implemented on wallets and devices.

The MuSig2 related proposals are as follows:

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.

The 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. Theoretically, it supports an unlimited number of signatories to participate in transactions, which can save on-chain space, reduce transaction fees, and improve security, privacy, and operability.

Inscription: Inscription is the process of writing customized content into the satoshi of Bitcoin. 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 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 minting process, and provide the necessary security for off-chain indexers, thereby improving the reliability of the overall inscription ecosystem.

Bitcoin re-staking: 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 re-staking, 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 functionality 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 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, 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 functionality. To keep 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: Use 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 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 inscriptions, 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 building BIP 32 extended public keys based on BIP 327 MuSig2 aggregate public key, and using 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 a MuSig2 wallet.

This is a necessary step towards MuSig2 adoption and wallet integration. These BIPs and specs are all that is needed to integrate a MuSig2 wallet. Additionally, many wallet developers and collaborative custodian 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 to Eat

Inscription

The most typical application of inscriptions is to construct BRC20, 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. 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 the example shows Satoshi #1, #11, and #31.

In the second step, the message is 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, that is, in the OP field. The OP_IF starts the conditional judgment, and the embedded 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 key parameters for deploying BRC20 tokens. It specifies the protocol as "brc-20", the operation type as "deployment", 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 off-chain states managed by indexers. These indexers parse and interpret the state of BRC20 tokens based on historical transactions. They parse on-chain data, check token states, and update balances to ensure that the information is up to date. In addition, light clients consolidate this information, allowing users to seamlessly identify and manage their 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 requirement 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. The off-chain indexer then updates the state. If the conditions are met, the indexer deducts the corresponding amount from the sender's balance and credits 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. 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 or delayed quotations will cause user 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 each time they jointly verify the signature at a specific node, 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 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 to 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 solution and improves the utility of Bitcoin assets. However, this staking has damaged the liquidity of Bitcoin to a certain extent. However, years of exploration of the Ethereum staking mechanism have paved the 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 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, since contract opcodes such as OP_CAT are not online, it is impossible to effectively restrict the future spending methods of Bitcoin transaction outputs. Therefore, MuSig2 is needed to achieve Bitcoin liquidity pledge.

As shown in Figure 2, in Chakra liquidity staking, users first transfer 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 in Babylon. While holding ckrBTC, users can 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 and exchange ckrBTC for Bitcoin.

Compared with self-custodial 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 users with more benefits.

BitVM Cosign

Robin Linus released the BitVM: Compute Anything on Bitcoin white paper in October 2023, which implemented a stateful Bitcoin script using Lamport one-time signatures. 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 built with OP_BOOLAND and OP_NOT opcodes to demonstrate a challenge mechanism for verifying arbitrary calculations on Bitcoin, but the circuits compiled by the program are large in scale and almost impossible to use in practice. Subsequently, BitVM1 used 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, while the challenger in BitVM2 is permissionless and the alliance members cannot collude to do 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 verifies the correct execution of the program. BitVM2 will divide the ZK verification algorithm into multiple sub-functions, each corresponding 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 funds for them, before initiating a Peg-in transaction, the BitVM Alliance needs to perform n-of-n pre-signatures on the five transactions Take1, Take2, Assert, Disprove, and Burn. Only after the user confirms that the pre-signatures of each descendant transaction have been completed, will the funds actually 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 funds for him, 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 Take1 transaction. If the Operator is malicious, anyone can challenge after crowdfunding 1BTC. In the face of the challenge, if the Operator does not respond, the Burn transaction will be executed, that is, 1.9BTC will be destroyed, and the remaining 0.1BTC will be given to the receiving address in the Burn transaction; if the Operator responds, the Assert transaction will be executed.

Case 1: If a sub-function value reveals inconsistency, anyone can initiate a Disprove transaction, which destroys 1BTC and gives 1BTC 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 Take2 transaction.

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, minimizing handling fees, and theoretically supports an infinite value of n, depending on the number of cosigners that can actually be coordinated, such as n 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 means that the funds in the BitVM bridge can only be spent using 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, thus 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, as 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 the complexity of transactions 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 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.

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, etc. In this case, it is necessary to combine aggregate signatures with threshold signatures to achieve multiple benefits.

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, (ShareA1, ShareA2, ShareA3) and (ShareB1, ShareB2, ShareB3), appear. At this time, threshold signatures are run based on the 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 signatures AggSig. During the whole process, the complete private keys KeyA and KeyB do not appear. Therefore, the coupling of threshold signatures and aggregate signatures is achieved 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

Welcome to BlockBeats the BlockBeats official community:

Telegram subscription group: https://t.me/theblockbeats

Telegram group: https://t.me/BlockBeats_App

Official Twitter account: https://twitter.com/BlockBeatsAsia