Getting Closer to BTC: Background Knowledge Needed to Understand BitVM (1)
TechFlow Selected TechFlow Selected
Getting Closer to BTC: Background Knowledge Needed to Understand BitVM (1)
This article will introduce the fundamental concepts of BitVM, Bitcoin scripting, and Segregated Witness.
Navigating Web3 tides with focused insightsAuthors: Nickqiao, Faust, Shew Wang, Geeker Web3
Advisor: Bitlayer Research Team
Summary: Recently, Delphi Digital released a technical research report titled "The Dawn of Bitcoin Programmability: Paving the Way for Rollups," which systematically outlines core concepts related to Bitcoin rollups, such as the BitVM suite, OP_CAT and covenant restrictions, Bitcoin ecosystem data availability (DA) layers, bridges, and four major BitVM-based Bitcoin Layer 2 solutions—Bitlayer, Citrea, Yona, and Bob.
While this report broadly presents the landscape of Bitcoin Layer 2 technologies, it lacks in-depth technical details, leaving many readers with only a vague understanding. Building upon Delphi’s report, Geeker Web3 has conducted deeper, expanded analysis aiming to help more people gain a systematic understanding of technologies like BitVM.
We will collaborate with the Bitlayer Research Team and the BitVM Chinese Community to launch a series called "Approaching BTC," focusing long-term on educational content around key topics such as BitVM, OP_CAT, and Bitcoin cross-chain bridges, striving to demystify Bitcoin Layer 2 technologies and pave the way for broader participation.
A few months ago, Robin Linus, lead of ZeroSync, published an article titled "BitVM: Compute Anything on Bitcoin," formally introducing the concept of BitVM and advancing the development of Bitcoin Layer 2 technology. This can be considered one of the most revolutionary innovations in the Bitcoin ecosystem, igniting the entire Bitcoin L2 space and attracting high-profile projects such as Bitlayer, Citrea, and BOB, bringing renewed vitality to the market.
Following that, more researchers joined efforts to improve BitVM, successively releasing different iterations including BitVM1, BitVM2, BitVMX, and BitSNARK. The general progression is outlined below:
-
The original BitVM whitepaper proposed by Robin Linus last year was based on a virtual logic gate circuit implementation, known as BitVM0;
-
In subsequent talks and interviews, Robin Linus informally introduced a CPU-based BitVM approach (called BitVM1), similar to Optimism's fraud proof system Cannon, simulating a general-purpose CPU off-chain using Bitcoin scripts.
-
Robin Linus also proposed BitVM2, a permissionless single-step non-interactive fraud proof protocol.
-
Members from Rootstock Labs and Fairgate Labs released the BitVMX whitepaper, similarly aiming to simulate a general-purpose CPU effect off-chain via Bitcoin scripts, akin to BitVM1.
Currently, the developer ecosystem around BitVM is becoming increasingly clear, with visible progress in tooling and infrastructure. Compared to last year, the BitVM ecosystem has evolved from being a mere "castle in the air" to something now "faintly visible," attracting growing interest from developers and venture capitalists alike.
However, for most people, grasping BitVM and related Bitcoin Layer 2 technical terms remains challenging, as it requires foundational knowledge of Bitcoin scripting, Taproot, and other background concepts. Existing online resources are either overly lengthy or insufficiently clear, often leaving readers confused. We aim to address these issues by explaining Bitcoin L2-related knowledge in the clearest possible language, helping build a systematic understanding of the BitVM framework.
MATT and Commitments: The Foundational Idea Behind BitVM
First, we emphasize that the foundational idea behind BitVM is MATT—Merkleize All The Things—which refers to using Merkle Trees, a tree-like data structure, to represent complex program execution processes and enable native fraud proof verification on Bitcoin.
Although MATT can express a complex program and its data processing traces, it does not publish all this data directly on the BTC chain due to its massive size. Solutions using MATT store data only in an off-chain Merkle tree, publishing only the root hash (Merkle Root) on-chain. This Merkle tree primarily contains three core components:
-
Smart contract script code
-
Data required by the contract
-
Execution traces left during contract execution (records of changes made to memory and CPU registers when executing smart contracts in VMs like EVM)
(A simple illustration of a Merkle Tree, where the Merkle Root is derived through multiple layers of hashing from the eight data segments at the bottom)
Under the MATT scheme, only the tiny Merkle Root is stored on-chain, while the full dataset within the Merkle Tree resides off-chain—this leverages a concept known as "commitment." Let's clarify what a "commitment" is.
A commitment resembles a concise statement—it can be thought of as a compressed "fingerprint" of a large dataset. Typically, someone publishing a commitment on-chain claims that certain off-chain data is accurate, and that data corresponds to this simplified statement—the commitment.
In some cases, a data hash serves as the commitment to the data itself; other commitment schemes include KZG commitments or Merkle Trees. In typical Layer 2 fraud proof protocols, the data publisher releases the complete dataset off-chain and posts the dataset's commitment on-chain. If someone detects invalid data in the off-chain dataset, they can challenge the on-chain data commitment.
Through commitments, Layer 2 systems compress vast amounts of data, publishing only their "commitment" on the Bitcoin chain. Of course, it must still be ensured that the full off-chain dataset is publicly observable.
Current major BitVM approaches—including BitVM0, BitVM1, BitVM2, and BitVMX—all adopt a similar abstract structure:
1. Program Decomposition and Commitment: First, decompose complex programs into numerous basic opcodes (compilation), then record the traces generated during actual execution (essentially, the state change logs when a program runs on a CPU and memory, referred to as Trace). Then, organize all data—including Traces and opcodes—into a dataset and generate its commitment.
Specific commitment methods can take various forms: Merkle trees, PIOPs (various ZK algorithms), hash functions
2. Asset Staking and Pre-signing: Data publishers and validators must lock a certain amount of assets on-chain via pre-signatures, under specific conditions. These conditions are designed to trigger in response to future events—if the data publisher acts maliciously, the validator can submit a proof to seize their assets.
3. Data and Commitment Publication: The data publisher posts the commitment on-chain and the full dataset off-chain. Validators retrieve the dataset and check for errors. Each part of the off-chain dataset is linked to the on-chain commitment.
4. Challenge and Penalty: Once a validator detects erroneous data provided by the publisher, they bring that segment on-chain for direct verification (after slicing it very finely)—this embodies the logic of fraud proofs. If verification confirms the publisher provided invalid off-chain data, their assets are seized by the challenger.
In summary, data publisher Alice publicly discloses all traces of Layer 2 transaction execution off-chain, posting the corresponding commitment on-chain. To prove part of the data is incorrect, you first demonstrate to Bitcoin nodes that this data is associated with the on-chain commitment—i.e., proving it was indeed published by Alice—and then let Bitcoin nodes verify that this portion is flawed.
Now that we have a general grasp of BitVM's overall approach, note that all BitVM variants fundamentally follow this paradigm. Next, let's dive into some key technologies used in this process, starting with the basics: Bitcoin Script, Taproot, and pre-signatures.
What Is Bitcoin Script?
Bitcoin-related knowledge is harder to grasp than Ethereum's—even basic transactions involve several concepts, including UTXO (Unspent Transaction Output), locking scripts (also called ScriptPubKey), and unlocking scripts (also called ScriptSig). We'll start by explaining these core concepts.
(Example of Bitcoin script code, composed of low-level opcodes rather than high-level languages)
Ethereum's asset model resembles Alipay or WeChat Pay—each transfer simply adjusts account balances via addition and subtraction. It's account-centric, where asset balances are just numbers under account names. Bitcoin's model is more like physical gold—each piece of gold (UTXO) bears an owner's mark. Transferring Bitcoin involves destroying old UTXOs and creating new ones (with changed ownership).
A Bitcoin UTXO contains two key fields:
-
Amount, measured in satoshis (100 million satoshis = 1 BTC);
-
Locking script, also known as "script pubkey (ScriptPubKey)," defining the conditions for unlocking the UTXO.
Note that a Bitcoin UTXO's ownership is expressed through its locking script. If you want to transfer your UTXO to Sam, you initiate a transaction destroying your UTXO and create a new one with unlock conditions set to "only Sam can unlock."
Then, if Sam wants to spend these bitcoins, he must submit an unlocking script (ScriptSig) containing his digital signature, proving he is indeed Sam. If the unlocking script matches the locking script, Sam can unlock and re-transfer the bitcoins.
(The unlocking script must match the locking script)
From a structural standpoint, every transaction on the Bitcoin chain corresponds to multiple Inputs and Outputs. Each Input declares which UTXO it intends to unlock and submits an unlocking script to destroy it; each Output reveals information about newly created UTXOs, publicly stating the locking script.
For example, in a transaction's Inputs, you prove you're Sam, unlock and destroy multiple UTXOs sent to you, then generate new UTXOs designated for future unlocking by xxx.
Specifically, in the transaction's Input data, you must declare which UTXOs you wish to unlock and indicate their "storage location." Note that Bitcoin differs fundamentally from Ethereum. Ethereum uses contract accounts and EOAs to store data, with asset balances recorded as numbers under those accounts in a database called the "world state." During transfers, Ethereum directly modifies entries in the world state, making data locations easy to identify.
Bitcoin has no world state design—asset data is scattered across past blocks (i.e., unspent UTXO data stored separately in each transaction's Outputs).
To unlock a UTXO, you must specify which past transaction's Output contains it and provide that transaction's ID (its hash), so Bitcoin nodes can search historical records. To query a given address's Bitcoin balance, one must scan all blocks from the beginning to find unspent UTXOs linked to that address.
When using Bitcoin wallets, checking an address's balance quickly is often possible because wallet services themselves scan blocks and build indexes for addresses, enabling fast queries.
(When generating a transaction to send your UTXOs to others, you must use the transaction hash/ID of those UTXOs to mark their position in Bitcoin's history)
Interestingly, the outcome of Bitcoin transactions is computed off-chain. When users generate transactions on local devices, they must fully construct both Inputs and Outputs, effectively calculating the transaction results upfront. Only after broadcasting to the Bitcoin network and passing node validation does the transaction get included on-chain. This "off-chain computation – on-chain verification" model is entirely different from Ethereum, where you only need to provide input parameters—the nodes compute and output the result.
Additionally, a UTXO's locking script can be customized. You can set it so that "the owner of a specific Bitcoin address can unlock it," requiring submission of a digital signature and public key (P2PKH). In Pay-to-Script-Hash (P2SH) transactions, you can embed a script hash in the UTXO's locking script—anyone who provides the pre-image of that hash and satisfies its predefined conditions can unlock the UTXO. The Taproot scripts relied upon by BitVM utilize features similar to P2SH.
How Are Bitcoin Scripts Triggered?
We’ll first use P2PKH as an example to explain how Bitcoin scripts are triggered—understanding this mechanism is essential before tackling more complex concepts like Taproot and BitVM. P2PKH stands for "Pay to Public Key Hash." Under this scheme, the UTXO's locking script includes a public key hash, and unlocking requires submitting the corresponding public key—consistent with standard Bitcoin transfer logic.
Here, Bitcoin nodes must verify that the public key in the unlocking script matches the public key hash specified in the locking script—that is, ensuring the "key" submitted by the claimant matches the "lock" preset in the UTXO.
More precisely, upon receiving a transaction, Bitcoin nodes concatenate the user-provided unlocking script (ScriptSig) with the locking script (ScriptPubKey) of the UTXO being unlocked and execute them together within the Bitcoin script execution environment. The figure below shows the concatenated result before execution:
Readers unfamiliar with Bitcoin's script execution environment may benefit from a brief explanation. BTC scripts consist of two types of elements:
Data and opcodes. These are pushed onto a stack from left to right and executed according to defined logic to produce a final result (we won't elaborate on stacks here—readers can consult ChatGPT).
In the above example, the left side shows the unlocking script (ScriptSig) uploaded by someone, containing their digital signature and public key, while the right side's locking script (ScriptPubKey) contains opcodes and data set by the UTXO creator (you don’t need to understand every opcode—just grasp the general idea).
In the locking script (right), opcodes like DUP, HASH160, and EQUALVERIFY take the public key from the unlocking script (left), hash it, and compare it against the preset public key hash. If they match, the first verification step passes.
But here's a problem: the content of the locking script is public on-chain—anyone can see the public key hash and potentially submit the matching public key, falsely claiming to be the rightful owner. So after verifying the public key-hash match, we must also confirm whether the transaction initiator actually controls the private key. This is where signature verification comes in. The CHECKSIG opcode in the locking script handles digital signature verification.
In summary, under P2PKH, the unlocking script must contain a public key matching the hash in the locking script and a valid digital signature—only meeting both conditions allows successful UTXO unlocking.
(This image is dynamic: Illustration of Bitcoin unlocking script under P2PKH)
Source: https://learnmeabitcoin.com/technical/script
Of course, the Bitcoin network supports multiple transaction types—not just pay-to-public-key/public-key-hash—but also P2SH (Pay to Script Hash), all depending on how the UTXO creator customizes the locking script at creation time.
Note that under P2SH, the locking script can preset a script hash, and the unlocking script must fully submit the content corresponding to that hash. Bitcoin nodes can then execute this script. If the script defines multi-signature logic, it enables multisig wallets on Bitcoin.
Of course, under P2SH, the UTXO creator must ensure the future unlocker knows the script content corresponding to the script hash. As long as both parties know the script, we can implement business logic far more complex than multisig.
One important point: the Bitcoin chain (blocks) does not directly record which UTXOs belong to which addresses. It only records which public key hashes or script hashes can unlock each UTXO. However, from a public key hash or script hash, we can quickly derive the corresponding address (that string of seemingly random characters shown in wallet interfaces).
The reason we see displays like "address xx has yy BTC" on block explorers and wallet UIs is because these services parse the data for us—scanning all blocks and computing addresses from public key hashes/script hashes declared in locking scripts—then showing how much BTC belongs to each address.
SegWit and Witness
Having understood P2SH, we’re now closer to grasping Taproot, which BitVM relies on. But first, we need to understand a critical concept: Witness and Segregated Witness (SegWit).
Reviewing earlier discussions on unlocking/locking scripts and UTXO unlocking procedures, we encounter a problem: digital signatures are embedded in the unlocking script. Since signatures cannot include themselves during generation, signatures can only cover parts outside the unlocking script—i.e., they associate only with the main body of the transaction data, not covering it entirely.
Thus, even if an intermediary slightly alters the unlocking script, the signature verification remains unaffected. For instance, Bitcoin nodes or mining pools could insert extra data into the unlocking script without affecting signature validation or transaction outcomes, causing subtle changes in transaction data and resulting in different transaction hashes/IDs. This is known as the transaction malleability problem.
The downside? If you plan to send multiple sequential transactions with dependencies (e.g., transaction 3 references output from transaction 2, which references output from transaction 1), later transactions must reference prior transaction IDs (hashes). Any intermediary—mining pools or Bitcoin nodes—can tweak the unlocking script, altering the final on-chain transaction hash from your expectation, thereby invalidating your pre-constructed sequence of dependent transactions.
Indeed, in DLC bridges and BitVM2 designs, batches of ordered, interdependent transactions are commonly constructed—so this scenario is quite common.
Simply put, transaction malleability arises because transaction ID/hash calculation includes unlocking script data, which intermediaries like Bitcoin nodes can subtly modify, causing discrepancies between actual and expected transaction IDs. This was an oversight in Bitcoin’s early design—an inherited technical debt.
The later-introduced Segregated Witness (SegWit) upgrade decouples transaction IDs from unlocking scripts entirely—transaction hashes are calculated without including unlocking script data. UTXOs following SegWit rules default to setting an "OP_0" opcode at the beginning of the locking script as a marker; correspondingly, the unlocking script is renamed from SigScript to Witness.
After adopting SegWit, transaction malleability is properly resolved—you no longer need to worry about Bitcoin nodes modifying your transaction data. You don’t need to overthink it: P2WSH functions similarly to earlier P2SH—you can preset a script hash in the UTXO locking script and require the submitter to provide and execute the corresponding script on-chain.
But if your script is extremely large and packed with code, conventional methods may fail to submit the full script to the Bitcoin chain (due to block size limits). What then? This is where Taproot comes in—enabling simplification of on-chain script content. BitVM builds precisely on such Taproot-based optimizations.
In the next article of our "Approaching BTC" series, we will dive deeper into Taproot, pre-signatures, and other advanced technologies related to BitVM—stay tuned!
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@godrealmx
