BitVM-Style Smart Contract

Bitcoin, by design, lacks native support for smart contracts. BitVM tackles this limitation by providing an ingenious way to emulate their functionality. This document delves into the intricacies of BitVM smart contracts, their design principles, and the security model that underpins their operation.

BitVM and BitVM2

Conceived by Robin Linus, BitVM represents a pioneering effort to bring the power of smart contracts to the Bitcoin ecosystem. The initial iteration, BitVM1, focused on generic computation. It required compiling a program's verifier into low-level instructions, similar to those used in the RISC-V architecture. BitVM1 employed a two-party protocol where challenges to the program's execution required explicit permission. To pinpoint erroneous instructions, a technique called interactive bisection was used.

BitVM2, a significant leap forward, introduces permissionless challenges, fostering a more open and decentralized environment. The core components of BitVM2 are primarily the fruits of labor from the BitVM alliance, a consortium of dedicated developers and researchers. Bitlayer, a committed member of this alliance, continues to contribute to the BitVM project, ensuring its long-term growth and adoption.

Demystifying BitVM Smart Contracts

The concept of BitVM smart contracts draws inspiration from Hashed Time-Locked Contracts (HTLCs), a simpler form of smart contract implemented on Bitcoin. HTLCs rely on pre-signed Bitcoin transactions to enforce contractual agreements between two parties. Before any funds are transferred, both parties pre-sign a refund transaction. This mechanism guarantees that, even in the event of a dispute or unforeseen circumstances, both parties can retrieve their funds.

BitVM smart contracts, while inspired by HTLCs, are significantly more sophisticated, accommodating interactions between multiple parties. Imagine a pre-defined network of Bitcoin transactions – this network, visualized as a directed graph, forms the backbone of a BitVM smart contract. This transaction graph meticulously outlines all possible execution paths for every participant involved. Once all parties have pre-signed this graph, signifying their agreement to its terms, it transforms into an immutable contract, much like a traditional smart contract deployed on a blockchain.

To better grasp this concept, consider the transaction graph as the "source code" of the smart contract. Participants, before joining the contract, meticulously review this code and its initial configurations. Only upon reaching a consensus does the contract become operational. This ensures transparency and eliminates the risk of participants unknowingly agreeing to unfavorable terms.

Pre-Signing the Contract: Building a Foundation of Trust

In typical blockchain ecosystems, smart contracts are deployed directly onto the blockchain, leveraging the blockchain's inherent security to act as a trusted source of truth. Bitcoin, however, lacks this native capability. To overcome this hurdle, BitVM introduces the concept of a pre-signing committee. This committee, composed of trusted entities, is responsible for meticulously reviewing and pre-signing the transaction graph. This process effectively emulates the on-chain deployment of traditional smart contracts.

The committee, through its multi-signature authority (multisig), plays a critical role in ensuring the integrity and security of the BitVM smart contract:

• Transaction Integrity: Each transaction within the graph undergoes rigorous scrutiny to ensure the correctness of its inputs. This involves verifying the number of inputs, their corresponding values, and other relevant details. To further bolster security, the committee's multisig is typically embedded within the unlocking script of each input. This acts as a safeguard against unauthorized modifications to the transaction graph.
• Output Validity: The committee also meticulously examines the outputs generated by each transaction. This includes verifying the number of outputs, their values, and most importantly, their unlocking scripts. These scripts, often employing covenant-style constructions, dictate how and when funds locked within an output can be spent. By carefully crafting these scripts, the committee ensures that funds flow through the contract as intended.

Once the pre-signed transaction graph is made public, all participants gain access to a consistent and tamper-proof version of the smart contract. The multisig mechanism ensures that all parties adhere to the predefined rules of the contract. Participants can only send transactions that are explicitly defined within the pre-signed graph, preventing any deviation from the agreed-upon terms.

A crucial aspect of the BitVM security model is the deletion of private keys by the committee members after the pre-signing process. This step is essential to prevent any single entity from unilaterally modifying the contract after it has been finalized. The security of BitVM relies on the "honest one" assumption, meaning that at least one member of the committee is assumed to have acted honestly and deleted their private key. As long as this assumption holds true, any attempt to manipulate the smart contract is rendered infeasible.

Designing the Transaction Graph: Navigating Complexity

While restricting transactions to a predefined set is a significant step towards emulating smart contracts on Bitcoin, the actual design of these transaction graphs is where the true complexity lies. Use cases like verifiable computing, cross-chain bridges (like a BTC bridge), or layer-2 scaling solutions (rollups) demand intricate and carefully orchestrated transaction flows. Let's delve into some of the challenges inherent in designing these graphs and how BitVM addresses them.

1. Guarding State Transitions: Ensuring Predictable Execution

A well-structured smart contract often incorporates a finite state machine (FSM) to manage its internal logic. The FSM transitions between different states based on predefined rules and the actions of its participants. Replicating this behavior on Bitcoin, a platform without native state management, requires a clever mechanism to control these state transitions. BitVM achieves this through the ingenious use of "connector outputs."

Connector outputs are special outputs embedded within transactions that act as gatekeepers for state transitions. When a particular branch within the transaction graph consumes a connector output, it effectively invalidates other branches that might have otherwise been accessible. This ensures that the state of the contract transitions in a predictable and controlled manner, preventing any ambiguity or unintended forks in execution.

To further refine this control mechanism, connector outputs often incorporate timelocks. A timelock, as the name suggests, prevents an output from being spent before a predefined time or block height. By strategically placing timelocks on connector outputs, certain branches within the transaction graph can be prioritized over others.

Connector outputs typically hold a negligible amount of Bitcoin (often referred to as "dust") as their primary purpose is control flow rather than value transfer. Their ephemeral nature makes them ideal for guiding the execution of the smart contract without unnecessarily locking up funds.

To illustrate this concept, consider a scenario where a participant, referred to as the "defender," stakes a certain amount of Bitcoin on an assertion they make. The transaction graph defines two possible paths for the defender to withdraw their stake: a "happy path" and an "unhappy path." Both paths share a common connector output. However, the unhappy path, equipped with an earlier timelock, allows a challenger to consume the connector output before the defender can proceed down the happy path. This mechanism forces the defender down the unhappy path, triggering a dispute resolution process to determine the validity of their initial assertion.

2. Handling Dynamic Elements: Embracing Flexibility

The static nature of pre-signed transaction graphs, while ensuring security and predictability, presents a challenge when dealing with dynamic elements inherent in certain smart contract use cases. Two common examples of such dynamic elements are:

• Unknown Witness Data: The witness data, which includes signatures and other information required to unlock a Bitcoin transaction input, might not be known at the time of pre-signing the transaction graph.
• Unknown Addresses: The Bitcoin addresses of certain participants might be unknown during the contract creation phase. For instance, in a cross-chain bridge, the recipient of pegged-out Bitcoin might not be known beforehand. Similarly, in optimistic rollup solutions, the address of a potential challenger is not predetermined.

BitVM employs different strategies to address these challenges:

• Commit-and-Reveal for Unknown Witness Data: BitVM leverages a cryptographic technique called commit-and-reveal to handle unknown witness data. This involves creating a cryptographic commitment to the witness data and embedding this commitment within the unlocking script of a pre-signed UTXO (Unspent Transaction Output). The actual witness data is only revealed and verified when the UTXO is spent, ensuring both security and flexibility.
• Flexible SIGHASH Flags and Application-Level Solutions for Unknown Addresses: For unknown addresses, BitVM offers a more nuanced approach. In some cases, flexible SIGHASH flags can be employed. A SIGHASH flag determines which parts of a transaction are signed, allowing for certain elements to be left unspecified during pre-signing. However, this approach has limitations and might not be suitable for all scenarios. In other cases, solutions at the application layer might be necessary. For instance, the "front-and-reclaim" pattern used in BitVM bridges addresses the challenge of unknown peg-out users.

Commit and Reveal: A Deep Dive

Bit commitments, often implemented using Lamport signatures, provide a secure and efficient way to commit to a value without revealing it until a later time. Here's how the commit-and-reveal process works in the context of BitVM:

1. Commit Phase: The party committing to the data (the committer) uses the public key of a Lamport signature scheme to generate a commitment for each bit of the data. These public key hashes are then embedded within the unlocking script of the committing UTXO. This step effectively "locks" the commitment to the data on the Bitcoin blockchain.
2. Reveal Phase: To reveal the committed data, the committer discloses the corresponding private keys associated with the Lamport signature. The unlocking script, upon receiving these private keys, verifies them against the previously committed public key hashes. If the verification is successful, the committed data is considered valid and is revealed. This mechanism ensures that the committed data remains hidden until the reveal phase while guaranteeing its integrity.

Leveraging SIGHASH Flags for Flexibility

SIGHASH flags provide a degree of flexibility in Bitcoin transactions by allowing for the selective signing of transaction data. This means that a transaction can be partially signed, leaving certain elements, such as the recipient's address, to be filled in later. In the context of BitVM, this flexibility can be harnessed to address the challenge of unknown addresses in specific scenarios.

For instance, in the BitVM2 bridge, the SIGHASH flag mechanism allows anyone to initiate a challenge against a potentially fraudulent withdrawal request by locking up 1 BTC. The recipient of this 1 BTC reward, in case the challenge is successful, is not predetermined during the contract creation phase. Instead, the SIGHASH flag mechanism allows for this address to be specified later by the challenger. This flexibility fosters a more open and decentralized challenge mechanism.

It's important to note that while SIGHASH flags offer a powerful tool for handling dynamic elements, their applicability is limited to certain transaction structures. In more complex scenarios, application-level solutions might be required to fully address the challenges posed by unknown addresses.

Creating a BitVM Smart Contract: A Bird's-Eye View

The process of creating a BitVM smart contract can be summarized in three key steps:

1. Define the Transaction Graph: The first step involves meticulously designing the transaction graph that embodies the desired functionality of the smart contract. This step requires a deep understanding of Bitcoin scripting, the specific use case being addressed, and the potential edge cases that might arise.
2. Pre-sign the Graph: Once the transaction graph is finalized, it is presented to the pre-signing committee. The committee members, using their multisig authority, carefully review the graph to ensure its correctness and security. Once the review is complete, the committee members jointly sign the transaction graph, effectively "locking it in."
3. Publish the Graph: The final step involves publishing the pre-signed transaction graph, making it accessible to all potential participants. This publication can be done through various means, such as distributing it through a decentralized storage network or simply making it available for download on a website.

BitVM Smart Contract Safety: A Spectrum of Trust

The level of trust required in a BitVM smart contract can vary depending on its specific design and implementation. It's helpful to think of this trust as a spectrum:

• Trustless: At one end of the spectrum, we have trustless systems, like those found in Bitcoin and Ethereum, where the security of the system relies solely on cryptographic principles and the decentralized nature of the network. No reliance on any single party or entity is needed.
• Trusted: At the other end of the spectrum, we have systems that require a high degree of trust in a centralized entity or a small group of entities.
• Hybrid Models: Between these two extremes lie various hybrid models that offer different trade-offs between trust and security:
  • Honest Majority: This model assumes that a majority of participants in the system will act honestly. Examples include MPC (Multi-Party Computation) bridges and Proof-of-Stake (PoS) blockchains.
  • Honest Minority: This model relaxes the trust assumption further, requiring only a minority of participants to act honestly.
  • Honest One: This model, employed in some optimistic rollup solutions, requires only one honest party for the system to function securely.

BitVM, with its flexible design, can be used to implement smart contracts across this spectrum of trust. The specific trust model employed will depend on the specific requirements of the use case being addressed. For instance, a BitVM-based cross-chain bridge might opt for an honest majority model, while an optimistic rollup solution might leverage an honest one model.