By design, Bitcoin supports only very simple smart contracts using basic operations. The main building blocks are: - **Signatures (`OP_CHECKSIG`):** Verify that a transaction was authorized by the rightful owner. - **Timelocks (`OP_CHECKLOCKTIMEVERIFY` / `OP_CHECKSEQUENCEVERIFY`):** Restrict spending funds until a specific block height or time has passed. - **Hashlocks (`OP_HASH160`, `OP_EQUALVERIFY`):** Lock coins until someone reveals a secret preimage matching a previously committed hash. These intentionally limited operations ensure Bitcoin remains secure and predictable, at the expense of complex programmability. The fact that any computable function can be represented as a Boolean circuit comes from foundational work in computational complexity, especially related to the Cook-Levin theorem, proven independently by Stephen Cook in 1971 and Leonid Levin in 1973. This theorem essentially showed that any computational task solvable by a Turing machine (the abstract mathematical model for computation) can also be represented by a Boolean circuit composed of logic gates. In other words, Boolean circuits are universal and capable of expressing any computational problem, given sufficient size and complexity. You’ll often hear the term "Turing complete" in discussions about blockchains and smart contracts. At its heart, Turing completeness means that a programming language can theoretically compute anything that a traditional computer can, given enough time and memory. Bitcoin’s built-in scripting language is intentionally not Turing complete - it’s simple, stack-based, and designed with limited functionality. A stack-based language operates by pushing and popping values onto a stack, rather than accessing variables directly. Bitcoin scripts intentionally lack loops and recursion, meaning they cannot run indefinitely—this is deliberate, because it guarantees scripts always terminate, ensuring predictable behavior and security. Ethereum, by contrast, uses a Turing-complete language, meaning Ethereum smart contracts can, in theory, perform arbitrarily complex computations, loops, and conditional logic directly on-chain. This makes Ethereum powerful for programming complex contracts but introduces complexity and potential vulnerabilities. BitVM shows that although Bitcoin itself is not Turing complete, we can cleverly achieve Turing-complete contracts off-chain, only using Bitcoin’s limited on-chain scripting language to verify (rather than execute) computations. In BitVM, each computational step (logic gate execution) is encoded into its own separate script, called a Tapleaf. These scripts are hidden together within a single Taproot address. To execute a particular gate, the prover creates an on-chain transaction that reveals the specific Tapleaf corresponding to that gate. Revealing a Tapleaf means the prover provides the blockchain with: * The script for that specific logic gate, * The necessary input and output values to satisfy the gate’s logic, * Proof linking the revealed script back to the original Taproot address. This allows verification of any chosen gate's correctness directly on-chain, while keeping all other gates hidden. In this context, pre-signing a sequence of transactions means that before execution begins, the prover and verifier collaboratively create and sign a series of Bitcoin transactions off-chain. These transactions aren’t immediately broadcasted; instead, they're privately stored. The Taproot address acts as a cryptographic anchor for these commitments, ensuring that neither party can alter the terms later. If disputes arise, either party can broadcast these pre-signed transactions to enforce the challenge-response mechanism on-chain, resolving disputes efficiently. ### Taproot 
Taproot addresses, introduced to Bitcoin in 2021, significantly enhanced privacy and efficiency by allowing complex scripts to appear indistinguishable from simple transactions. Developed by Pieter Wuille and other Bitcoin contributors, Taproot solved the issue of limited privacy and scalability for complex scripts by combining them into a compact, cryptographic structure. Internally, Taproot uses a Merkelized Abstract Syntax Tree (MAST) - think of it as a cryptographic "tree" structure where only the specific branch that's executed is revealed, keeping all other conditions hidden and private. This makes even highly complex Bitcoin contracts look just like ordinary transactions, unless explicitly revealed. ### MATT "MATT," short for "Merkelize All The Things," is a proposal to enhance Bitcoin’s contract capabilities without changing its fundamental rules. It suggests encoding complex contract logic and conditions using Merkle trees - a cryptographic structure that hides detailed logic behind simple hashes. Complex conditions remain hidden until explicitly executed, significantly improving privacy and efficiency. MATT is similar in spirit to Optimistic Rollups (popularized around 2019, mostly in Ethereum), which execute transactions off-chain and periodically post transaction summaries on-chain, assuming correctness unless disputed. In contrast, MATT commits logic directly on-chain from the beginning but keeps details hidden until executed. MATT emerged shortly after optimistic rollups (~2021), applying similar concepts but specifically adapted to Bitcoin's architecture. ### Optimistic Rollups Optimistic Rollups are a blockchain scaling technique designed to handle large numbers of transactions off-chain. The name "optimistic" comes from the assumption that most computations or transactions are honest and don't need immediate verification. Instead of checking every action on-chain (which is slow and costly), transactions are executed off-chain, and only a summary or "rollup" is recorded on-chain. These rollups work by assuming honesty first - transactions are optimistically accepted without immediate verification. If nobody disputes them within a given timeframe, they're finalized. But if someone suspects wrongdoing, they can submit a fraud proof, prompting the blockchain to verify the challenged transaction. If fraud is found, the dishonest actor loses a deposit. Optimistic rollups are primarily used on Ethereum to address scalability limitations. Introduced around 2019–2020 by Ethereum community researchers, these rollups help Ethereum process more transactions efficiently without sacrificing its robust security guarantees. In BitVM, the basic building block is the **bit value commitment**, where the prover securely commits to setting a specific bit (either 0 or 1). To understand this clearly, recall two important Bitcoin concepts: - **UTXO (Unspent Transaction Output):** A UTXO is essentially a "coin" locked by conditions defined in scripts. You can only spend the coin if you satisfy those conditions. - **Scripts:** Small pieces of logic attached to UTXOs that determine under which conditions they can be spent. BitVM leverages bit commitments to chain multiple transactions together, like so: 1. Transaction #1 creates a UTXO with a script containing a committed bit (0 or 1). 2. Transaction #2 spends this UTXO by running its script, checking the previously set bit, and possibly committing a new bit. 3. This process repeats through multiple transactions, each validating previous bits and setting new conditions. When the prover and verifier first set up the circuit, the prover commits to a single bit ("0" or "1") by publishing two hashes (**hash0** and **hash1**), each corresponding secretly to **preimage0** and **preimage1** respectively. Initially, only the prover knows both preimages. Later, the prover chooses one bit value by revealing exactly one preimage (for example, **preimage1**, meaning "bit = 1"). If at any point the prover reveals both preimages (**preimage0** and **preimage1**), that's called **equivocation**, because the prover has tried to commit to both values. In this scenario, the verifier can now prove fraud by using these two preimages to satisfy a hashlock condition set previously in the Bitcoin script, unlocking and claiming the prover's deposit as punishment.