5. Bridging Bitcoin and Bitlayer Network 5.1 Integration of the BitVM Bridge A secure and reliable method for managing user assets is essential for rollup solutions. Among known approaches, the BitVM bridge stands out due to its robust architecture and practicality. The BitVM bridge securely facilitates the transfer of BTC from the Bitcoin network to Bitlayer, where it is represented as a native asset called YBTC. Additionally, the bridge ensures secure and efficient asset withdrawals back to Bitcoin, providing users a trustworthy exit mechanism. In our design, each user's deposit corresponds to an individual BitVM smart contract instance. Deposited funds are locked by the presign committee's address, and an equivalent amount of YBTC is minted on Bitlayer. Liquidity providers can participate in these contract instances by redeeming BTC from the smart contracts, submitting appropriate proofs that include the associated 'Burn' transaction on Bitlayer and its corresponding claim on Bitcoin. You can learn more about Bitcoin-based claim verification here. 5.2 Roles The BitVM protocol defines four primary roles—User, Broker, Attester, and Watcher—to ensure correctness and security. Users hold assets either as BTC on the Bitcoin network or YBTC on Bitlayer. When depositing assets, users interact with Brokers to obtain and verify necessary transaction information. Under normal conditions, users withdraw funds by initiating a Burn transaction on Bitlayer. In emergency scenarios, users directly issue a force inclusion transaction on the Bitcoin network.

After extensive consideration, the opcode OP_CTV (CheckTemplateVerify) has been well understood by the Bitcoin community and its developers now. As a result, Jeremy Rubin has expressed his support for a covenant upgrade plan aimed at activating OP_CTV. Soon after that announcement, Robin claimed his support for OP_CTV too. In this article, I am trying to explain Why OP_CTV is important to the BitVM bridge, and the key points for implementing BitVM bridge with OP_CTV BitVM Bridge Below figure shows The original BitVM transation graph: image the key point for implementing BitVM bridge is the committee. It forces all transactions of that graph should follow the specifed order. Otherwise the graph is broken and the fund that is locked in the transaction graph is in danger. Due to the committee, it based on 1-of-n honesty assumption, which means at least there is one honest member of committee, the bridge is safe. More information about BitVM bridge can be found here But that is also the biggest limitation of committee. the committee has to get involved a lot of members. Otherwise it will be hacked easily if all of the members are controlled. More and more members join the committee, the cost of communication will become higher and interaction between each other will become more complex. It is a tradeoff between cost and safety finally. If OP_CTV is activated, the committee is unnecessary, because all transactions of that graph can be forced to follow the specified order by OP_CTV. Efficiency and cost will be improved highly then. Even the OP_CTV is activated, the way to implement BitVM bridge may still not very intuitive. Then two key concepts will be introduced.

Overview After extensive consideration, the opcode OP_CTV (CheckTemplateVerify) has been thoroughly studied, reviewed, and is now well understood by the Bitcoin community and its developers. As a result, Jeremy Rubin has expressed his support for a covenant upgrade plan aimed at activating OP_CTV. It is possible that developers may not have to wait much longer before this feature is officially activated. The BitVM bridge, on the other hand, seeks to establish a trust-minimized bridge system between Bitcoin and various sidechains or sidesystems. Historically, implementing covenants in Bitcoin has typically relied on mechanisms such as a presigning committee, which ensures that transactions are submitted in a predetermined manner. However, this approach often introduces trust assumptions and operational complexity. For those interested in the technical details of how the BitVM bridge works, further information can be found here. While the latest design of the BitVM bridge has undergone significant changes compared to earlier iterations, it still retains the fundamental principles and key insights necessary for its implementation. Furthermore, it can be used as a reference example to demonstrate a potential approach for implementing the BitVM bridge with the use of OP_CTV. In the end, a demo is provided for you to see how the BitVM bridge may work in practice. OP_CTV OP_CTV, also known as OP_CHECKTEMPLATEVERIFY, is a Bitcoin opcode with a straightforward yet powerful function. It verifies whether the element at the top of the stack matches the DefaultCheckTemplateVerifyHash of the transaction itself. The DefaultCheckTemplateVerifyHash represents a novel approach to computing the digest of a transaction, designed to facilitate more efficient and predictable transaction processing. This digest calculation is particularly noteworthy because it commits to specific fields of a transaction in a carefully chosen order, prioritizing fields that are least likely to change and progressing to those that are more dynamic nVersion nLockTime

image

The Bitlayer BitVM Bridge is a Bitcoin bridging solution optimized based on BitVM2 protocol, which leverages Bitcoin’s security and efficiency for cross-chain interactions using n-of-n multisignature and zero-knowledge proofs (ZKP). How does Bitlayer BitVM Bridge work? You can gain a comprehensive understanding of Bitlayer BitVM Bridge architecture by reading this blog. This document provides a detailed description of the audit scope, which is divided into two main sections: Bridge Contract A (Deployed on Bitcoin) and Bridge Contract B (Deployed on Ethereum). Bridge Contract A Bridge Contract A is essentially a set of Bitcoin transactions (which we will refer to as the TransactionGraph), as shown in the diagram below. image Different colored dashed boxes represent the presigning actions of different roles and the scope of their presigned transactions.

The demo is shown below: image First of all, two types of inputs are defined:. Fund Input: This input holds a significant amount of funds and is secured using an OP_CTV script Logic Input: This input contains only a minimal "dust" amount and is spent through a P2SH script signature (script_sig) Some transactions in the figure have both two types of inputs, such as happytake, unhappytake and disprove

Overview Bitlayer is developing Bitlayer BitVM Bridge based on BitVM2 and is currently in the audit phase. We are seeking to establish partnerships with audit service providers. You can gain a comprehensive understanding of Bitlayer BitVM Bridge architecture by reading this blog. We look forward to further discussions on the audit scope, requirements, service fees, and payment methods. Scope The code is divided into two repos:

Reusable collateral could be one of the most valuable enhancements to the BitVM bridge. By significantly improving capital efficiency, it allows multiple reclaims to share the same deposit. In that case, the operator is not required to prepare separate UTXOs for each individual reclaim, resulting in substantial cost savings. reusable collateral transactions It introduces a new feature that the time transaction is linked to the kickoff transaction of each reclaimable transaction graph. This means the operator can only initiate a reclaim in the order dictated by the sequence of time transactions. But only one operator can submit pegout successfully each round, others have to wait for a certain period to enter next relcaim However, some challenges still need to be addressed for this new feature. If the reclaimable transaction graph is invalid, such as when the related Pegin was not successfully submitted to the Bitcoin network, it will have a more significant impact on other reclaims compared to disabling reusable collateral. This is because subsequent transactions are directly affected by this issue. Even if the reclaimable transaction graph is invalid, the following time transactions are still required to wait for the corresponding timeout period ($\Delta T$) to elapse before they can be initiated. This enforced delay introduces inefficiencies and further exacerbates the impact on the overall reclaim process. To enhance the convenience and flexibility of withdrawals, the reclaimbale utxo(the UTXO received by the operator after the reclaim process) should ideally have varying denominations, such as 1 BTC, 2 BTC, or 5 BTC, and so forth. However, it is inherently challenging for the operator to predict which denomination a user might choose to utilize. This unpredictability makes it difficult for the operator to arrange the sequence of reclaimable UTXOs in a logical or optimal order. As a result, users are left with no alternative but to accept the reclaimable UTXO that the operator is capable of processing at that particular point in the sequence. This limitation restricts user flexibility and could lead to inefficiencies in the withdrawal process.

<span style="display:block;text-align:center;">TapSTARK: ZK-STARKs on Bitcoin Without Protocol Upgrade</span> <span style="display:block;text-align:center;">Bitlayer Research Team</span> <span style="display:block;text-align:center;">December, 2024</span> Abstract: TapSTARK is a protocol that implements native STARK verification on Bitcoin without requiring additional upgrades. We replace the Merkle tree in the FRI PCS (Polynomial Commitment Scheme) with Bitcoin's native Taptree. However, there are differences between Taptree and the Merkle tree. We use cryptographic tools—bit commitments—to implement data commitments, addressing the differences. Additionally, the consistency of the involved algebraic equations, value consistency, and the transformation of Fiat-Shamir are verified to ensure verification integrity. The scheme allows for Merkle path verification without incurring gas fees and eliminates the need to construct a Merkle tree on-chain, thus avoiding reliance on non-standard instructions (such as OP_CAT for string concatenation). We first introduce some background knowledge required for this blog, including ZKP (Zero-Knowledge Proof), Polynomial Commitment, and Merkle Tree. 1.1 Zero-knowledge proof ZKP allows a prover to convince a verifier of a statement's validity without revealing additional information. A succinct ZKP ensures sublinear communication relative to the statement size, while a transparent ZKP avoids trusted setups, making it blockchain-compatible. TapSTARK does not require the zero-knowledge property.

Introduction Discussions about Bitcoin's next upgrade have been ongoing, but as of December 2024, the community has yet to reach a consensus on whether to upgrade, what problems the upgrade should address, or what functionalities it should introduce. The debate remains polarized, resembling a political stalemate. In this deadlock, several interesting phenomena have emerged: A portion of the community actively pushes for upgrades. Driven by information asymmetry or commercial interests, some members frequently advocate for specific opcodes, and certain projects even depend on opcodes that "might" appear in the future. A significant number of pragmatic ecosystem developers have made considerable cryptographic and engineering efforts to expand Bitcoin's potential, all without assuming protocol upgrades. Voices advocating for slow upgrades or outright opposing upgrades are also substantial. These phenomena highlight that the topic of upgrades is highly popular within the Bitcoin community. However, they also reveal that many community members lack a comprehensive understanding of the complete process of a Bitcoin upgrade. Additionally, there is limited awareness of how innovative cryptographic tools can enhance Bitcoin's potential.The core purpose of this article is to break through this information asymmetry, align everyone’s understanding, and facilitate deeper discussions on the topic.