Bitcoin in Practice: Nodes and Mining

By Kurt Wuckert Jr.

Nodes and Mining

When people say “bitcoin nodes,” they often picture a bunch of identical computers sitting around the world. In practice, a mining node is a working system with distinct parts that cooperate to validate transactions, assemble blocks, and compete to mine them.

A node, as described here, has three major components:

  1. Mining (pool software plus ASIC miners)This is the proof of work engine. It runs independently and takes a candidate block header as input. Pool software “shards” the job by splitting hashing work across lots of machines, and the ASICs do the actual brute-force hashing.

  2. Node softwareThis is the brain and bookkeeping. It validates transactions, prepares and verifies blocks, and builds the candidate block template that the mining side tries to solve.

  3. NetworkThis is the communications layer that lets nodes and pools exchange messages, propagate transactions, announce blocks, and request data from each other.

Mining

One counterintuitive point matters up front: from a proof of work perspective, the cost of mining a block is not tied to whether it contains one transaction or a hundred billion transactions. Proof of work is aimed at solving a target puzzle, not “paying per transaction.” The transactions matter for fees and usefulness, but the hashing race is the hashing race.

Here is the high-level flow described:

1) Collect and validate transactions

  • Transactions are collected from users, and any missing ones are gathered from other nodes.

  • The node validates each transaction.

    • If valid, the UTXOs referenced by inputs are updated appropriately, and transaction IDs (TXIDs) are stored.

    • If invalid, the transaction is rejected.

2) Build a candidate block

  • The validated transactions are represented in the candidate by their TXIDs.

  • Those TXIDs are arranged into a Merkle tree, producing a Merkle root for the candidate block.

3) Hand the candidate header to the miners

A “block candidate” here is the header components plus a candidate Merkle root. Miners repeatedly hash that candidate header, looking for a hash output below a target. Finding that winning hash is the proof of work solution.

Once a solution is found, the candidate is finalized into a full block header. The block header contains these fields:

  • Version: a 4-byte little-endian value indicating the protocol version the block is published under.

  • hashPrevBlock: a 32-byte little-endian double SHA-256 hash of the previous block header, linking blocks together.

  • hashMerkleRoot: a 32-byte value representing the Merkle root of the ordered transactions in the block.

  • Time: a 4-byte Unix timestamp applied to the block’s transactions; policy only requires it to be within 2 hours of validating nodes’ local time, with 1-second precision.

  • Bits: a 4-byte compact representation of the difficulty target required by network rules.

  • Nonce: a 4-byte “number used once” that miners cycle through while hashing.

There is a practical detail here: ASICs can burn through the full 4.3 billion nonce space quickly. To give miners more room to search, nodes also vary a value in the coinbase transaction called the extra nonce, then recompute the Merkle root. That effectively provides additional nonce “spaces” for the ASICs to iterate through.

The node software determines Version, hashPrevBlock, hashMerkleRoot, Time, Bits, plus a starting nonce. The mining component then performs a brute-force style process, repeatedly computing the double SHA-256 hash of the candidate header until it finds a hash below the target.

4) Propagate the found block and trigger validation

When a proof of work solution is found, it is returned to the node software. The node then uses the network (described here as the Bitcoin server network, BSN) to broadcast messages to other nodes announcing the proposed block.

Other nodes then:

  • Request the block details from the winning node,

  • Validate the block header and all underlying transaction data,

  • Reply with whether they accept it.

This acceptance process is described as Nakamoto consensus, and it is how the network converges on a shared ledger history.

5) How acceptance becomes “consensus”

Nodes show acceptance by building on top of the block they accepted. They do that by assembling the next candidate block using the accepted block ID as the previous block ID in their new block header.

Nodes compete, only the first to find a solution gets to publish the block, and everyone else’s hashing effort on that round is wasted. Once a block is published, the race starts again on a new candidate.

6) Temporary forks and resolution

Sometimes two nodes find valid solutions at nearly the same time, producing a temporary fork with two competing chain tips.

The fork resolves when a subsequent block is found that builds on one of those tips. The chain that receives the next block becomes longer, and the other branch is abandoned as nodes switch to building on the longer chain.

Standard and Local Policies

Validation is not just “accept everything.” Nodes apply rule sets at different layers.

Standard policies versus local policies

When a new transaction arrives, it goes through checks:

  • Standard policies (consensus rules) are the rules nodes are mandated to enforce for the network to operate. These are checked consistently and define what is valid under the protocol.

  • Local policies are additional acceptance criteria based on a node’s own infrastructure choices and business preferences. These are generally checked before a transaction is accepted into the mempool or included in a candidate block.

A simple way to think about it is: consensus rules decide what the network will recognize as valid; local policies decide what a particular miner is willing and able to handle based on their setup.

Consensus Rules

Consensus rules are described as fixed, codified into node software, and required for active participation in network governance.

Genesis block rule

The chain is anchored to the first block, the Genesis block, created on January 9th, 2009.

In this description:

  • The Genesis block is special because it was created with hardcoded values rather than being mined.

  • It included a first reward of 50 coins designed to be unspendable.

  • The coins are unspendable because the output was sent to a public key that was generated without an associated private key, which elliptic curve cryptography allows.

The purpose of anchoring to Genesis is to prevent a malicious party from creating an alternative chain that redirects hash power or economic activity. It also supports simplified payment verification by letting users confirm they are on the correct chain with minimal overhead, by verifying the known Genesis block hash:

000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

If a chain does not trace back to that origin, it is the wrong network.

Block size rule

Block size is defined as the serialized size of the block in bytes, including the header and all transactions.

In this description, the protocol does not define a maximum block size. Block size depends on what the node’s hosting capability can handle. The average block size is expected to grow without a fixed upper bound as the network grows.

Longest chain rule

Nodes are expected to track the longest honest chain and build on top of it. In this model, intentionally mining on an alternative chain instead of the longest honest one is considered malicious and a violation of protocol expectations.

Block subsidy rule

Nodes receive block subsidies for creating new blocks, and this serves as the distribution mechanism for new coins. The reward is treated as financial income, subject to local tax and income regulation. Mining is treated as a business activity under local jurisdiction.

Difficulty adjustment

Difficulty adjustment exists to keep block production stable, targeting about one block every 10 minutes.

Difficulty is applied through the Bits value in the block header, which impacts the target calculation for proof of work. This is implemented in node software and is not described as something an individual node can tune manually.

A historical observation is included: in the first 284 days after launch, there “should” have been 144 blocks per day for about 41,000 blocks, which would correspond to 2 million bitcoin; instead, only 1.25 million were mined by that point.

Network Consensus (Nakamoto consensus)

This consensus method is framed as deliberately avoiding reputation-based or identity-based voting. Rather than achieving consensus by ballots, nodes show acceptance through action.

Nodes “vote” by:

  • Creating blocks,

  • Building new blocks on top of previously broadcast blocks of accepted transactions.

The number of block-producing nodes is publicly observable. A maximum of 2016 nodes is described for a two-week difficulty adjustment window (6 blocks per hour for 14 days), under the idea that each block could be produced by a different node. In practice, most blocks are created by a small set of nodes, often 5 to 10.

Nodes that cannot create blocks are described as listener clients, not part of the node consensus and voting mechanism.

The 100 block rule incentive window

A coinbase output cannot be spent until it has 100 confirmations, meaning the chain must be 100 blocks higher than the block where that coinbase appears. This creates an economic incentive for a winning miner to care about the next 100 blocks, because their reward is only safely spendable after that maturity period.

The text uses this to argue that the effective window of simultaneously incentivized miners is 100 blocks, because at any time the miners with fresh coinbase rewards have a direct incentive to maintain chain stability for that maturity period.

Permissionless churn

Because proof of work requires continuous investment and continual winning of blocks, the participants that successfully mine blocks change over time. Over each difficulty period, the set of miners who actually produced blocks in that window are the miners “in” that cycle.

The brute-force nature of proof of work is presented as a way to prevent unfair advantages, and as a mechanism for trustless, permissionless participation. Other selection methods introduce trust in intermediaries, which makes the system vulnerable to abuse.

First-seen rule

When nodes receive conflicting transactions that attempt to spend the same coins, the first-seen rule applies:

  • The transaction the node received first is treated as the valid spender of that coin.

The rule is extended in a specific way: if a block is discovered that includes the double-spend transaction, that block should be considered invalid, and the node should continue mining against it, unless a second block is discovered on top of it. That second block indicates the majority of the network has determined that the other transaction was first seen.

Transaction Consensus Rules

Nodes apply protocol-level checks when validating transactions. The described checks include:

  • Transaction size: a maximum size that nodes agree to support by consensus, currently described as 10 MB.

  • nLockTime and nSequence: fields used to create transactions that become valid in the future. Only final transactions are confirmed in blocks; before that, they can be stored in the mempool.

  • Value exchange: total input value must cover all outputs plus fees.

  • Coinbase maturity: coinbase outputs cannot be spent until the chain is at least 100 blocks higher than the block where the coinbase appears.

  • Transaction format: transactions must follow protocol formatting rules.

  • Scripting language rules: transactions use a scripting language for inputs and outputs, and there are protocol rules governing that script behavior.

Local Policies

Local policies are business and infrastructure driven acceptance criteria. They vary by node based on configuration, hardware, and the services a node chooses to provide beyond the mandatory enforcement of consensus rules.

Local policies typically relate to:

  • The block and transaction sizes a node can support,

  • Transaction fee requirements,

  • How a node validates blocks and transactions received over the network.

Node Operations

Node software implements the protocol. Software implementations improve over time, but the protocol rules are treated as staying the same.

A node’s two main operational components are:

  • The mining pool component,

  • The node software that performs the functional work.

The node software is referred to as bitcoind, or bitcoin node software, historically implemented as a monolith. The text also mentions ongoing work toward a microservice architecture aimed at much higher throughput, including terabyte-size blocks and more than a million transactions per second, supporting a wide range of transaction types and applications for global commerce.

Node Software Components

At a functional level, node software includes:

  • P2P system (Bitcoin server network, BSN): manages network connections and message exchange between nodes. “Peer to peer” here means nodes are peers in responsibility and function, even if they offer extra services to users.

  • Transaction validator: validates incoming transactions.

  • Block assembler: builds candidate blocks from validated transactions.

  • Block validator: validates blocks found by other nodes, including all underlying transactions.

  • Chain tracker: keeps track of the current chain tip, monitors new blocks, downloads announced blocks, updates internal state, and handles communication when blocks fail validation.

What happens inside a node, moment to moment

There are two primary flows happening constantly:

Flow 1: Your node is mining

  1. Receive transactions from users or other nodes.

  2. Validate them.

  3. Store validated transactions in the mempool, broadcast them to peers.

  4. Block assembler builds and updates a candidate block template.

  5. Mining pool software hashes the candidate header, repeatedly searching for a proof of work solution.

  6. If found, the node propagates the block to the network.

Flow 2: Another node found a block

  1. Chain tracker hears the network announcement.

  2. Your node downloads the block.

  3. Block validator validates the block and its transactions.

  4. The mempool removes transactions now confirmed by that block.

  5. Your node builds a new candidate block on top of the new chain tip and resumes mining.

Alongside these, several sub-flows run in parallel:

  • BSN continuously routes messages in and out.

  • Mining pool software keeps requesting updated block templates so it is working on the freshest candidate.

  • Block assembler keeps adding new transactions, updating the Merkle root as needed.

  • UTXO storage updates UTXO states as transactions are accepted and as blocks are validated; final “spent” status is reached when confirmed in a block.

  • Mempool receives validated transactions and periodically feeds updates into candidate block construction.

When validating a block from another node, the text notes your node will already know about roughly 97% of the transactions, and will request the remaining unseen ones.

ELI5(ish...)

Picture bitcoin like a public notebook that gets a new page added every 10 minutes or so.

  • Nodes are the businesses trying to write the next page.

  • Node software is the part that checks, “Are these payments real?” and then stacks the valid ones onto the next page.

  • Mining hardware is the part that plays a giant lottery by guessing numbers really fast. The winning guess earns the right to publish the next page.

When your node gets new payments, it checks them, puts them in a waiting room (the mempool), and keeps updating its draft page (the candidate block). The miners keep hashing that draft, trying to find the winning proof of work.

If your node wins, it announces the new page. Other nodes then ask for it, verify everything on it, and if it checks out, they show acceptance by building their next page on top of yours.

Sometimes two nodes publish a page at almost the same time, so the notebook briefly has two possible endings. The tie breaks when the next page gets added on one side. Everyone follows the side that becomes longer.

There are also two kinds of rules:

  • Consensus rules are the “must-follow” rules for what counts as valid. If you break these, the rest of the network rejects you.

  • Local policies are your own business rules, like how big a transaction you are willing to handle, or what fees you require, based on your hardware and preferences.

That is the basic rhythm, validate transactions, assemble a page, race to win the lottery, publish, verify, repeat.