Introduction

A Bitcoin mining pool generally prioritizes valid transactions by fee rate, while accounting for unconfirmed transaction dependencies and the block's weight and signature-operation limits. It builds a candidate block from transactions available to its template-building infrastructure, aiming to maximize fee revenue within those constraints. This is why a transaction paying a large absolute fee can be excluded while a smaller transaction with a higher fee rate is included instead.

This article explains who performs transaction selection in pooled mining, the economic logic pools apply, the structural constraints that limit their choices, and the circumstances under which a transaction with a competitive fee may still miss the next block.

Who Selects the Transactions in a Mining Pool?

In pooled mining, individual miners do not normally choose which transactions enter a candidate block. That task belongs to the pool's template-building infrastructure, typically a full node or a dedicated service that exposes a block template through an interface such as Bitcoin Core's getblocktemplate remote procedure call. This interface returns a set of candidate transactions along with their fees, sizes, and dependency information, which the pool's software uses to assemble a proposed block (Bitcoin Core, getblocktemplate RPC documentation). Once a template is built, the pool distributes work derived from it to connected miners, who hash the assigned job rather than independently selecting transactions.

Stratum V2's Job Declaration protocol provides an alternative: a miner or mining farm can use its own template provider to select transactions and declare a custom block template to a pool. This requires compatible pool and miner infrastructure (Stratum V2, Protocol Overview).

A related point often overlooked is that there is no single, canonical Bitcoin mempool shared identically by every participant. Each pool's node maintains its own view of pending transactions, shaped by network propagation, timing, and that node's own relay policy. A transaction can only be considered for a pool's template if it has already reached and been accepted by that pool's node. Two pools building templates at the same moment may therefore have slightly different candidate sets.

The Basic Economic Criterion: Fee Rate, Not Absolute Fee

A transaction's fee is the difference between the value of its inputs and the value of its outputs, expressed in satoshis. Because block space is limited, pools do not generally rank transactions by this absolute fee alone. The more relevant measure is the fee earned per unit of space the transaction occupies, commonly expressed in satoshis per virtual byte (sat/vB).

Virtual size is transaction weight divided by four, rounded up to the next integer (BIP141).

Fee rate = Transaction fee (satoshis) ÷ Virtual size (vB)

Consider two transactions competing for the same limited space:

• Transaction A: 10,000 sats fee, 200 vB → 50 sat/vB
• Transaction B: 20,000 sats fee, 1,000 vB → 20 sat/vB

Transaction A pays a lower absolute fee but a higher fee rate. All else equal, it is the more attractive candidate for a pool working under a fixed block-space budget, since it represents less competition for finite room relative to the revenue it contributes.

Why Pools Evaluate Transaction Packages, Not Isolated Transactions

The fee-rate comparison above assumes each transaction can be evaluated on its own, which is not always true. A transaction that spends an output created by another unconfirmed transaction cannot be included in a block unless its parent is included first or already confirmed. When an unconfirmed parent carries a low fee rate but its unconfirmed child carries a high one, a pool may evaluate the two together as a package rather than individually. This is the mechanism behind child-pays-for-parent (CPFP) fee bumping.

A package fee rate is calculated as:

Package fee rate = (Parent fee + Child fee) ÷ (Parent virtual size + Child virtual size)

Suppose a parent transaction pays 1,000 sats for 500 vB (2 sat/vB on its own) and its child pays 24,000 sats for 100 vB (240 sat/vB on its own). Evaluated as a package:

(1,000 + 24,000) ÷ (500 + 100) = 25,000 ÷ 600 ≈ 41.67 sat/vB

Evaluated in isolation, the parent looks unattractive. Evaluated as a package with its child, the combined rate is substantial, and a pool may rationally include both. This is also the practical reason a low-fee-rate transaction can sometimes appear in a block ahead of a higher-fee-rate transaction elsewhere in the mempool: it was pulled in as part of a more valuable package, not selected on its own merits.

Bitcoin Core already accounted for unconfirmed transaction dependencies before version 31.0. The 31.0 release introduced cluster mempool, a redesign that organizes connected transactions into clusters and orders subsets expected to be mined together, called chunks, by their combined fee rate for relay, eviction, and block-template construction (Bitcoin Core 31.0 release notes). The same release sets default local policy limits of 64 transactions and 101 kB of virtual size for a single connected cluster. These are node-level policy defaults that individual operators may adjust; they are not Bitcoin consensus rules, and they do not define a universal cap on how large a parent-child package can be across the network.

The Block-Level Constraints That Shape Template Construction

Beyond individual and package fee rates, a candidate block is bound by fixed consensus limits. Under the rules introduced by Segregated Witness, a Bitcoin block may not exceed 4,000,000 weight units, and it is additionally limited to 80,000 sigop cost units (BIP141). Weight units are not equivalent to a block's serialized byte size, and the sigops limit can bind a template before its weight limit does if a selected set of transactions contains an unusually high density of signature operations.

These limits mean that block assembly is a constrained selection problem rather than a simple ordered list. Near the end of a nearly full block, the most profitable remaining package may be too large to fit in the unused capacity. In that situation, a smaller transaction with a lower fee rate, but one that fits the remaining space, may be selected instead, since it still adds fee revenue that would otherwise be left uncollected.

Why a Competitively Priced Transaction May Still Be Excluded

Several conditions can prevent a transaction from entering the next block even when its fee rate appears reasonable relative to prevailing network conditions:

• It has not reached the pool's mempool. Propagation delay or local relay policy can mean the pool's node simply has not received or accepted the transaction yet.
• Its package fee rate is not competitive. An isolated fee rate can look attractive while the transaction's unconfirmed ancestors make the combined package less so.
• It conflicts with another unconfirmed transaction. If two transactions spend the same input, a pool can only include one; replacement policy determines which version, if either, remains in the mempool.
• Block-weight or sigops space ran out first. A transaction may be valid and fairly priced but simply not fit in the remaining capacity of the template being built.
• A competing block was found first. Block discovery is probabilistic. A transaction can have an excellent fee rate and still be confirmed in a later block if another pool or miner finds a valid block before the transaction is incorporated into a distributed template.

Can a Pool Prioritize a Specific Transaction?

Pools retain discretion over the exact contents of a valid block template, since Bitcoin's consensus rules constrain which transactions can be included but do not mandate a specific selection order. This discretion is the basis for transaction-acceleration services offered by some pools. ViaBTC, for example, offers a BTC Transaction Accelerator: eligible free submissions are prioritized by ViaBTC for inclusion in the next block it mines, while its paid service notifies cooperating pools after the acceleration payment is received. Confirmation timing remains uncertain because block discovery and prevailing network conditions cannot be controlled (ViaBTC Help Center, BTC Transaction Accelerator).

This type of service illustrates the boundary of pool discretion clearly: a pool can choose to favor an eligible transaction within its own template, but it cannot make an invalid transaction valid, cannot override another pool's template, and cannot guarantee when it will next find a block. Readers evaluating any acceleration service should treat it as a request for priority treatment rather than a guaranteed confirmation mechanism.

Practical Implications for Bitcoin Users

For someone broadcasting a Bitcoin transaction, the preceding mechanics translate into a few practical considerations. Fee rate, not absolute fee, is the figure to evaluate against current network conditions, since it reflects the amount paid per unit of the constrained space pools are optimizing for. If a transaction depends on an unconfirmed parent, evaluate the combined fees and virtual sizes of the transaction and the unconfirmed ancestors that must be included with it. Users whose transaction is stuck with a low fee rate may be able to use replace-by-fee or CPFP, where wallet software and transaction structure support them, to make the pending transaction or its package more attractive to include. None of these techniques guarantees a specific confirmation block or time, since block discovery remains probabilistic and template contents vary across pools.

Conclusion

A Bitcoin mining pool selects transactions by building a block template from the pending transactions its own node has received, then favoring the valid transactions or transaction packages that offer the greatest fee revenue per unit of constrained block space. Parent-child dependencies, the block-weight and sigops limits set by BIP141, and the timing of template updates all shape the final selection alongside fee rate. These factors explain the common cases in which a transaction with a seemingly competitive fee is delayed, and why ordering by raw fee rate alone is an incomplete description of how pools actually construct blocks.

FAQ

Does a higher fee always mean faster confirmation?

Not necessarily. Fee rate (fee divided by virtual size), not the absolute fee amount, is the figure pools typically weigh most heavily, and an unconfirmed parent transaction with a low fee rate can also affect how a pool evaluates a related child transaction.

Why can a low-fee transaction appear in a block before a higher-fee one?

This usually happens because the low-fee transaction is the required parent of a higher-fee child, and the pool evaluated the two together as a package, or because the higher-fee transaction had not yet reached the pool's mempool or did not fit the block's remaining weight or sigops capacity.

Do all pools see the same set of pending transactions?

No. Each pool's node maintains its own mempool based on transaction propagation and that node's relay policy, so candidate transaction sets can differ slightly between pools at any given moment.

Can a mining pool include an invalid transaction if the fee is high enough?

No. Every transaction in a candidate block must satisfy Bitcoin's consensus rules regardless of its fee; a higher fee cannot make an otherwise invalid transaction valid, and other full nodes will reject a block containing an invalid transaction.

What does a transaction accelerator actually do?

It requests priority treatment for an eligible pending transaction. With ViaBTC, free submissions are prioritized by ViaBTC, while paid acceleration notifies cooperating pools after payment is received. Neither option guarantees a specific confirmation time, since that still depends on block discovery and prevailing network conditions.

References

• Bitcoin Core, getblocktemplate RPC documentation
• Bitcoin Improvement Proposals, BIP141: Segregated Witness
• Bitcoin Core, 31.0 release notes
• ViaBTC Help Center, BTC Transaction Accelerator
• Stratum V2, Protocol Overview