Understanding Transaction Fee Selection in Mining

A block can be valid, pay the right address, and still leave money behind. That is the practical reason for understanding transaction fee selection. A miner who finds a block earns the subsidy plus the fees from the transactions included in that block, subject to Bitcoin’s consensus rules. The word that matters is included.

For a home miner, this is not a promise of better luck or steadier income. Solo mining remains a high-variance lottery. It is about knowing what the pool or template provider is doing with the work your hardware is attempting, and knowing what evidence exists if your hash solves a block.

What transaction fee selection actually means

Every unconfirmed Bitcoin transaction carries an implied fee. Its inputs have a total value. Its outputs have a total value. The difference is the fee available to the miner who confirms it. A block producer does not receive those fees through a separate payment transaction. They claim them in the coinbase transaction, alongside the block subsidy.

A candidate block has limited weight. It cannot include every transaction waiting in the mempool. Someone must decide which transactions fit and in what order. That decision is transaction fee selection.

The usual objective is not simply to choose the transactions with the largest fee in sats. Block space is measured in weight, so the useful comparison is fee rate, commonly expressed in sats per virtual byte. A transaction paying 20,000 sats may be less attractive than one paying 2,000 sats if it consumes much more block weight.

That simple rule has exceptions. Some transactions are related. A low-fee parent may need its higher-fee child included with it. This is commonly handled as a package. A template builder also has to account for standardness policy, signature checks, transaction dependencies, and the time required to validate and assemble a candidate block. The highest apparent fee rate is not always the transaction that can safely or efficiently enter the template.

The distinction miners need to make

Transaction fee selection is often confused with three separate questions: who builds the block template, who controls the coinbase payout, and whether the pool charges a service fee. They are connected, but they are not the same thing.

A pool can charge zero commission and still choose every transaction in the candidate block. A miner can have a direct coinbase payout address and still depend on another party’s template construction. A pool can also claim to select transactions efficiently without giving miners a way to inspect the completed block after it is found.

None of these arrangements is automatically dishonest. The problem begins when the arrangement is described vaguely enough that a miner cannot tell which authority holds which power.

For conventional Stratum V1 mining, the pool generally sends a job derived from a template it has already constructed. Your ASIC searches the nonce space for a valid hash. It does not independently browse the mempool and redesign the block. If it finds a valid block, the transaction set was normally chosen upstream.

Stratum V2 creates room for more explicit roles, including template distribution and job negotiation. But protocol capability is not proof of a particular deployment. A miner should ask which party supplies the template, which keys are pinned, what job fields are committed, and what can be checked after a block is found. “Supports V2” is not an answer to those questions by itself.

Why fee selection affects a solo miner’s payout

Suppose a candidate block includes 3.125 BTC in subsidy and 0.25 BTC in transaction fees. If the block is accepted, its coinbase transaction may claim up to 3.375 BTC, less no pool commission if the arrangement is genuinely zero-fee. If the template instead includes only 0.05 BTC of fees, the remaining 0.20 BTC is not redirected to the miner later. It was never claimed in that block.

The numbers can be much smaller or much larger depending on network conditions. During ordinary periods, fees may be a modest part of the reward. During sustained congestion, they can become material. The point is not to predict a fee level. It is to understand that selection quality can affect the value of the rare event you are trying to win.

There is also a hard limit to what can be promised. No pool can guarantee the maximum possible fee total for every block. Mempools differ between nodes. Transactions arrive at different times. Package policy changes. A competing block can make transactions disappear from the mempool just before your block is assembled. A valid candidate can become stale before it reaches the network.

A credible operator does not replace those realities with a revenue slogan. It identifies the node that builds the template, the policy it follows, and the records available when a block is solved.

What verification looks like after a block is found

The clearest evidence is the accepted block itself. Its transaction list is public. Its coinbase transaction is public. Its total coinbase claim can be compared against the subsidy at that height plus the fees implied by the included transactions.

Start with the payout output. Does the coinbase pay the Bitcoin address you configured? Then inspect the transaction set and calculate the fees from each transaction’s inputs and outputs. Finally, compare the resulting total against the coinbase amount. The coinbase cannot validly claim more than the subsidy plus included fees. If it claims less, the difference is not a hidden accounting line item. It is value the block did not claim.

This check answers a precise question: what did this accepted block pay? It does not prove that every theoretically available transaction should have been included. That broader judgment requires the template timestamp, the pool node’s mempool view, package relationships, and its policy at the moment the template was built. Those facts are harder to reconstruct later, which is why operational records matter.

A signed ledger or job record can establish that a worker submitted work and how the service accounted for it. It cannot make a missing transaction appear in an already-mined block. Keep the layers separate. Work accounting proves whether your shares were received. A block proves what was mined. An on-chain payout proves where the reward went.

Questions to ask before pointing a rig at a pool

The useful questions are concrete. Who runs the full node used for template construction? Is the candidate block built from that operator’s node or delegated to another service? What is the configured coinbase payout destination? Does the miner receive the full subsidy and included fees directly on-chain if a block is solved?

Then ask about the evidence. Can you inspect the exact payout address before mining? Can you verify the submitted-work trail without trusting a dashboard balance? Is there a public record of operational changes that could affect job construction or payout behavior? If encrypted Stratum V2 is offered, can you authenticate the authority key rather than merely encrypt traffic to an unknown endpoint?

NexusPool’s model is direct on-chain payment of the block subsidy and included transaction fees to the miner’s configured Bitcoin address. That establishes payout destination. It does not repeal the need to examine the block, the job record, and the operator’s published behavior. Direct payment is better treated as a fact to verify than a phrase to repeat.

A better standard than “best fees”

“Best fee selection” sounds reassuring, but it is not a standard a miner can audit. Better questions are narrower. Was the template built by a known node? Were transactions selected under a stated policy? Did the accepted block claim the fees from its included transactions? Did the coinbase pay the address the miner specified?

Those questions leave room for honest uncertainty. You may not be able to prove, after the fact, that a different mempool snapshot would not have produced a slightly higher-fee block. You can prove whether your actual winning block paid your actual address and claimed the fees from the transactions it actually confirmed.

That is enough to reject blind trust. Your hashrate buys a chance to produce a block. Do not let vague language obscure who constructed it, who controlled its reward, or what the chain records once it exists.

Trust nothing. Verify the candidate block.