Technical Deep Dive (Optional – For the Curious)

Most of this book has been about using Bitcoin: understanding what it is, how to hold it securely, how to send it, what to watch out for. This chapter is different. It is for the reader who wants to understand how Bitcoin actually works at a technical level — the mechanisms that make it secure, expressive, and deliberately limited.

You do not need this chapter to use Bitcoin safely and effectively. But if you have ever wondered what the code inside a transaction actually says, why Bitcoin was designed without loops, or how the queuing system for unconfirmed transactions works, this chapter answers those questions in plain language.

What is Bitcoin Script?

Every Bitcoin transaction includes a small program written in a language called Bitcoin Script.

Script defines the rule that governs spending. When you send Bitcoin to someone, you are not simply moving coins to their address — you are creating an output that is "locked" with a Script program specifying the conditions under which those coins can be spent. The recipient, when they later want to spend those coins, must provide an input that "unlocks" the program.

The technical terms for these two parts: the locking program is called a ScriptPubKey (or output script). The unlocking data provided later is called a ScriptSig or, in newer transaction formats, a Witness.

Bitcoin Script is a stack-based language. This means instructions are executed in sequence, pushing values onto and popping values from a stack — imagine a pile of plates where you can only add or remove from the top. Operations are simple: push a value, check a signature, compare hashes, jump if a condition is met.

When a node validates a transaction, it runs the unlocking script first (pushing any required data onto the stack), then runs the locking script. If the final state of the stack has a non-zero value at the top, the transaction is valid. If not, it is rejected.

This all happens automatically. When you use a modern wallet to send Bitcoin, the wallet writes the appropriate Script for you. But understanding the mechanism shows you why Bitcoin transactions are what they are — and what they can and cannot do.

Common Script Patterns

Standard Bitcoin transactions use a small set of well-established Script templates:

Pay-to-Public-Key-Hash (P2PKH) — the classic address format starting with "1". The locking script says: whoever can provide a public key matching this hash, and a valid signature from the corresponding private key, can spend these coins. This is the building block of most historical Bitcoin transactions.

Pay-to-Script-Hash (P2SH) — addresses starting with "3". The locking script says: whoever can provide a script that hashes to this value, and inputs that satisfy that script, can spend these coins. This enabled multisig and more complex conditions while keeping addresses compact.

Pay-to-Witness-Public-Key-Hash (P2WPKH) — SegWit addresses starting with "bc1q". The same logic as P2PKH, but the signature data is moved to the witness portion of the transaction. This reduced fees and fixed a longstanding malleability issue.

Pay-to-Taproot (P2TR) — addresses starting with "bc1p". The newest format, using Schnorr signatures and a tree structure for spending conditions. Simple spends look identical to complex multi-condition spends, improving privacy.

OP_RETURN — a special output type used to store arbitrary data on-chain. Provably unspendable. Used for Ordinals inscriptions, token protocols, and other data anchoring.

What are OP Codes?

OP codes (operation codes) are the individual commands in Bitcoin Script. Each does one specific thing.

Some of the most important:

OP_DUP — duplicates the top item on the stack. Used in the standard address script to allow checking the public key hash without destroying the public key.

OP_HASH160 — takes the top item off the stack, runs it through SHA-256 followed by RIPEMD-160, and pushes the result. This is the hash function used to create Bitcoin addresses from public keys.

OP_EQUALVERIFY — checks that the top two items on the stack are equal. If not, the script fails immediately.

OP_CHECKSIG — takes a public key and a signature from the stack, verifies the signature against the transaction data, and pushes true or false. This is the fundamental "prove you own this" operation.

OP_CHECKMULTISIG — verifies multiple signatures against multiple public keys. Requires M-of-N signatures to succeed, where M and N are specified in the script.

OP_CHECKLOCKTIMEVERIFY (CLTV) — fails the script unless the transaction's locktime is at or past a specified block height or timestamp. Used to create time-locked outputs that cannot be spent before a certain point.

OP_CHECKSEQUENCEVERIFY (CSV) — similar to CLTV but uses relative timelocks — the output cannot be spent until a certain number of blocks after it was created. Essential for Lightning Network payment channels.

OP_IF / OP_ELSE / OP_ENDIF — conditional execution. Lets a script have multiple spending paths, activated depending on what data the spender provides.

Many OP codes that existed in early versions of Bitcoin were deliberately disabled after security vulnerabilities were discovered. Script's expressiveness was intentionally narrowed over time.

What Does "Turing Complete" Mean, and Why Isn't Bitcoin?

A Turing complete programming language is one that can simulate any computation, given sufficient time and memory. To be Turing complete, a language needs to be able to loop indefinitely and maintain arbitrary state between operations.

Ethereum's smart contract language (Solidity, running on the EVM — Ethereum Virtual Machine) is Turing complete. It can run loops, maintain state across multiple transactions, and execute arbitrarily complex programs. To prevent infinite loops from consuming network resources forever, Ethereum introduced "gas" — a cost for each computational step. Programs run until they complete or run out of gas.

Bitcoin Script is deliberately not Turing complete. It has no loops, no recursion, and no persistent state between transactions. Every Script execution terminates in a bounded number of steps. This was a design choice, not a limitation of early technology.

The reasons are clear:

Predictability. Every node in the Bitcoin network must validate every transaction. If Script could loop indefinitely, a malicious transaction could halt validation globally — or require every node to execute unbounded computation before deciding whether a transaction is valid. With bounded Script, validation is fast and predictable regardless of transaction complexity.

Security. More expressive languages have larger attack surfaces. Ethereum's history includes multiple high-profile exploits of smart contract code — the DAO hack in 2016, numerous DeFi protocol exploits since 2020. Bitcoin Script's limited expressiveness means many entire classes of vulnerability do not exist.

Consensus safety. Bitcoin's rules must be evaluated identically by tens of thousands of independent nodes worldwide. Adding external data sources, complex state, or unbounded computation would make consensus fragile. Bitcoin Script keeps validation entirely deterministic and self-contained.

The trade-off is real: Bitcoin cannot run the kind of open-ended programmable applications that Ethereum supports natively. Complex financial applications, decentralized exchanges, and governance systems that require ongoing state belong on other layers or other networks.

What Smart Contracts Can Bitcoin Do?

Within Script's limits, Bitcoin can express a meaningful set of contract types:

Multisig — require M signatures from N designated keys before funds can be moved. A 2-of-3 multisig means any two of three key holders can authorize a transaction, but none can act alone. Used for corporate treasury controls, inheritance setups, and custody solutions.

Timelock contracts — funds cannot be moved before a specified block height or time. Used for vesting schedules, bonds with lock-up periods, and as a building block for more complex constructions.

Lightning Network payment channels — a combination of multisig and relative timelocks that allows two parties to transact instantly off-chain, settling only the final balance on-chain. This is the most widely deployed Bitcoin smart contract construction.

Hash Time-Locked Contracts (HTLCs) — the mechanism that allows Lightning Network payments to route through intermediaries without requiring trust in those intermediaries. A payment is locked with a cryptographic secret; the recipient unlocks it by revealing the secret; intermediaries are paid only when the secret propagates back through the chain.

Taproot script trees (MAST) — Taproot allows multiple spending conditions to be committed as a hash tree. The spender reveals only the branch they are actually using, keeping unused conditions private. This enables complex multi-path contracts while leaking minimal information about unexercised conditions.

Vaults with delayed recovery — a two-transaction construction where a first transaction begins an unlock process, and a second transaction after a delay completes it. If the first transaction was unauthorized, a recovery key can intervene during the delay. This simulates a vault with a time lock.

These constructions are real, deployed, and used today. They are not theoretical capabilities. They are, however, significantly simpler than what Ethereum's full smart contract environment can express.

What is the Mempool?

The mempool (memory pool) is the collection of valid, unconfirmed transactions waiting to be included in a block.

When you broadcast a Bitcoin transaction, it does not go directly into a block. First, it propagates across the network, node by node. Each node checks that the transaction is valid — correct signature, unspent inputs, proper format — and if so, adds it to its local mempool. The transaction sits there, visible but unconfirmed, until a miner selects it for inclusion in a new block.

Miners select transactions from the mempool based primarily on fee rate (satoshis per virtual byte). Higher fee rate transactions get priority. When the mempool is nearly empty, even very low-fee transactions confirm quickly. When it is full — which happens during periods of high demand — low-fee transactions can wait hours or days.

Each node caps its mempool size (Bitcoin Core's default is 300 megabytes). When the mempool is full, the node drops the lowest-fee transactions to make room. Those transactions are not permanently lost — they can be rebroadcast — but they will not confirm until fees drop or the broadcaster increases the fee.

Replace-by-Fee (RBF): Bitcoin supports a mechanism where a sender can replace an unconfirmed transaction with a new version that pays a higher fee, effectively bumping the priority. Most modern wallets support this. If your transaction is stuck, increasing the fee via RBF is the standard fix.

Unconfirmed transactions expire. Bitcoin Core nodes drop unconfirmed transactions from their mempool after approximately 14 days if they remain unconfirmed. The coins are not lost; the transaction simply needs to be rebroadcast.

Practical guidance: Check fee estimates before broadcasting. Tools like mempool.space show current mempool conditions in real time, including estimated confirmation times at various fee levels. For non-urgent transactions, waiting for low-fee periods (typically weekends and overnight in European time zones, when transaction volume historically drops) can save meaningful amounts.

Key Definitions

UTXO — Unspent Transaction Output. The individual "coins" that make up a Bitcoin balance.

ScriptPubKey — the locking script attached to an output. Defines who can spend it and how.

ScriptSig / Witness — the unlocking data provided by the spender to satisfy the locking script.

Timelock — a Script condition that prevents spending until a specified time or block height.

PSBT — Partially Signed Bitcoin Transaction. A standardized format for sharing and co-signing transactions that require multiple parties, commonly used in multisig setups and Ordinals trading.

P2TR (Pay-to-Taproot) — the current best-practice Bitcoin address format, using Schnorr signatures and MAST for efficient and private complex spending conditions.

Mempool — the pool of valid but unconfirmed transactions waiting for miners to include them in a block.

RBF (Replace-by-Fee) — a mechanism allowing a sender to increase the fee on an unconfirmed transaction to speed up confirmation.

Risk Note

Bitcoin Script is powerful within its boundaries but unforgiving of mistakes. A script written incorrectly can lock coins in an output that can never be spent. Multisig and timelock constructions require careful planning and testing — particularly the backup and recovery procedures. Mempool fees vary significantly with demand. Transactions with very low fees can sit unconfirmed for extended periods during busy times. Use only software you understand and trust for any non-standard Script operations.

Reader Takeaway

Bitcoin Script is intentionally simple and bounded. This is not a bug — it is what makes Bitcoin secure, predictable, and trustworthy at scale. The trade-off is that complex applications belong on higher layers. The mempool is the staging area for all transactions; understanding it helps you set fees intelligently. Taproot and Schnorr are the current frontier of Bitcoin's expressiveness, making complex contracts more private and efficient.

Chapter Summary

• Bitcoin Script is a stack-based language inside every transaction. It defines who can spend an output and under what conditions.
• OP codes are the individual commands: OP_CHECKSIG verifies signatures, OP_CHECKLOCKTIMEVERIFY enforces timelocks, OP_IF enables conditional spending paths.
• Bitcoin Script is deliberately not Turing complete. No loops, no persistent state. This makes validation fast, predictable, and secure.
• Bitcoin can express real smart contracts: multisig, timelocks, Lightning payment channels, HTLCs, and Taproot script trees — all in active use today.
• The mempool holds unconfirmed transactions. Miners prioritize by fee rate. RBF lets senders increase fees on stuck transactions. Mempool size and fee conditions vary with demand.

References

• Antonopoulos, A. Mastering Bitcoin. O'Reilly
• Bitcoin.org Developer Guides — Script reference
• Bitcoin Optech newsletters: Taproot, Schnorr, MAST documentation
• Mempool.space: live fee estimation and mempool visualization
• Chaincode Labs: Bitcoin Script training materials
• Bitcoin Core documentation: mempool policies and RBF