Dossier 12 Source-led history · Edition 1.0
How Bitcoin’s Blockchain Works: Transactions, Proof of Work and Finality
Bitcoin is not a line of balances periodically certified by miners. It is a replicated state transition in which independently operated nodes verify spending conditions, blocks commit to ordered transactions, and proof of work helps valid branches converge.
In this dossier
At a glance
Verified record
| Stage | Protocol object or rule | What is independently checked | Important distinction | Source |
|---|---|---|---|---|
| Transaction construction | Inputs identify prior outpoints; outputs specify satoshis and scripts | Values, authorization data, lock conditions, and absence of duplicate inputs | Private keys can authorize signature-based spends; they do not contain coins | [2] Bitcoin transaction primitives[3] Transaction consensus verification |
| Mempool admission | A node’s local set of unconfirmed transactions | Consensus prerequisites plus local fee, standardness, conflict, and resource policy | There is no single global mempool | [4] Bitcoin Core validation |
| Candidate block | Coinbase followed by selected transactions | Subsidy-plus-fee limit, dependencies, block limits, and transaction validity | Consensus does not require one transaction-selection algorithm | [4] Bitcoin Core validation |
| Commitments | Header transaction Merkle root and SegWit witness commitment | Calculated roots must match committed values | The header root commits txids; witness data uses the BIP141 coinbase commitment | [9] BIP 141 — Segregated Witness[6] Merkle-root implementation |
| Block header | 80 bytes: version, previous hash, Merkle root, time, nBits, nonce | Parent relation, target encoding, time constraints, and header hash | The timestamp is miner supplied within consensus bounds | [5] Block-header primitives |
| Proof of work | Double-SHA-256 header hash at or below target | Target is valid for the height and proof satisfies it | Difficulty describes the target; proof of work does not validate scripts | [7] Proof-of-work and difficulty adjustment |
| Chain selection | Valid branch with greatest accumulated chainwork | All blocks on the candidate branch must pass consensus | ‘Longest chain’ is shorthand and can be wrong when work per block differs | [4] Bitcoin Core validation |
| Confirmations and reorgs | Active-chain depth above the containing block | A competing valid branch can cause disconnect and connect operations | Confirmations provide probabilistic burial, not absolute finality | [1] Bitcoin: A Peer-to-Peer Electronic Cash System |
Bitcoin tracks spendable outputs rather than protocol-level accounts
A Bitcoin transaction output contains an integer value in satoshis and a script that states the conditions for spending it. While that output remains unspent, it belongs to the node’s UTXO set. A later transaction input references the earlier transaction identifier and output index—often written txid:vout—and supplies the witness or script data needed to satisfy the condition. Validation consumes an output in full; any remainder must be deliberately recreated as change.
Wallet interfaces sum relevant UTXOs and display the result as a balance, but an address or wallet balance is not the primitive maintained by consensus. A private key likewise does not store bitcoin. It enables a wallet to produce a signature accepted by a particular spending condition. This model matters for history and forensics: one payment can consume several earlier outputs and create several new ones, and apparent ‘movement between addresses’ is an interpretation of that graph rather than an account transfer recorded by the protocol.
A wallet selects inputs, creates outputs, and signs the relevant commitment
To pay, a wallet selects enough UTXOs to cover recipient outputs and the intended fee, chooses scripts for the recipient and usually for change, and signs according to the input types and signature-hash rules. The fee is not a special output. It is the difference sum(inputs) − sum(outputs), which a miner may collect through the block’s coinbase transaction. Values must remain within consensus ranges, and an ordinary transaction cannot create more output value than its available inputs.
Scripts allow more than a simple single-key payment. Current output types can commit to key hashes, witness programs, multisignature arrangements, timelocks, or Taproot conditions. The exact bytes covered by a signature depend on the spending path and signature-hash mode. A readable explainer can use a one-key example, but should not imply that every transaction reveals a public key in advance, uses the same witness structure, or authorizes all outputs in precisely the same way.
Nodes validate before relay, and each node owns its mempool policy
A wallet sends the serialized transaction to a node, which performs structural and contextual checks before accepting it into its mempool. The node verifies that referenced outputs exist and are available in its current view, values do not overflow or inflate supply, scripts and signatures succeed, and lock constraints are met. It also applies local policy covering standard forms, minimum fees, resource limits, ancestor relationships, and conflicts or replacements. Peers repeat their own checks rather than trusting the first node.
Consensus validity and relay policy are deliberately distinct. A transaction one node declines to store or forward can still be consensus-valid if a miner includes it in a valid block. There is also no authoritative network-wide mempool: nodes can see different transactions because of timing, connectivity, eviction, fee policy, replacement rules, or conflicting spends. An unconfirmed transaction is therefore a propagated proposal, not a reservation of an output or a promise of eventual confirmation.
From a signed transaction to confirmations
Every peer performs its own checks. Policy governs local mempool behavior; consensus governs whether a block can change accepted chainstate.
- 01Select UTXOs
txid:voutThe wallet identifies existing outputs that can fund the payment and fee.
- 02Create and sign
Σin − Σout = feeOutputs define new spending conditions; witness or script data satisfies the old conditions.
- 03Apply local policy
mempoolA node checks consensus prerequisites plus its own relay, fee, conflict, and resource rules.
- 04Relay to peers
P2PPeers request and independently evaluate the transaction; no global mempool is created.
- 05Build a candidate
coinbase + txsA miner selects and orders transactions, calculates fees, and constructs the commitment roots.
- 06Search for proof
SHA256d(header) ≤ targetThe miner varies header and template data until a qualifying hash is found.
- 07Validate the block
full nodePeers verify proof of work, commitments, reward, scripts, UTXOs, and every consensus limit.
- 08Connect chainstate
1 confirmationA valid best-chain block spends old UTXOs, creates new ones, and gives included transactions one confirmation.
- 09Extend or reorganize
greatest chainworkDescendants add confirmations; a higher-work valid branch can later disconnect and replace blocks.
Transaction relay does not reserve inputs, proof of work does not excuse an invalid block, and confirmations reduce reorganization risk without creating deterministic finality.
A miner assembles a candidate block and commits to its contents
A miner or block-template service selects transactions that fit consensus limits and whose dependencies can be satisfied in block order. Fee rate and package economics commonly influence selection, but Bitcoin consensus does not require a universal auction algorithm. The first transaction is the coinbase. It has a special input and creates outputs up to the permitted block subsidy plus the fees of included transactions; its output cannot be spent until it has matured for 100 blocks.
Transaction identifiers are arranged into a Merkle tree whose root enters the block header. Changing an included transaction changes its branch and therefore the root. SegWit requires an additional witness commitment: witness transaction identifiers form a separate Merkle root committed in a designated coinbase output, which is then indirectly committed by the ordinary transaction root. This nested construction is why it is imprecise to say that the header’s transaction Merkle root directly contains every witness byte.
Proof of work commits an 80-byte header to a target
The serialized header contains version, the previous block hash, the transaction Merkle root, a timestamp, the compact target nBits, and a nonce. Miners vary the nonce and other mutable template data and repeatedly double-SHA-256 the header. A proof succeeds when the resulting hash, interpreted as a number under Bitcoin’s rules, is no greater than the target. Verification is inexpensive even though finding a qualifying hash is deliberately probabilistic and computationally costly.
The target is the consensus object; difficulty is a convenient ratio comparing it with a reference target. On mainnet, the target is recalculated every 2,016 blocks toward a two-week timespan, subject to adjustment bounds in the implementation. Ten minutes is therefore an average design target, not a schedule for the next block. Proof of work says that computation was committed to a header and its ancestry. It does not by itself prove transaction validity, authenticate a real-world fact, or guarantee that a miner followed relay policy.
Receiving nodes verify the miner’s proposal before changing chainstate
A full node checks the header, parent, proof of work, target, time rules, size and weight limits, transaction and witness commitments, coinbase form and reward, and every transaction’s scripts and state transition. It confirms that inputs refer to available UTXOs and that the block contains no prohibited double spend or excess creation. A block with immense proof of work is still rejected if one consensus check fails. Miners order valid candidates; they do not receive authority to rewrite the validation rules of unchanged nodes.
If the block is valid and belongs on the best available branch, the node connects it by removing spent outputs and adding newly created outputs to its UTXO database. It also updates indexes and removes confirmed or conflicting transactions from the local mempool as appropriate. The node’s accepted chain is thus the result of deterministic validation plus branch comparison. ‘Trust the blockchain’ is incomplete shorthand: the security property comes from independently enforced rules and accumulated work on a branch that passed them.
Confirmations increase burial, but Bitcoin has no absolute finality flag
A transaction in the current tip’s block has one confirmation; every active-chain descendant adds another. Near-simultaneous valid blocks can give nodes different tips temporarily. Nodes compare valid branches by accumulated chainwork, not simply by counting blocks. When a branch with more work becomes available, a node can disconnect blocks from its former branch, reverse their UTXO changes, and connect the winning branch. This is a chain reorganization, not retroactive editing of a block’s bytes.
Transactions removed during a reorg may return to the local mempool if they remain valid and satisfy policy. A conflicting transaction confirmed on the winning branch may instead make them invalid. Confirmation counts can consequently decrease or return to zero. Greater depth normally makes reversal progressively more expensive and operationally unlikely, but the protocol never emits an irreversible-finality certificate. ‘Six confirmations’ is a widely used risk convention whose adequacy depends on transaction value, threat model, hash-power assumptions, and the recipient’s tolerance—not a consensus guarantee.
The chain proves protocol commitments, not every claim attached to them
A block timestamp is selected by its miner within validity constraints and should not be treated as a certified real-world instant. A transaction proves that its consensus spending conditions were satisfied; it does not prove the parties’ identities, the purpose of payment, delivery of goods, or legal ownership outside the protocol. Labels assigned to addresses by explorers and analysts are external evidence that can be useful but remain separate from block validation.
Simplified-payment-verification clients can check header proof of work and a Merkle path showing that a transaction was committed in a block, but they do not replay every script and UTXO transition as a full node does. Software defects and consensus upgrades introduce additional social and implementation risks distinct from routine reorganization probability. The technically accurate conclusion is bounded: Bitcoin makes a particular transaction history expensive to replace and independently auditable under shared rules; it does not turn every interpretation of that history into truth.
Protocol state-transition sketch
Implementation-neutral pseudocode separates wallet construction, local policy, mining, consensus validation, and best-chain activation.
wallet:
inputs = select_unspent_outputs(amount + target_fee)
outputs = [recipient(amount)]
remainder = sum(inputs) - amount - target_fee
if remainder_is_economic(remainder):
outputs.append(change(remainder))
tx = sign_transaction(inputs, outputs)
receiving_node:
require basic_consensus_checks(tx)
require scripts_and_inputs_valid(tx, current_utxo_view)
if local_mempool_policy_accepts(tx):
store_and_relay(tx)
miner:
block.transactions = [coinbase(subsidy + fees), selected_transactions]
block.header.merkle_root = transaction_merkle_root(block)
while sha256d(block.header) > target:
mutate_candidate(block)
broadcast(block)
full_node:
require header_and_proof_valid(block)
require commitments_and_limits_valid(block)
require every_state_transition_valid(block, parent_utxo_view)
add_candidate_branch(block)
activate_valid_branch_with_greatest_chainwork()
confirmations(tx) = active_tip_height - containing_block_height + 1This is explanatory pseudocode, not executable Bitcoin Core code. Bitcoin Core separates these responsibilities across multiple functions, caches, and validation contexts.
Evidence discipline
What the record establishes
Bitcoin transactions consume identified previous outputs and create new outputs containing values and spending conditions.
[2] Bitcoin transaction primitives · [3] Transaction consensus verificationA block header contains version, previous-block hash, Merkle root, timestamp, compact target, and nonce.
[5] Block-header primitivesUnder SegWit, witness data is committed through a witness Merkle root placed in the coinbase commitment structure.
[9] BIP 141 — Segregated Witness · [6] Merkle-root implementationBitcoin Core validates blocks and transactions before connecting their UTXO changes to chainstate.
[4] Bitcoin Core validation · [3] Transaction consensus verificationBitcoin nodes compare valid branches using accumulated chainwork rather than block count alone.
[4] Bitcoin Core validation · [1] Bitcoin: A Peer-to-Peer Electronic Cash SystemConfirmations provide probabilistic economic settlement rather than absolute protocol finality.
[1] Bitcoin: A Peer-to-Peer Electronic Cash System · [4] Bitcoin Core validationReplace-by-fee and standard transaction relay are policy behaviors distinct from base consensus validity.
[11] BIP 125 — Opt-in full replace-by-fee signaling · [13] Bitcoin Core transaction policy documentationLimits
What this record does not establish
- The walkthrough describes current mainnet concepts at a high level; exact validation paths depend on software version and transaction type.
- Mempool contents and policy are local. A node’s rejection from its mempool does not necessarily prove that a transaction would violate block consensus.
- The header transaction Merkle root commits transaction identifiers; SegWit witness bytes are committed through the separate BIP141 witness commitment.
- Ten minutes is a target average, not a guaranteed interval, and header timestamps are miner supplied within consensus constraints.
- The valid chain with greatest accumulated work is more precise than ‘the longest chain.’
- Coinbase outputs have a 100-block maturity rule; ordinary confirmed outputs should not be described as having the same consensus delay.
- Confirmation depth does not create absolute finality, and no universal confirmation count is safe for every threat model.
- On-chain data does not prove off-chain identity, beneficial ownership, legal purpose, or delivery of goods.
Direct answers
Frequently asked questions
Does Bitcoin’s blockchain store account balances?
No protocol-level account balance is stored. Nodes maintain a set of unspent transaction outputs, each with a value and spending condition. Wallet software finds relevant UTXOs and sums them to display a familiar balance.
Do miners decide whether a Bitcoin transaction is valid?
Miners choose transactions and propose an ordering in proof-of-work blocks, but independently operated full nodes verify every consensus rule. A node rejects a block with invalid scripts, unavailable inputs, excess issuance, or invalid proof of work regardless of who mined it.
What is a Bitcoin confirmation?
A transaction has one confirmation when its block is in the node’s active chain. Each valid descendant adds another, increasing the amount of accumulated work burying it. Confirmation is therefore chain depth, not a separate message sent by the miner.
Are six confirmations absolutely final?
No. Six is a widely used risk convention, not a consensus guarantee. A valid branch with greater accumulated work can reorganize blocks and reduce a transaction’s confirmation count; the appropriate threshold depends on value, threat model, and risk tolerance.
Source register
Sources, datasets and technical references
Retrieved and reviewed 9 August 2026- Bitcoin: A Peer-to-Peer Electronic Cash SystemSatoshi NakamotoBitcoin.org · primary specification
The original transaction-chain, timestamp-server, proof-of-work, network, incentive, Merkle-tree, and simplified-verification design.
Open source - Bitcoin transaction primitivesBitcoin Core · primary source code
The serialized input, outpoint, output, witness, value, and transaction data structures.
Open source - Transaction consensus verificationBitcoin Core · primary source code
Consensus checks for transaction structure, duplicate inputs, values, locks, and input availability.
Open source - Bitcoin Core validationBitcoin Core · primary source code
Mempool admission, block checking, connect and disconnect behavior, best-chain activation, and chainstate transitions.
Open source - Block-header primitivesBitcoin Core · primary source code
The six serialized header fields, block structure, and header hash operation.
Open source - Merkle-root implementationBitcoin Core · primary source code
Construction of transaction and witness Merkle roots.
Open source - Proof-of-work and difficulty adjustmentBitcoin Core · primary source code
Target calculation, retarget bounds, proof checking, and chainwork calculation.
Open source - Mainnet consensus parametersBitcoin Core · primary source code
Mainnet proof-of-work spacing, timespan, target limit, and other consensus parameters.
Open source - BIP 141 — Segregated WitnessBitcoin Improvement Proposals · primary specification
Witness transaction identifiers, witness Merkle root, coinbase witness commitment, weight, and witness-program rules.
Open source - BIP 113 — Median time-pastBitcoin Improvement Proposals · primary specification
Use of median time-past for transaction lock-time consensus calculations.
Open source - BIP 125 — Opt-in full replace-by-fee signalingBitcoin Improvement Proposals · primary policy specification
The opt-in replacement policy and its distinction from consensus.
Open source - BIP 341 — TaprootBitcoin Improvement Proposals · primary specification
Current Taproot output and witness-program consensus rules.
Open source - Bitcoin Core transaction policy documentationBitcoin Core · primary software documentation
The project’s explicit separation and documentation of transaction relay and mempool policy.
Open source
Cite this dossier
A dated, versioned reference
Degrees of Satoshi editorial project. “How Bitcoin’s Blockchain Works: Transactions, Proof of Work and Finality.” Degrees of Satoshi, version 1.0. Published 9 August 2026; last reviewed 9 August 2026. https://degreesofsatoshi.com/history/how-bitcoin-blockchain-works/
Contemporary primary records are preferred. Protocol behavior, business failures and government policy are treated as separate evidence categories. Interpretive claims are explicitly bounded; corrections should cite a source at least as strong as the record being revised.
Read the research standards