Who Chooses Bitcoin Transactions: Miner, Pool or Template Provider?

Who chooses Bitcoin transactions in a mined block? Trace control across nodes, pool templates, Stratum V1, Stratum V2 and individual ASIC miners.

The block producer chooses

The entity that constructs the final candidate block chooses its transaction set within consensus rules. In solo mining that is usually the miner’s own full node and template software. In conventional pooled mining it is usually the pool. The physical ASIC searches headers derived from the job and normally never receives the complete transaction list.

Start with the validating node, because the ASIC only hashes the candidate header it receives. Record the node release and the pool component that assembled the block. If those facts are unknown, the operator cannot show which rules were actually applied before electricity was committed to the work.

Bitcoin Core and getblocktemplate

A validating node maintains a mempool and can use fee, dependency, weight and operator policy to build a candidate. getblocktemplate returns the transactions and metadata needed by specialised mining software. The caller can apply permitted changes and submit a solution. Node policy shapes the candidate. But another miner can legally mine a different consensus-valid selection.

Treat status dashboards as observations, not as the source of truth. Compare them with an independently operated node and retain the raw deployment or template response. Period boundaries, chain reorganisations and cached pool pages can otherwise make a correct-looking percentage describe the wrong state.

The conventional Stratum V1 path

A V1 pool constructs the block and sends compact job components to workers. Merkle branches let the worker derive the header after building its coinbase. But they do not reveal the full transaction set. The worker can accept the job or change pools. It cannot substitute its preferred transactions into that job and still expect the original share accounting to work.

Build the failure response before the boundary arrives. Define which rejection messages trigger an alert, who can pause a template source and how failover is prevented from returning miners to the same faulty validation stack. A second hostname is not independent when both endpoints share one node.

What a mining proxy can change

A proxy can distribute extranonce space, targets and jobs to many ASICs. Unless it also runs a template provider and a protocol that supports custom work, it does not gain transaction-selection authority. Marketing language about local control should be checked against the actual messages: which component supplies transaction data and who can reject a proposed job.

Separate readiness, signalling and enforcement in the operating log. Readiness is a claim about software and process, signalling is data carried by blocks, and enforcement is a validation result. Combining them into a single supported or unsupported label hides the point at which revenue is actually at risk.

The Stratum V2 alternative

Template Distribution can bring fresh templates from a miner-side node. At the same time, Job Declaration lets the client propose them to the pool. The pool verifies validity and coinbase constraints, then accepts shares for the declared job. This makes transaction choice more distributed while preserving pooled payouts. It remains optional and depends on implementation support.

Map responsibility across the full path: validating node, template server, pool protocol, proxy, firmware and ASIC. For each layer, state what it can alter and what it merely relays. This prevents a version-bit setting in firmware from being mistaken for complete consensus-rule support. Relate that responsibility map to the pool and job-control boundary in our Stratum V2 guide.

Fees and policy incentives

Block builders usually favour high-feerate packages because fees increase revenue. But they may exclude transactions for policy, technical or legal reasons. A miner-selected template can expose differences between the local mempool and the pool’s choices. It cannot include an invalid transaction, and poor connectivity can miss profitable transactions even without deliberate filtering.

Test the primary and failover paths with the same checks. Compare chain tip, chainwork, deployment state, required rules and template age, then save the result with a timestamp. The process should be repeatable by another operator without relying on an undocumented pool conversation.

How to prove who controls selection

Capture the job and template flow. Identify the node that produced the transaction list, compare its block-template transaction IDs with the pool’s job, and test whether a custom declaration is accepted. Document who controls coinbase outputs and propagation. An ASIC setting labelled pool does not answer the question. control resides in the upstream software path.

Turn the conclusion into a business decision. State which chain and settlement venues the operation intends to serve, the maximum acceptable stale-block exposure and the point at which mining pauses. This connects protocol evidence to electricity cost, pool revenue and payout finality.

Operator decision record

A concise decision record for who chooses Bitcoin transactions should name the source documents, their dates, the node release tested, the responsible pool or template provider and the exact trigger for action. Include screenshots or machine-readable output for the deployment state. But keep the raw node response as the stronger evidence.

State whether a change affects policy, block construction or consensus validity, because those layers have different failure costs.

Run the check on every production and failover path. Confirm that monitoring alerts on stale templates, unexpected chain tips, rejected proposals and a rise in stale shares. Keep rollback instructions for node and pool configuration. But do not roll back across an active consensus boundary without understanding the rules the older release enforces.

If the evidence conflicts, pause the affected path and investigate before committing more electricity to uncertain work.

For related background, read our plain-English BIP-110 guide and technical BIP-110 review. Those articles use a modern proposal to show why signalling, activation, template construction and accepted chain history must be examined separately.

Conclusion

Who chooses bitcoin transactions is best understood as a defined interaction between validating software, mining infrastructure and economic acceptance. The safest operator does not infer consensus from a dashboard percentage or a pool slogan. They verify the rule source, the activation boundary, the template fields and the chain their payouts ultimately settle on.

That discipline reduces the chance of hashing an invalid or commercially unwanted block.