pk.org: Computer Security/Lecture Notes

Hash Pointers, Merkle Trees, and Bitcoin

Study Guide

Paul Krzyzanowski – 2026-10-07

Bitcoin combines hash functions, digital signatures, and proof of work to maintain a shared transaction history without a central authority.

Hash Pointers and Blockchains

A hash pointer stores a reference to data together with a cryptographic hash of that data, so a reader can detect whether the data changed. A blockchain is a linked list in which each block holds a hash pointer to the previous block. The newest block is identified by a head pointer, and the first block is the genesis block.

Changing any block changes its hash, which invalidates the hash pointer in the next block, and so on up to the head. An attacker who alters a block must therefore recompute every hash pointer between that block and the head. The chain is a tamper-evident log. Protecting only the head pointer, for example by storing it securely or signing it, is enough to detect tampering anywhere in the chain.

A distributed ledger such as Bitcoin has no single head pointer that one authority can protect, since every participant holds its own copy of the chain and there is no central authority. Recomputing the hashes is easy, so an attacker who can distribute a rewritten chain could pass it off as the real one. Bitcoin instead makes adding each block computationally expensive through proof of work, so that rewriting history requires redoing that work for every block after the change.

Merkle Trees

A Merkle tree is a binary tree of hashes. Each leaf is the hash of one data item, each parent is the hash of its two children joined in order, and the single hash at the top is the Merkle root. Changing any item changes the root.

A Merkle proof, or proof of inclusion, is the set of sibling hashes along the path from one item to the root, together with their left-or-right positions. The verifier hashes the item, combines it with each sibling in turn, and compares the result with a trusted root. A proof for a balanced tree of \(n\) items contains about \(\log_2 n\) hashes. The item and the proof can come from an untrusted source, but the root must be obtained securely. A matching root establishes that the item belongs to the collection.

Bitcoin and Its Goals

Bitcoin is a decentralized payment system. A conventional payment system relies on a bank as a trusted third party that keeps the account balances, checks that a payer has the funds, and records each transfer. Bitcoin replaces the bank with a public ledger, a history of every transaction, replicated across many independent computers. Anyone can run one of these computers, verify the history, and submit payments without registering with any authority.

Removing the central authority creates two problems that the rest of the design solves. The first is identifying who may spend funds when there are no names or accounts, which Bitcoin does with cryptographic keys. The second is double spending. Digital data can be copied, so a payer can sign two transactions that spend the same funds. Each signature is valid on its own, so the participants need a way to agree on a single transaction history that decides which payment counts.

Users are pseudonymous rather than anonymous. Transactions do not carry names, but every transaction is public, and outside information can link an address to a person.

Keys, Signatures, and Addresses

Bitcoin identifies participants by keys rather than names or accounts. A user creates an elliptic curve public/private key pair on their own computer, and that key pair is the only information the user needs to keep in order to control funds. The private key signs transactions, and anyone can verify the signature with the public key. A valid signature shows that the signer holds the private key. It does not reveal who that person is, and it does not show whether the funds have already been spent.

A private key must be generated unpredictably and kept secret. A stolen key lets the thief spend the funds, and a lost key makes them permanently inaccessible, since there is no central authority that can reset it. A wallet is software that generates and stores a user’s keys and uses them to create transactions. It does not hold balances or transactions. Those are determined by the public ledger.

An address tells a sender how to construct an output that the recipient can spend. It contains a hash of the recipient’s public key plus a checksum. Spending the output requires presenting a public key that hashes to that value and a valid signature under that key. Hashing the key makes the address shorter and keeps the public key off the blockchain until the output is spent, in which case it appears as the owner of the transaction that is doing the spending. The checksum detects typing errors.

Transactions and Unspent Outputs

Bitcoin has no account balances. The ledger is the history of transactions, and the system tracks unspent transaction outputs (UTXOs). Each output records an amount and the condition for spending it. A user’s balance is the sum of the UTXOs that the user’s keys can spend.

A transaction has the following parts:

Verification and Replication

A full node is a computer that holds a complete copy of the blockchain, the ledger of every transaction since the genesis block. It verifies every block and transaction in that copy for itself rather than trusting any other node, and from that history it maintains the current UTXO set. For each new transaction, it checks that every referenced output exists and is unspent, that no output is used twice, that each public key hashes to the required value, that each signature is valid, and that the outputs do not exceed the inputs. The node takes the input amounts from the earlier outputs, not from the transaction.

A verified transaction is not yet part of the blockchain. The node holds it in memory as a pending transaction, and it does not change the confirmed UTXO set until a block containing it joins the node’s chain. Different nodes can hold conflicting pending transactions, so local verification cannot settle which of two competing spends will count.

There is no master copy of the blockchain. Full nodes around the world each hold their own copy, and no node has authority over another. A lightweight client can use a Merkle proof and an accepted block header to check that a transaction is in a block, but it relies on full nodes and miners for the other checks.

Blocks and Proof of Work

Miners collect pending transactions into blocks. Each block has a header and an ordered list of transactions. The header contains the following fields:

The block hash is the double SHA-256 hash of the header. Changing any transaction changes the Merkle root, the block hash, and the link from the next block.

Proof of work requires the block hash, interpreted as a 256-bit integer, to be at most the value of the target. Hash outputs cannot be predicted, so a miner repeatedly changes the nonce and hashes the header again until the result qualifies. A smaller target leaves fewer acceptable hashes and makes the search harder. Finding a qualifying header is expensive, but checking one takes a single hash computation. The nonce has a limited range, and trying every value usually does not produce a hash below the target. Miners therefore also vary other permitted header data, including the set of transactions, which changes the Merkle root and gives them a new header to search.

A miner’s hash rate is the number of hashes it can try per second. As the network’s total hash rate changes, the difficulty adjustment periodically recomputes the target so that blocks continue to arrive about every ten minutes on average. Every node derives the required target from the chain, so a miner cannot choose an easier one.

Agreement, Chain Selection, and Reorganization

Chain selection is how Bitcoin resolves double spending. Two transactions can carry valid signatures while spending the same output, and signatures alone cannot settle which one counts. Only an agreed history can.

Two miners can find valid blocks at about the same time. Both blocks extend the same previous block, so the chain forks into two competing branches, and nodes that received different blocks first temporarily follow different branches. To choose between branches, each node assigns every branch it knows about a score, which is its accumulated work, the total proof of work that its blocks represent. The node follows the valid branch with the highest score. Miners extend the branch they follow, so one branch soon gains more work than the other, and every node converges on it.

The work credited to a block is determined by the target it was mined under, with a smaller target counting for more work. It is not the number of hash attempts the miner actually made. When all blocks have the same target, the branch with the most work is also the longest one, which is why the rule is often described as following the longest chain. Branch selection depends only on work and validity. There is no vote among nodes, and running more nodes does not add mining power. Valid proof of work does not make invalid transactions acceptable, because every node validates each block’s contents independently.

When a competing branch overtakes the one a node had followed, the node performs a chain reorganization. It undoes the abandoned branch’s changes to its UTXO set and applies the winning branch. Transactions from the abandoned branch become pending again if they are still valid. A transaction that conflicts with a spend in the winning branch is rejected.

The 51% Attack and Confirmations

A 51% attack refers to control of a majority of the network’s hash rate, not of nodes or coins. An attacker with that much hash rate can mine a private branch faster than the honest miners on average, replace recent blocks, double-spend its own funds, and keep chosen transactions out of blocks. It cannot forge other users’ signatures or create coins beyond what the rules allow, because every full node checks those rules. An attacker with less than half the hash rate can still succeed by luck, but the chance falls as more blocks are added.

A transaction has one confirmation when it is in a block in the active chain and gains another with each later block. More confirmations make a transaction more expensive to reverse, since an attacker would have to redo the work of every block since then. The protocol does not require any number of confirmations. The recipient decides how many to wait for, weighing the value of the payment against the delay, and six is the traditional guideline for valuable payments. No number of confirmations is a guarantee.

Mining Rewards

The first transaction in every block is the coinbase transaction (no relationship to the Coinbase company). It has no inputs and lets the miner claim the block reward, which consists of newly created bitcoin, called the block subsidy, plus the fees of the block’s transactions. Nodes reject a block whose coinbase claims more than the rules allow.

The subsidy halves on a fixed schedule, which limits the total supply to about 21 million BTC and makes fees a growing share of the reward over time. The reward is the incentive for miners to participate. Mining consumes electricity and hardware, and without payment for finding blocks there would be no reason to do it, and no proof of work to protect the chain. A reward in an abandoned branch cannot be spent, so miners are paid only for blocks the network accepts.

What You Don’t Need to Study

The following are not required for exams:

Next: Terms we covered