When it comes to the BTC ecosystem, it is inevitable to mention BTC’s “cross-chain” capabilities. Unlike the EVM ecosystem, BTC’s mainnet does not have Turing-complete smart contract capabilities, so it cannot use cross-chain solutions similar to the EVM ecosystem at the moment.
In this article, I will provide a layman’s introduction to common cross-chain methods for BTC and briefly analyze their security.
1. Multi-Signature Bridge
1.1 Overview
Multi-signature is a technology that requires multiple people to sign with their private keys to complete a transaction. In a regular wallet, we only need to sign with our own private key to complete a transaction, which is known as a “1-of-1” scheme. In a multi-signature wallet, because multiple people’s private keys are required to sign, it enhances security. Additionally, it can adopt an “m-of-n” scheme (e.g., out of 5 people, only 3 signatures are needed), reducing the risk of single point failure.
The concept of a multi-signature bridge is to deposit money into a multi-signature address and generate a mapped asset or proof of share in the corresponding chain.
1.2 Security Analysis
Note: When analyzing security, we exclude “hacker risks” and “technical code vulnerabilities.”
The biggest risk of multi-signature lies in the individuals or entities forming the multi-signature.
MS-1: Regular Multi-Signature Bridge
Security Analysis: The risk mainly comes from the composition of the multi-signature group. If the multi-signature is controlled mostly or entirely by project-related personnel, it is essentially the same as a “single signature” for users.
MS-2: Multi-Signature Bridge with Background Individuals/Entities
Security Analysis: In this case, security will be better, as it is a multi-signature with background individuals/entities, reducing the possibility of malicious actions (considering reputation factors). However, if the potential profit is significant, collusion among multiple parties is still possible. It would be better to involve regulated institutions.
MS-3: Decentralized Multi-Signature Participants + Randomly Selected Multi-Signature Bridge
Security Analysis: Many people are concerned about the composition of multi-signature participants. By introducing a sufficient number of multi-signature participants and striving for “decentralization,” then randomly selecting multi-signature participants as validators during the actual operation process, security can be improved. However, we need to observe the degree and authenticity of this “decentralization” to avoid superficial measures.
2. MPC (Multi-Party Computation)
2.1 Overview
MPC is a technique that uses multi-party computation to protect transactions. In simple terms, a multi-signature scheme requires multiple people’s private key signatures, while an MPC scheme splits a private key into many parts, encrypts them, and distributes them to multiple individuals. When a transaction is required, an individual brings their part, and everyone calculates using the same function algorithm to approve the transaction. This technology can also be combined with multi-signature, where M out of N parts can form a valid signature.
MPC is a more advanced technology compared to multi-signature, but it also has controversy. For example, “accountability.” From an outsider’s perspective, it is impossible to distinguish who performed the MPC signature, so accountability becomes a significant issue in case of problems.
2.2 Security Analysis
MPC is similar to multi-signature but has some differences. The main risk lies in the individuals forming the MPC and the risk of leaking computing function parameters.
MPC-1: Regular MPC
Security Analysis: If the MPC participants are mainly project-related or have vested interests, there is a possibility of rugpull at any time.
MPC-2: MPC with Background Individuals/Entities as Participants
Security Analysis: Security will be relatively better, but if the potential profit is significant, collusion among multiple parties is still possible.
MPC-3: Introducing Decentralized Participants and Utilizing TEE (Trusted Execution Environment)
Security Analysis: If decentralized witnesses are fully introduced and randomly selected, and signatures are performed within the TEE, security will be improved to a considerable extent. Additionally, various methods such as random selection functions and hiding witness information can be introduced to enhance security in other dimensions.
Unified Risk: TEE Parameter Leakage
If TEE parameters are leaked during the generation of computing functions or if the TEE environment used as a participant is compromised or maliciously leaked, the entire security system becomes ineffective.
3. DLC (Discreet Log Contracts)
3.1 Overview
DLC stands for Discreet Log Contracts, which is a concise assertion contract scheme proposed by Tadge Dryja of MIT in 2018.
For example, A and B make a bet that if the BTC price reaches $100,000 tomorrow, A will give 1 BTC to B, and if it doesn’t, B will give 1 BTC to A. They utilize DLC off-chain to generate such a contract and fund it with signatures. However, this transaction is invalid until it is signed by an oracle, which acts as an assertion machine (similar to the role of Chainlink). When the oracle provides information and signs it, the DLC contract will execute. For example, if the BTC price reaches $100,000, A’s 1 BTC in the funding will transfer to B.
Interestingly, DLC allows the oracle to have no knowledge of the contract content. The oracle only needs to provide data, which reduces the possibility of oracle manipulation to some extent.
3.2 Security Analysis
The main risk of DLC lies in the oracle.
DLC-1: Regular DLC (Oracle provided by the project)
Security Analysis: If the oracle is provided by the project, it is generally only used in the testing phase. If used in the main network, security entirely depends on the project’s malicious intent.
DLC-2: Introduction of Third-Party Oracles
Security Analysis: In this case, security will be improved, especially when using well-known third-party oracles. The potential issue is the risk of oracle attacks or errors. However, collusion risks still exist.
DLC-3: Introduction of Multiple Third-Party Oracles
Security Analysis: In this case, security is further enhanced, avoiding the risk of single point failure.
Of course, other techniques such as OP can be added to enhance security.
DLC is an interesting solution, but currently, there doesn’t seem to be specialized oracles for DLC. Also, one issue is that the oracle needs to pre-sign all possible scenarios, making it cumbersome.
4. Time Lock
4.1 Overview
In principle, time locks do not fall under the category of “cross-chain.” They enable “pledging” functionality. However, because they allow native pledging on BTC and the pledged assets can be transferred using other methods, they are discussed here as a form of cross-chain.
As the name suggests, a time lock is a lock with conditions related to time. Specifically, it is a lock that can only be opened after a time event occurs. BTC has both “absolute time locks” and “relative time locks.” The former specifies a specific time point (e.g., a date or block height) for unlocking, while the latter specifies a time delay (e.g., a number of blocks) for unlocking.
For example, we can define that money can only be spent after block height 385,421, which is an absolute time lock. We can also define that money can only be spent after receiving 6 confirmations, which is a relative time lock.
Time locks have various functionalities, such as:
1) Forced storage, similar to fixed deposits. If you are afraid of spending your BTC, you can put it in an address with a time-lock script and can only withdraw it after a certain period.
2) Unexpected disaster recovery. For example, if you have BTC assets but are concerned about unforeseen circumstances, you can use multi-signature to set up your private key to directly spend the BTC. However, if it remains untouched for a year, several other private keys can be used to spend the BTC.
3) Trustless arbitration. In the case of disputes requiring arbitration, a relative time lock can be set up to provide a trustless arbitration solution.
4) …
4.2 Security Analysis
Time locks are a native technology for BTC and mainly used for pledging. As for pledging, it is about unlocking at maturity, and the control remains in the hands of the user, so it is equivalent to the security of the mainnet.
However, there may be slashing measures in some pledging projects, and the risk lies in asset loss due to false slashing reports.
5. BitVM
5.1 Overview
BitVM technology is likely to be familiar to many people. In simple terms, it combines existing opcodes to provide BTC’s mainnet with Turing-complete (though not entirely) capabilities, sufficient to meet existing needs. This technology is complex in terms of implementation and deployment, but due to its enormous potential, it is still highly regarded.
In terms of cross-chain, if ZK bridges or OP bridges can be implemented based on BitVM, it can achieve the same level as the EVM ecosystem.
5.2 Security Analysis
If implemented, security will be unquestionable. However, the implementation process needs to be observed, and currently, it seems challenging.
6. Covenants
6.1 Overview
Covenants are mechanisms that allow conditions to be set for future Bitcoin transactions. They can be understood as opcodes within the BTC system, including existing ones, under review, and deprecated ones. These script opcodes are essential for BTC’s expansion capabilities. It is natural to think that if more opcodes can be enabled, it would enhance scalability and achieve native cross-chain capabilities. However, introducing new opcodes or restrictions may lead to unforeseen abuses or vulnerabilities, so the community is cautious about it.
Additionally, upgrading covenant-related functionalities would require a soft fork upgrade of consensus rules. Considering the situation during the Taproot upgrade, upgrading covenant-related functionalities might also take a long time to complete.
For example, OP_CAT, which has recently gained a lot of attention, can indeed enhance BTC’s expansion capabilities. However, the potential unknown risks make it unlikely to be approved.
6.2 Security Analysis
In fact, it is currently impossible to analyze the security of this solution as there is no specific plan yet. It is just a possibility. However, in principle, if this solution can be implemented, it will be relatively native and have higher security.
7. Conclusion
The diversity of cross-chain methods in the BTC ecosystem shows that industry professionals are attempting to solve this problem through various means. Due to the lack of scalability, many “tricks” are being explored.
Currently, the main cross-chain method is achieved through multi-signature. Although regular multi-signature schemes carry asset risks and do not align well with the concept of “owning asset control,” they are relatively simple and convenient, making them the preferred method for many projects. We can also see some projects optimizing multi-signature-based solutions.
Fortunately, we are also witnessing more native cross-chain solutions in the BTC ecosystem. They focus on “asset security” as BTC is considered the highest-quality asset, and secure cross-chain capabilities allow BTC holders to invest with peace of mind.
For specific projects and technical analysis in this field, it is recommended to refer to the publications of GeekWeb3.
