Bitcoin is a distributed system that maintains a shared record of transactions without a central authority. Instead of relying on a bank to keep track of who owns what, participants use cryptography to verify payments and a shared set of rules to agree on the transaction history.

To understand how it works, we’ll start with two structures built from hashes: hash pointers and Merkle trees. Then we’ll see how keys, transactions, blocks, and mining fit together. We focus on the cryptographic mechanisms and agreement on transaction history. We do not cover Bitcoin’s scripting language, the details of its peer-to-peer protocol, wallet implementation, or payment channels.

Sections and subsections marked Optional are background reading and are not exam material. The accompanying study guide identifies the concepts to study. The example keys, target, network statistics, and historical reward table illustrate the mechanisms; their exact values do not need to be memorized.

Hash Pointers and Blockchains

Pointers let one data element refer to another. A pointer may be a memory address, a filename, or a server name and object identifier. It tells us where to find something, but not whether that data has changed.

A hash pointer stores both a reference to some data and a cryptographic hash of that data. When we retrieve the data, we compute its hash and compare it with the stored value. A mismatch reveals a change, assuming a secure hash function and a stored hash the attacker cannot replace.

We can build a linked list where each block contains data and a hash pointer to the previous block. A list connected this way is a blockchain.

To add a block, we copy the current head hash pointer into the new block and update the head to refer to the new block and contain its hash. The head identifies the newest block. Following the links backward eventually reaches the first block, called the genesis block.

Suppose an attacker changes Data-1 in the figure. We can detect that because its hash no longer matches the hash stored in Data-2. The attacker could update that hash, but doing so changes Data-2. Now the hash in Data-3 is wrong and needs to be updated too.

The attacker would need to change every hash pointer leading up to the head. As long as we protect the head pointer, we can detect tampering anywhere in the chain. For example, we could store the head securely or sign it. We also need to know which head is current so that an attacker cannot pass off an older copy as the latest history.

This gives us a tamper-evident log. If the attacker can replace the head too, recomputing all those hashes is easy. Bitcoin therefore needs an additional mechanism to agree on the head and make rewriting history expensive.

Merkle Trees

Suppose we want to download a large file from servers we don’t trust. A hash of the complete file lets us verify it after the download finishes. But we might want to check individual chunks as they arrive, without downloading all the other content.

A Merkle tree is a tree of hashes that lets us do this. At the bottom, each leaf contains the hash of one data chunk. Each parent contains the hash of its two child hashes joined together, in order. We repeat this until we reach a single hash at the top, called the Merkle root.

Changing a chunk changes its hash, which changes the hashes above it, all the way to the root. The root therefore serves as a compact fingerprint for the entire collection.

To verify Data-2 in the figure, we need the chunk itself, the trusted Merkle root, and a small subset of the tree’s hashes. This subset is called a Merkle proof, or a proof of inclusion. Despite the name, it isn’t a logical proof written as a sequence of arguments. It is a package of hash values and their positions that lets us perform a check.

The package contains the sibling hash at each level on the way from the chunk to the root. A sibling is the other child of the same parent. For Data-2, the proof contains just two hashes from the tree:

• \(H_3\), the hash beside \(H_2\). It represents Data-3, which we don’t need to download.

• \(H_{0,1}\), the hash beside \(H_{2,3}\). It represents the entire subtree containing Data-0 and Data-1, neither of which we need to download.

The proof also identifies which hash goes on the left or right when joining each pair. Using this information, we work our way up the tree:

1. Compute the hash of Data-2 to obtain \(H_2\).

2. Join \(H_2\) with \(H_3\) and hash them to obtain \(H_{2,3}\).

3. Join \(H_{0,1}\) with \(H_{2,3}\), hash them, and compare the result with the known Merkle root.

We compute \(H_2\), \(H_{2,3}\), and the candidate root ourselves. The server only needs to supply the sibling hashes we cannot compute without the missing data. If our root matches the trusted root, the chunk belongs to that collection. This is why a small subset of the tree is enough to check membership without downloading the rest of the content.

Proof size grows logarithmically. A balanced tree with \(2^{20}\) chunks, about a million, needs only 20 sibling hashes per proof. With 32-byte hashes, that’s 640 bytes plus position information.

The data and proof can come from an untrusted server, but the Merkle root must be obtained securely. Otherwise, an attacker could change the data and supply a matching root. A verified signature or an authenticated connection to a trusted source can protect the root.

A proof establishes that the chunk belongs to the collection. It doesn’t establish whether its contents are correct.

Bitcoin’s Goals

Bitcoin was announced on October 31, 2008 by a person or group using the pseudonym Satoshi Nakamoto. The network began operating in January 2009. It was designed as an open, decentralized payment system, with no bank, government, or central operator in charge. Anyone can participate without registering with an authority.

Users don’t need to provide their names. They can create keys on their own computers and use as many addresses as they like. This is often described as anonymity, but pseudonymity is more accurate. Every transaction is public, and information from outside Bitcoin can connect an address to a person. Exchanges and other businesses that provide access to Bitcoin can also be regulated.

One problem is that digital information can be copied. Alice could sign a transaction paying Bob and another paying Carol using the same funds. Both signatures would be valid. This is the double-spending problem. Signatures establish who authorized a payment, but the network still needs a way to agree on which payment counts.

Accounts and Transaction Outputs

To understand how Bitcoin tracks money, start with the familiar model of a bank account. The bank maintains an account balance for each customer. When Alice pays Bob $100, the bank checks that she has enough money, subtracts $100 from her balance, and adds it to Bob’s. It also keeps transaction records for auditing, recovery, and checking that its accounts agree.

The bank is a trusted third party. We rely on it to keep accurate records and transfer money correctly. That creates risks if it makes a mistake, goes offline, closes, or has a corrupt employee. It can also freeze accounts, including under government orders. Central control makes disputes and recovery possible, but gives the bank control over access to the money.

Bitcoin keeps a history of transactions, called the ledger, and tracks which transaction outputs remain available to spend. Each output records an amount and a condition that must be met to spend it, usually proof of control over a private key. These available outputs are called unspent transaction outputs (UTXOs).

When someone spends an output, the new transaction consumes it and creates new outputs for the recipients. The original output must be spent in full. If the sender needs only part of its value, the transaction sends the remainder back as change.

Bitcoin has no account balances. A wallet calculates its balance by adding up the UTXOs it can spend. The UTXO model is a design choice rather than a requirement of decentralization. Other cryptocurrencies, such as Ethereum, use account balances.

Keys and Addresses

So far, we have talked about people sending and receiving bitcoin, but we haven’t defined how the network identifies them. Bitcoin uses keys instead of names or account numbers.

Keys

A wallet generates a public/private key pair using elliptic curve cryptography. Bitcoin uses the secp256k1 curve. The private key is a random number chosen from its valid key range, represented in 256 bits. The public key is derived from it mathematically.

When someone creates a transaction, they sign the required transaction data with their private key. Anyone can verify that signature using the corresponding public key. This proves that whoever created the signature had the private key. It doesn’t reveal that person’s name.

Our transaction example uses the Elliptic Curve Digital Signature Algorithm (ECDSA).

Predictable randomness can make a private key guessable. A stolen key can let an attacker spend the funds, while losing the only usable copy can make them permanently inaccessible. There is no central service that can reset the key.

Addresses

To receive a payment, the recipient gives the sender a Bitcoin address. The address tells the sender’s wallet how to create an output that the recipient will be able to spend.

Bitcoin supports several ways of stating the condition for spending an output. The traditional pay-to-public-key-hash (P2PKH) format requires a public key that hashes to a stored value and a valid signature under that key. We use P2PKH for our transaction examples.

To generate a P2PKH address, we proceed as follows:

1. Start with the public key and compute its SHA-256 hash.

2. Hash that result with RIPEMD-160, another hash function, to produce a 160-bit fingerprint.

3. Add a network/version identifier and a checksum, then encode the result as text using Base58Check.

Using a 160-bit hash makes addresses shorter. It also keeps the public key off the blockchain until an output paying that address is spent, provided the address is not reused. The sender’s wallet decodes the address and creates an output requiring a matching public key and a valid signature to spend it. Later, when the recipient spends that output, the network checks both. The address checksum helps detect typing errors, but it can’t tell whether the address belongs to the intended person.

1E99423A4ED27608A15A2616F8D7E9E900E2F45B5F7C3D1A29E1234ABCD56789

023BA7C7324928E35BDD29031250247A316D3A688DE4CE5B6BF41E8E93101ABE79

19AbQsRSePtWcFyxiH4nSxVtCaUDTRJo5L

Transactions and Verification

A transaction contains inputs and outputs. Inputs identify where the bitcoin comes from by referring to outputs of earlier transactions. Each reference contains a transaction identifier (txid), which is a hash of the transaction’s data, and an index selecting one of that transaction’s outputs.

Suppose Bob controls two UTXOs worth 0.2 BTC each and wants to pay Carol 0.3 BTC. He chooses a fee of 0.0001 BTC. His transaction has the following components:

Bob must spend both original outputs completely, even though Carol receives only part of their value. His wallet creates another output sending 0.0999 BTC back to himself as change. The remaining 0.0001 BTC is the transaction fee, which the miner can collect when including the transaction in a block:

\[\text{fee}=\sum\text{input values}-\sum\text{output values} =0.4-(0.3+0.0999)=0.0001\text{ BTC}.\]

Change is an ordinary output back to the sender. There is no separate fee output in Bob’s transaction.

Bob signs a hash of the required transaction data. With the usual signature mode, SIGHASH_ALL, this covers every input and every output, including output amounts and spending conditions. Changing Carol’s payment would invalidate the signatures. Different inputs may require different keys.

Bob sends the transaction to one or more Bitcoin nodes, which can forward it to their peers. Each full node, a participant that independently verifies the entire transaction history and maintains the current UTXO set, checks the transaction. For our P2PKH example, the checks include:

1. Check the inputs. Each referenced output must exist and be unspent. The transaction cannot use the same output twice.

2. Check the public keys. Each key must hash to the value required by the previous output it is being used to spend.

3. Verify the signatures. Each signature must be valid for the required public key and transaction data.

4. Check the amounts and other rules. The output total cannot exceed the input total. Amounts must be in the allowed range, and any timing restrictions must be met.

The node looks up the input amounts in the previous outputs. It doesn’t take Bob’s word for how much they contain.

Receiving and checking Bob’s transaction does not change the node’s confirmed UTXO set. The node can hold the transaction in its mempool, a collection of pending transactions, and track its proposed spends separately. When a block becomes part of the node’s active chain, the node applies its transactions in order, removing spent outputs from the confirmed UTXO set and adding new ones. A second attempt to spend the same output in that history fails.

Mempools differ because nodes receive transactions in different orders and use different acceptance policies. A node may accept Bob’s payment into its mempool while another node has a conflicting payment. Local verification alone doesn’t settle which payment will enter the blockchain.

Blocks and Replication

Transactions arrive from many users at different times. Miners collect them into blocks and compete to add the next block to the chain. This lets the network agree on batches of transactions instead of handling a separate consensus decision for every payment. Miners are paid for this work; we will cover the reward later.

Each block contains a header and an ordered list of transactions. The header occupies 80 bytes and contains the following fields:

Bitcoin computes the block hash by applying SHA-256 twice to the header’s bytes. Each header contains the previous block’s hash, linking the blocks together. That hash also identifies the previous block when a node requests it from a peer.

Transactions and the Merkle Root

The transactions in a block are represented by a Merkle tree, with transaction identifiers at the leaves. Changing the data covered by one of those identifiers changes the hashes up to the root. Since the root is in the header, this also changes the block hash and breaks the link from the next block.

A lightweight client can use a Merkle proof to check a transaction’s inclusion without downloading the block’s other transactions. It must also establish that the header belongs to the accepted chain. The proof doesn’t check all transaction rules or show that an output remains unspent. This approach, described as simplified payment verification in the original Bitcoin paper, relies on miners to enforce validity and provides less assurance than full validation.

Replicated Copies

Complete copies of the blockchain are stored by archival full nodes around the world. There is no master node or master copy. Each full node checks the blocks for itself and keeps track of the unspent outputs.

A pruned full node performs the same validation but discards old block data to save storage. Lightweight wallets keep less information and depend more on other servers. Not every participant stores the complete history.

The Size of the Network

Some example figures help put this replication in perspective. The following snapshot is dated October 4, 2026:

These are example measurements, not protocol limits. Node counts depend on which nodes can be discovered, and block sizes and transaction counts vary. Blocks can fall outside the rough range above, as the sample block below illustrates.

Distributed Agreement and Mining

Return to Alice’s attempt to spend the same money twice. She signs one transaction paying Bob and another paying Carol, both using the same UTXO. Each signature is valid, and either transaction could be accepted if considered on its own before the output is spent. Different nodes may receive different payments first. Checking signatures cannot settle this disagreement.

Blocks let us put transactions in a sequence, but we still need to agree on which blocks count. Once one payment appears in the accepted history, the conflicting payment cannot spend that output again in the same history. The network needs to meet three goals:

• Participants should agree on the same sequence of valid blocks as updates reach them.

• Changing that sequence should become harder as more blocks are added.

• New blocks should be added slowly enough that they usually reach other nodes before competing blocks appear.

Miners work concurrently. Proof of work limits how often anyone can successfully propose a block, although competing blocks still appear occasionally.

Proof of Work and Hashcash

The idea comes from Hashcash, introduced by Adam Back in 1997 to make activities such as sending spam more expensive. Senders had to find a value whose hash met a requirement. Finding it took repeated attempts, but checking it took little work. Bitcoin adapts this idea to adding blocks.

Suppose we want a hash that starts with 20 zero bits. We can’t predict which input will produce that result, so we have to try different inputs and hash each one. Each attempt has about a one-in-a-million chance of success. On average, finding a match takes \(2^{20}\) attempts, although a lucky search could finish immediately.

The successful input provides a proof of work. Finding it is expensive, while anyone can check that its hash meets the requirement.

Bitcoin interprets the double SHA-256 header hash as a 256-bit integer and requires:

\[\operatorname{SHA256}(\operatorname{SHA256}(\text{header}))\leq T.\]

Here, \(T\) is the target, the largest acceptable hash value. A smaller target makes mining harder because fewer possible hashes qualify. Leading zero bits help us picture the requirement, but Bitcoin compares the entire hash value with the target.

000000000000000000021ef00000000000000000000000000000000000000000

Miners change the nonce and hash the header repeatedly. A 32-bit nonce gives \(2^{32}\) possibilities, but the sample target above requires about \(2^{79}\) attempts on average to find a valid block. Trying every nonce for one otherwise unchanged header therefore covers only about \(1/2^{47}\) of the expected search, and none may work. To keep searching, a miner can adjust permitted timestamp values, change the selected transactions, or change an extra nonce in the block’s first transaction. Transaction changes alter the Merkle root, providing a different header to try.

This search is called mining. Once a miner finds a suitable header, anyone can verify its proof of work by hashing that header and checking the result. Checking the complete block takes additional work because its transactions must also be verified.

Adding a Block

Anyone can run a node to receive and verify transactions and blocks. With mining software and hardware, a participant can also build candidate blocks and try to mine them. Running a full node does not require mining.

A new block is added through the following process:

1. A miner collects transactions into a candidate block and searches for a header hash that meets the target.

2. When it succeeds, it broadcasts the block to its peers.

3. Each full node checks the target, proof of work, Merkle root, and transactions against the protocol’s rules.

4. After considering the new block, the node selects the valid branch with the greatest accumulated work. The block may extend the current chain or make a previously weaker branch overtake it.

Each node validates blocks and selects its active chain independently. There is no majority vote of nodes. Extra nodes don’t give someone more mining power, and valid proof of work doesn’t make invalid transactions acceptable. When branches have equal work, nodes can temporarily keep different choices until one branch pulls ahead.

Difficulty Adjustment

A miner’s hash rate is the number of hashes it can try per second. Adding mining hardware increases the network’s combined hash rate. Without changes to the target, blocks would arrive faster. Bitcoin adjusts its target every 2,016 blocks, aiming for 10 minutes per block on average. At that rate, an adjustment period lasts about two weeks.

The Difficulty Adjustment Algorithm (DAA) checks how long the preceding period took, using block timestamps. If blocks arrived too quickly, it lowers the target to make mining harder. If they arrived too slowly, it raises the target. Each adjustment is limited to a factor of four in either direction, with a maximum target limiting how easy mining can become.

Every node calculates the required target from the chain, so a miner cannot choose an easier one. Individual blocks can still take much less or much more than ten minutes.

Mining Hardware and Pools (Optional)

When Bitcoin started, people mined with CPUs. They moved to GPUs, then field-programmable gate arrays (FPGAs), and eventually application-specific integrated circuits (ASICs) designed for hashing. The higher a miner’s hash rate, the better its chance of finding a block.

Finding a block is like winning a lottery. A miner with 1% of the network’s hash rate expects roughly 1% of the blocks over time, but may wait a long time between wins. Mining pools let miners combine their efforts and share rewards. Miners submit hashes meeting an easier pool target to show their contributions. Occasionally, one also meets Bitcoin’s target and produces a block.

Pools make payments more predictable for individual miners, but often give the pool operator control over which transactions go into proposed blocks.

Competing Chains and Accumulated Work

Two miners may find valid blocks at nearly the same time, both referring to the same previous block. Some nodes hear about one first, while others hear about the other. For a while, the network has two competing branches.

Bitcoin resolves this by comparing the accumulated work in each chain, the total proof of work that its blocks represent. The work credited to a block is the expected number of hash attempts needed to meet its target, which is approximately \(2^{256}\) divided by the target. Halving the target doubles the credit. Accumulated work doesn’t measure how many attempts the miner actually made. A miner who found a block on the first attempt receives the same credit as one who searched for an hour. Bitcoin’s source code calls this quantity chainwork.

Nodes follow the valid chain with the most accumulated work. The original Bitcoin paper describes this rule as following the longest chain, “which has the greatest proof-of-work effort invested in it.” The two descriptions agree when every block was mined under the same target, which was nearly the case when the paper was written. Since the target changes over time, a long chain of blocks mined under an easy target can contain less work than a shorter chain mined under a hard one, so counting blocks alone can give the wrong answer. Bitcoin’s software switched from comparing chain length to comparing accumulated work in July 2010. The longest-chain description remains a useful approximation.

This connects back to the head pointer at the beginning of the article. Each node treats the tip of its selected chain as the head. Independent validation and accumulated work determine which head it accepts. Hash pointers still make changes detectable, while proof of work makes replacing the accepted history expensive. The protection depends on the network and mining assumptions, rather than on one authority safeguarding a master pointer.

As miners add blocks, one branch gains more work and nodes switch to it. This is a chain reorganization. Each node undoes the abandoned branch’s changes to its UTXO set and applies the winning branch. Transactions from abandoned blocks may return to the mempool, provided they remain valid. A payment that conflicts with a spend on the winning branch cannot be accepted again.

The 51% Attack

An attacker could deliberately build a competing branch to replace a past payment. Changing an old block requires redoing its proof of work and the work for every block after it. Meanwhile, honest miners keep adding blocks to the public chain.

Suppose Alice pays Bob and waits for him to deliver goods. At the same time, she secretly mines a branch that spends the same input back to herself instead. If her branch gains more accumulated work, nodes switch to it. Bob’s payment disappears from the accepted history, even though he already delivered the goods.

An attacker controlling more than half the network’s hash rate can build work faster than the honest miners on average. This is known as a 51% attack. The percentage refers to hashing power, not the number of nodes or how much bitcoin someone owns.

An attacker with less hash power can still get lucky. If honest miners control the majority, however, catching up becomes less likely as more blocks are added.

An attacker who controls most of the hash rate can double-spend its own funds, reorder recent transactions, or prevent payments from being included. It still cannot forge someone else’s signature or make full nodes accept more newly created coins than the rules allow. Acquiring enough hash power is expensive, but we cannot rule out an attack on cost alone.

Confirming Transactions

A payment becomes harder to reverse as more blocks are added after it. A transaction has one confirmation when it appears in a block in the active chain. Every block added afterward gives it another confirmation. Six confirmations means the block containing the transaction plus five later blocks.

The recipient decides how long to wait before treating the payment as settled. Bitcoin’s payment-processing guidance discusses how confirmation counts affect confidence. Common guidelines include:

These are guidelines, not Bitcoin rules or guarantees tied to dollar amounts. Six confirmations take roughly an hour on average from broadcast if the transaction enters the next block. Congestion and unpredictable block times can make the wait longer. No fixed number guarantees that a payment cannot be reversed, especially while an attacker controls most of the hash rate.

Rewards and Transaction Fees

Mining costs money for equipment and electricity. Bitcoin gives miners an incentive to do this work through a reward for each accepted block.

Every block starts with a special coinbase transaction. It lets the miner claim newly created bitcoin, called the block subsidy, plus the fees from the block’s transactions. Unlike an ordinary transaction, it doesn’t spend previous outputs. Other nodes reject the block if the miner claims too much.

The subsidy started at 50 BTC and halves every 210,000 blocks, roughly every four years. The reward schedule so far, together with the next expected halving, is:

In October 2026, the subsidy is 3.125 BTC per block. Halvings happen at specified block heights, so the next date is an estimate rather than a scheduled day. This schedule limits the total amount created to about 21 million BTC. The table shows the subsidy only. Transaction fees are added to it.

The subsidy and transaction fees together form the block reward. Since block space is limited, miners have an incentive to include transactions paying higher fees for the space they use. As the subsidy shrinks, fees become more important. Whether those fees will support enough mining to maintain security remains an economic question.

Miners cannot spend coinbase outputs immediately. Under the coinbase maturity rule, an output created in block \(h\) can first be spent in block \(h+100\). A reward from an abandoned branch cannot be spent on the winning chain. These rules encourage miners to produce blocks the network will accept, although incentives alone cannot guarantee honest behavior.

Benefits and Limitations (Optional)

Bitcoin makes it possible to maintain a shared transaction history without putting one organization in charge. However, some parts of the system are more decentralized than others. The main benefits and limitations are:

• Anyone can verify the ledger. Anyone with enough storage, bandwidth, and processing power can run a full node. Copies around the world let participants check transactions without depending on one server.

• Mining is concentrated in a few pools. The top two pools account for roughly half of observed block production. A one-week Mempool ranking retrieved on October 6, 2026, put Foundry USA at 26.78% and AntPool at 19.84%, totaling 46.62%. These estimates come from attributed blocks, and the shares change over time. Miners can switch pools, but a few operators still have considerable influence over which transactions enter blocks. Cooperation between large pools could make censorship or a majority attack possible.

• Software development concentrates influence. Bitcoin Core, the principal full-node software project, is open to contributions, but a smaller group reviews and releases changes. Developers cannot force independent node operators to adopt new rules. However, malicious code or a bug could harm users who run it, expose wallet keys, or weaken transaction checking.

• There is no undo service. A mistaken payment cannot be canceled through a central authority. The recipient can send a refund as a new transaction. A chain reorganization can remove a payment, but it provides no dependable way to recover a mistake.

• Using Bitcoin safely takes care. Many people rely on exchanges or other custodians to manage their keys. That brings back dependence on a service provider. Regulated exchanges may identify their customers, connecting those people to public transaction histories. As Bitcoin’s privacy guidance explains, having no names in the ledger does not make users anonymous.

• Security has a cost. Mining consumes electricity, block space is limited, and waiting for confirmations takes time. The system depends on secure cryptography, correct software, network connectivity, and enough mining power following the rules.