Block Packing

Block packing is the process of selecting and ordering transactions to maximize fee revenue or other objectives when constructing a new block.

Key Takeaways

Block packing is how miners and validators choose which transactions from the mempool to include in a new block, optimizing for total fee revenue within the block's capacity limit.
The problem resembles a knapsack optimization: transactions have varying sizes and fees, and the goal is to maximize total fees without exceeding the block weight limit. In general this is NP-hard, but greedy algorithms based on feerate sorting produce near-optimal results in practice.
Bitcoin and Ethereum approach block packing differently: Bitcoin Core uses feerate-based sorting with dependency awareness, while Ethereum relies on specialized block builders competing in auctions to extract MEV alongside transaction fees.

What Is Block Packing?

Block packing is the process of selecting and ordering transactions from a node's mempool to construct a new block. Every block has a finite capacity: Bitcoin enforces a limit of 4,000,000 weight units (equivalent to 1,000,000 virtual bytes), while Ethereum caps blocks at 30 million gas. Since the mempool typically contains more transactions than can fit in a single block, the block producer must decide which transactions to include and in what order.

The simplest objective is maximizing total transaction fees collected. Miners and validators earn fees from every transaction they include, so packing the most fee-dense transactions yields the highest revenue. However, dependencies between transactions (a child transaction that spends from an unconfirmed parent) and, in Ethereum's case, opportunities for value extraction through transaction ordering add significant complexity.

The result of block packing is a block template: an ordered list of transactions ready for the block producer to mine or propose.

How It Works

The Knapsack Problem

Block packing maps directly to the classic knapsack problem from computer science. Each transaction has a "weight" (its size in vbytes or weight units) and a "value" (the fee it pays). The block's capacity is the knapsack's weight limit. The goal: maximize total value without exceeding the capacity.

The general knapsack problem is NP-hard, meaning no known algorithm solves it optimally in polynomial time. However, block packing in practice is far more tractable. With typical transactions averaging around 250 to 500 vbytes and a block capacity of 1,000,000 vbytes, a block can hold thousands of transactions. When many small, similarly-sized items compete for space, a greedy algorithm (sorting by fee density and picking from the top) produces results very close to optimal.

Complications arise from transaction dependencies. In the UTXO model, a child transaction cannot be included without its unconfirmed parent. This means the block assembler cannot simply sort all transactions independently: it must consider packages of related transactions together.

Bitcoin Core's Block Assembly Algorithm

Bitcoin Core builds block templates using an algorithm based on ancestor feerate sorting. Introduced in 2016, this approach treats each transaction not in isolation but as part of a package that includes all of its unconfirmed ancestors.

The process works as follows:

For each transaction in the mempool, compute its ancestor feerate: the combined fee of the transaction plus all its unconfirmed ancestors, divided by their combined size
Sort all transactions by this ancestor feerate in descending order
Select the highest-scoring transaction and include it along with any unconfirmed ancestors not already in the template
Update the ancestor scores of remaining transactions to reflect what has already been included
Repeat until the block is full or the mempool is exhausted

This greedy algorithm handles the dependency problem elegantly. A low-fee parent with a high-fee child gets pulled into the block because the child's ancestor feerate accounts for the parent's weight. This is conceptually similar to child-pays-for-parent (CPFP): a generous child fee effectively subsidizes its parent's inclusion.

# Simplified ancestor feerate calculation
ancestor_fee = tx.fee + sum(ancestor.fee for ancestor in tx.unconfirmed_ancestors)
ancestor_size = tx.size + sum(ancestor.size for ancestor in tx.unconfirmed_ancestors)
ancestor_feerate = ancestor_fee / ancestor_size  # sat/vB

Cluster Mempool and Chunk Feerate

The ancestor feerate algorithm has a known limitation: it can produce suboptimal block templates in certain edge cases involving complex transaction graphs. Cluster mempool, a major redesign of Bitcoin Core's mempool infrastructure, addresses this by introducing a more rigorous approach based on linearization and chunk feerates.

Under cluster mempool, related transactions are grouped into clusters. Each cluster is linearized into an optimal ordering, then split into "chunks": contiguous groups of transactions that should be included together. Block building becomes straightforward: take chunks in descending feerate order across all clusters until the block is full.

Pieter Wuille's analysis shows that if linearizations are near-optimal, the total fee loss from this chunk-based approach is bounded by the unfilled block space multiplied by the feerate of the first chunk that does not fit. In practice, this produces block templates that are closer to optimal than the legacy ancestor feerate algorithm.

Ethereum Block Building

Ethereum's approach to block packing differs fundamentally from Bitcoin's. Under proposer-builder separation (PBS), the roles of constructing and proposing blocks are separated. Specialized block builders compete in an auction run through MEV-Boost relays, bidding for the right to have their block included by the proposing validator.

Ethereum builders optimize for more than just transaction fees. They also extract maximal extractable value (MEV) through strategies like arbitrage, liquidations, and sandwich attacks. A builder's block packing algorithm considers not just which transactions to include but their precise ordering, since the sequence of state changes determines MEV opportunities.

This has led to significant builder concentration. As of 2024, MEV-Boost handled approximately 90% of Ethereum blocks, with just a handful of builders producing the vast majority of them. Efforts like enshrined PBS (ePBS) aim to bring builder separation into the consensus layer to reduce reliance on trusted relays and improve decentralization.

Use Cases

Mining Revenue Optimization

The primary use case for block packing is maximizing miner or validator revenue. During periods of high network congestion, the difference between a well-packed and poorly-packed block can be substantial. Optimal packing ensures that the highest-value transactions are included first, directly impacting the block producer's block reward from fees.

Fee Market Dynamics

Block packing algorithms define the fee market by determining the minimum feerate required for inclusion. When blocks are full, the packing algorithm's selection threshold becomes the effective floor price for block space. Users must bid above this threshold to get their transactions confirmed, creating a competitive market for scarce block capacity.

Transaction Prioritization

Bitcoin Core supports the prioritisetransaction RPC, which lets node operators add a fee delta to specific transactions. The block assembly algorithm uses these modified fees during ancestor feerate calculation, allowing miners to prioritize specific transactions (for example, their own consolidation transactions) without those transactions actually paying higher on-chain fees.

Fee Estimation

Wallet fee estimation algorithms depend on understanding how block packing works. By simulating the block assembly process against the current mempool, wallets can predict the feerate needed for confirmation within a target number of blocks. Bitcoin Core's MiniMiner uses the same ancestor-set scoring algorithm for this purpose.

Risks and Considerations

Centralization Pressure

Sophisticated block packing algorithms can create centralization pressure. In Ethereum, the complexity of MEV extraction has concentrated block production among a small number of specialized builders. In Bitcoin, the simpler fee-maximization objective keeps block template construction accessible to individual miners, but any shift toward MEV-style optimization on Bitcoin layer 2s could introduce similar dynamics.

Suboptimal Templates

No polynomial-time algorithm guarantees optimal block packing in all cases. The ancestor feerate heuristic can miss better arrangements when complex dependency chains create conflicting incentives. Cluster mempool improvements significantly narrow this gap, but perfect optimality remains computationally intractable for arbitrary transaction graphs.

Transaction Pinning

Transaction pinning exploits weaknesses in block packing algorithms. An attacker can craft transactions that manipulate feerate calculations to prevent a victim's transaction from being included in a block template. Cluster mempool's improved linearization makes certain pinning vectors harder to exploit, but the attack surface remains a concern for time-sensitive protocols like Lightning.

MEV and Fairness

On Ethereum, block packing is inseparable from MEV extraction. Builders routinely reorder, insert, or censor transactions to capture value. While PBS isolates validators from needing to run MEV strategies themselves, the system raises fairness concerns: ordinary users may receive worse execution prices due to sandwich attacks and other extractive ordering strategies.