Generally, a mining node is a full node with the mining option enabled. However, they can also be lightweight nodes participating in a mining pool, with the pool server maintaining the full node.
The mining node constructs blocks and fills them with a properly ordered set of transactions from the pool of open transactions called the mempool (short for memory pool).
Next, it typically uses purpose-built silicon called ASICs (or other mining hardware) to find a number (the nonce), which, when combined with the block header, results in the block header's hash value below the current difficulty target given by the previous difficulty adjustment. This process is called mining or hashing. If it finds a valid combination, it broadcasts the block along with the number it found so that other nodes can verify the validity of the claim. Thus, mining nodes compete to create Bitcoin blocks. Once a block is successfully mined, it is added to the blockchain, and the process repeats for the next block.
The Three Layers of Bitcoin Mining
In production, Bitcoin mining splits into three coordinated layers: the mining node, the mining pool, and the ASIC. Each layer has a job that the other two cannot do.
The Mining Node
A mining node is a Bitcoin full node configured to support block production. It tracks the current chain tip, maintains a copy of the mempool, validates every incoming transaction and block against consensus rules, and produces block templates on request. When an ASIC finds a valid Proof of Work (PoW) for a template, the node verifies the solved block and announces it to peers.
The reference implementation is Bitcoin Core. Its mining-related Remote Procedure Calls (RPCs), getblocktemplate and submitblock, live in src/rpc/mining.cpp.
The Mining Pool
A mining pool is a coordination service that distributes block-template work to many ASIC operators and pays out the block reward proportionally to the hashing contribution each operator submits. The pool runs (or contracts) a mining node, fetches templates from it, and breaks the work into smaller difficulty shares that individual operators can submit as proof of effort.
Hashing the entire network's difficulty alone produces high payout variance. Pooling hash rate gives operators smaller, steadier payments.
The ASIC
An ASIC, or application-specific integrated circuit, is purpose-built silicon that computes SHA-256 hashes (see the SHA-256 glossary entry) at a fixed energy cost per hash. The ASIC takes a candidate block header from the mining node (via the pool, in pooled setups), iterates the nonce field, and checks whether each resulting hash falls below the current difficulty target. When one does, the ASIC reports the winning nonce back up the stack.
ASICs do not validate transactions, hold UTXOs (Unspent Transaction Outputs), or participate in the peer-to-peer network. Hashing is the entire scope of the hardware's job.
Template Construction in the Mining Node
A block template is a draft block that contains everything except a valid nonce. Building one is the mining node's central job.
The node starts by reading the mempool. It selects a subset that maximizes fee revenue subject to the block weight limit and any dependency constraints between transactions (a child transaction cannot appear before its parent). For each candidate, the node tracks fee rate (satoshis per virtual byte), signature operation count, and ancestor and descendant relationships.
Once the transaction set is chosen, the node assembles the coinbase transaction. The coinbase pays the block subsidy plus the sum of fees from included transactions to an address controlled by the miner or the pool. As of 2026 the block subsidy is 3.125 BTC, halving roughly every 210,000 blocks per the Bitcoin supply schedule. The next halving occurs at block 1,050,000, expected around 2028.
The node then computes the merkle root over all transactions and fills in the block header: version, previous block hash, merkle root, timestamp, difficulty bits, and a nonce placeholder. The output is a complete candidate block ready for PoW.
getblocktemplate: How Pool Software Talks to the Node
Pool software and standalone miners request templates from a node through the getblocktemplate JSON-RPC, defined in Bitcoin Improvement Proposal (BIP) 22 and extended by BIP 23. The call returns the entire candidate block structure: the chosen transactions in hex form with their fees and dependencies, the coinbase value, the difficulty bits, the previous block hash, the height, and the timestamp.
BIP 23 adds pool-relevant extensions: block proposal (the miner submits a proposed block for the node to validate before committing hash power to it), allowed mutations (which header and coinbase fields the miner may modify), and target ranges for share submission.
A long-polling parameter lets the miner subscribe to template refreshes; when a new block arrives on the network and invalidates the current template, the node pushes an updated one. This avoids wasted hash power on stale work.
Block Submission and Validation
When the ASIC finds a nonce that drives the block header hash below the difficulty target, the work travels back up the stack: ASIC to pool, pool to mining node, mining node to the network.
The pool calls the submitblock RPC on the node with the complete solved block in hex. The node re-runs every consensus check: PoW validity, transaction signatures, UTXO availability, total fees, block weight, coinbase subsidy amount, and merkle-root integrity. If any check fails, submitblock returns a rejection reason and the work is discarded. If every check passes, the node accepts the block, updates its chain tip, and announces it.
A misconfigured pool or a buggy template can produce a block that wastes the operator's PoW, and the node's check catches it before broadcast.
Block Relay Performance
The seconds after a block is found matter economically. Until the block propagates to other miners, those miners continue hashing the previous tip, and any block they find on that tip will lose the race once the newer block arrives.
BIP 152, Compact Block Relay (CBR), reduces propagation bandwidth and latency by transmitting short transaction identifiers instead of full transaction bodies for transactions the receiving peer already has in its mempool. BIP 152 defines a high-bandwidth mode (peers push compact blocks before validation, reaching about 0.5 round trips on the happy path) and a low-bandwidth mode (peers announce first and the receiver pulls, which costs more round trips but less bandwidth). Reduced variance in propagation time means fewer accidental short reorganizations and a fairer playing field for miners on slower connections.
Specialized relay networks such as FIBRE and Falcon historically served the same goal at the cost of additional infrastructure. With CBR widely deployed, most of that gap closed.
Why Miners Run Their Own Nodes
A miner cannot produce a valid block without a current view of the chain tip. The set of valid transactions, the difficulty target, the previous block hash, and the legitimate coinbase subsidy all depend on the current consensus state.
Running on someone else's node introduces two risks. First, an eclipse attack: an adversary that controls all of the miner's network connections can feed it a stale or fabricated chain view, causing the miner to hash on work that the rest of the network will reject. Second, a custody or censorship risk: the operator of the upstream node chooses which transactions appear in the template and can withhold templates entirely.
Operators who care about either risk run their own validating node. Larger operations often run multiple nodes across diverse network paths and cross-check templates against a redundant set.
Mining Node vs Mining Pool vs ASIC
| Layer | Hardware | Job | Output |
|---|---|---|---|
| Mining node | General-purpose server | Validate chain, build templates, submit solved blocks | Block templates and accepted blocks |
| Mining pool | Coordination software (often a mining node plus stratum server) | Distribute work, track shares, pay out rewards | Share assignments and payouts |
| ASIC | Specialized SHA-256 hardware | Iterate the nonce until the hash falls below target | Winning nonces |
One mining node can serve templates to several pools, and one pool can coordinate work across many ASIC operators. Over time, an ASIC operator may also rotate between several pools.
Solo Mining vs Pooled Mining
In a solo configuration, the operator runs one mining node and one or more ASICs pointed at it directly. The node produces templates, the ASICs hash, and any block the setup finds pays the full reward to the operator's coinbase address. Payout variance is high; an operator with one percent of network hash rate solves a block on average once every hundred blocks, but the actual gaps can be much longer or shorter.
In a pooled configuration, the pool's mining node produces templates that the pool's stratum server breaks into share-sized work units. Many independent ASIC operators connect to the pool and receive a stream of assignments. Each share that meets a lower difficulty target than the network proves the operator did work. The pool pays each operator a fraction of the block reward proportional to submitted shares, smoothing payouts. The trade-off is that the pool decides which transactions enter the block.
Stratum V2 and Decentralization
Stratum V1, the dominant pool protocol for over a decade, hands the entire block-template decision to the pool. Operators contribute hash rate but have no voice in which transactions get confirmed.
Stratum V2, maintained by the open-source Stratum Reference Implementation project with contributions from Blockstream Research and other organizations, restructures the protocol around three sub-protocols. The most consequential is Job Declaration, which lets the ASIC operator run a local Template Provider that talks to the operator's own Bitcoin node and constructs candidate blocks locally. The pool still verifies the work and pays out shares, but the operator chooses the transactions.
Other Stratum V2 changes include authenticated encryption on the wire (V1 is plaintext), binary framing (V1 is verbose JSON over TCP), and explicit channels for header-only work versus full templates.
The decentralization implication is direct: if a pool attempts to censor a transaction or to exclude certain addresses, operators using Job Declaration can route the work elsewhere or include the transaction anyway, since they own the template. Several pools were running production V2 deployments alongside legacy V1 as of early 2026.
What a Mining Node Does Not Do
Hashing happens on the ASIC, not on the mining node. A mining node running on a general-purpose CPU could not earn a block in any reasonable horizon.
Fees flow only through a solved block, which requires PoW that the node cannot produce, so the node earns nothing on its own.
A well-resourced node can serve templates to multiple pool back-ends and to many ASIC fleets at once, much as a single Bitcoin full node can serve light wallets and explorers across many users.
A mining node only needs to be correct: a validating implementation, an up-to-date chain view, and a reliable network path to peers. Size and speed beyond that are optional.
Frequently Asked Questions
Is a mining node the same as a Bitcoin full node?
A mining node is a full node with the additional job of producing block templates and accepting solved blocks. Every mining node is a full node; not every full node is a mining node.
Can a miner mine without running a node?
A miner can point ASICs at a pool that runs the node on the miner's behalf. The miner then trusts the pool's view of the chain and the pool's template contents. Running an independent node removes that trust.
What does getblocktemplate return?
The RPC returns a complete candidate block: the chosen transactions in hex, the coinbase value, the difficulty bits, the previous block hash, the block height, the timestamp, and the allowed mutations. The miner customizes the coinbase and iterates the nonce.
What is the difference between submitblock and the P2P block message?
submitblock is a local RPC the mining software calls on its own node when it finds a solved block. The node then announces that block to its peers using the P2P block and (under BIP 152) cmpctblock messages.
How fast does a block need to propagate?
There is no hard deadline, but every additional second of propagation gives competitors more time to find a block on the previous tip. CBR keeps propagation well under one second between well-connected peers in typical conditions.
Does Stratum V2 require a new node?
The protocol works with a standard Bitcoin Core node providing the Template Provider interface. The change is in the pool protocol layer above, not in the node itself.