Blockchain Fundamentals
Conceptual background to the protocol specification
This section gives the conceptual background needed to read the Specification. It is context, not the validity contract itself — every rule that determines whether a transaction or block is valid is stated in the Specification section.
Blocks and the chain
A block is an 80-byte header followed by an ordered list of transactions. Each header contains the double-SHA-256 of the previous block's header (hashPrevBlock), so blocks form a chain: altering an old block would change its hash and break every block after it. The header also carries the Merkle root, a single hash committing to every transaction in the block (see Blocks).
Transactions and the UTXO model
A transaction consumes existing outputs and creates new ones. Each output carries an amount and a locking script (scriptPubKey); each input references a previous output and supplies an unlocking script (scriptSig) that satisfies it (see Transactions).
An output that has not been spent is an unspent transaction output (UTXO). The set of all UTXOs is the current ledger state — collectively it accounts for every satoshi in existence. Spending is all-or-nothing at the output level: consuming a 100-satoshi UTXO to pay 50 (with, say, 10 in fees) consumes the whole 100 and creates a new 40-satoshi output as change. Because outputs are independent and carry no shared balance, transactions spending different UTXOs can be validated in parallel.
The first transaction of every block is the coinbase: it has a null input and issues new coins, up to the block subsidy plus fees (see Economic Model).
Proof of work and consensus
Nodes agree on the next block through proof of work: a node assembles a candidate block and searches for a nonce that makes the header hash meet the target in nBits. Finding a solution is competitive; validating a proposed block is cooperative — a block that satisfies the consensus rules is accepted by other nodes, which express acceptance by building on it. The chain with the greatest cumulative work is the one nodes extend. A node earns a block's subsidy and fees only if the network builds on its block, aligning its incentive with rule-compliant behaviour.
Properties
The following properties all follow from the rules and structures above:
Immutability. Changing any transaction changes its block's Merkle root and hash, invalidating the proof of work of that block and every block after it.
Distributed validation. Every node applies the same consensus rules, so honest nodes converge on the same valid chain; a block is accepted only after independent validation.
Pseudonymity. Transactions reference public keys and scripts, not identities; any identity binding is off-chain (see Privacy and Identity).
Economic security. Rewriting a confirmed block requires out-pacing the honest chain's cumulative work, making history rewrites economically impractical.
Consensus by work. Influence over the chain is proportional to work performed ("one CPU, one vote"), a Sybil-resistant answer to the Byzantine Generals problem.
Scale. From Genesis the block-size limit is a miner-configured consensus cap and the maximum transaction size is 1 GB; Script imposes no protocol limit on the number of inputs or outputs.
Peer-to-peer verification. SPV lets a party verify a transaction's inclusion in a block with a Merkle proof, without the full chain (see Light Clients and SPV).
Last updated