Get deep into crypto

Multi-signature (multisig) scripts in Bitcoin allow a UTXO to be spent only when a predefined number of valid signatures are provided. Instead of a single private key controlling funds, multisig scripts encode shared control rules—such as 2-of-3 or 3-of-5—directly into Bitcoin Script and are enforced by every full node.

CHECKSEQUENCEVERIFY (CSV) is a Bitcoin Script opcode that enforces relative timelocks, preventing a UTXO from being spent until a defined number of blocks have passed since its confirmation. CSV is critical for secure payment channels, vaults, and recovery mechanisms because it ties spending rights to the age of an output, not a fixed date.

CHECKLOCKTIMEVERIFY (CLTV) is a Bitcoin Script opcode that enforces an absolute timelock on a UTXO, preventing it from being spent until a specific block height or timestamp is reached. The rule is enforced by consensus, meaning every full node independently verifies that the timelock condition is satisfied before accepting the spend.

Timelocks in Bitcoin Script are rules that restrict when a UTXO can be spent. They allow transactions to be valid only after a certain block height or timestamp, enabling features like payment channels, escrows, vaults, and recovery mechanisms—without trusting intermediaries.

Bitcoin Script size and complexity limits are strict consensus rules that cap how large scripts can be and how much work they can perform. These limits guarantee deterministic execution, prevent denial-of-service attacks, and keep full-node validation fast and affordable—protecting decentralization at the base layer.

Bitcoin Script enforces spending conditions by attaching precise, consensus-verified rules to each UTXO and requiring every spender to cryptographically prove those rules are satisfied. These conditions are executed deterministically by every full node, ensuring that bitcoin can only be spent in exactly the ways defined when the UTXO was created.

Bitcoin Script is extremely secure because it is deliberately limited, fully deterministic, and enforced by every full node at the consensus level. By avoiding general-purpose computation, global state, and unbounded execution, Bitcoin Script eliminates entire classes of vulnerabilities that plague more expressive smart contract systems.

Bitcoin limits Script expressiveness to preserve security, determinism, and decentralization at the base layer. By deliberately avoiding general-purpose computation, Bitcoin ensures that every transaction can be validated quickly, predictably, and cheaply by anyone running a full node—without introducing complex state, unbounded execution, or fragile assumptions.

Pay-to-Public-Key-Hash (P2PKH) is the original and most widely used Bitcoin transaction type that locks funds to the hash of a public key. To spend a P2PKH output, the spender must reveal the corresponding public key and provide a valid cryptographic signature—proving ownership in a simple, secure, and decentralized way.

In practice, Bitcoin cannot change its UTXO model without breaking consensus and destroying backward compatibility. The UTXO model is not a modular feature—it is the foundation of Bitcoin’s transaction validation, security assumptions, and decentralization. While Bitcoin can extend or optimize how UTXOs are used, replacing the model itself would require a disruptive hard fork that…

The UTXO model is harder to understand because it replaces familiar account balances with a consume-and-create system of individual outputs—but it is more secure because this structure minimizes mutable state, simplifies verification, and makes double spending and state corruption structurally impossible. What feels unintuitive to users is precisely what makes the model robust.