What happened
On 24 August 2026 Bitcoin Core merged pull request 35580, "bugfix: compare non-adjusted chunk weight against block weight limit". The block assembler, the code that picks which transactions go into the template a miner hashes, was measuring a candidate group of transactions with one ruler and the space remaining in the block with another. Groups that would have fitted were skipped, and as the description puts it, "those chunks pay higher fees, so this could potentially cause miners to needlessly forfeit some fees revenue". The fix is on master and has not shipped in a release yet.
What it changes
Bitcoin Core keeps two different sizes for a transaction, and they exist for different reasons.
The first is real weight, and it is a consensus limit: a block may not exceed 4,000,000
weight units, with a separate ceiling of 80,000 on the cost of its signature operations. The
second is a policy device. Signature checks are expensive for every node to verify but cheap
to put in a transaction, so Core ranks a transaction in the mempool
by its sigops-adjusted weight, which
GetSigOpsAdjustedWeight
computes as max(weight, sigop_cost * bytes_per_sigop), with -bytespersigop defaulting to
20. A transaction dense in signature checks is therefore priced as though it were larger than
it is, which is the intended effect.
The bug was using the second number to answer a question only the first one can answer.
TestChunkBlockLimits
added the group's adjusted weight to the weight already in the block and compared that to the
limit. A group that physically fitted was rejected because its inflated size did not. The
assembler then skipped it and took the next best group, which by construction pays less.
Where the block was nearly full, a run of such skips could also trip the give-up path that
ends assembly after a thousand consecutive failures.
The patch passes the sum of each transaction's actual weight instead, and leaves the signature operation check where it was, testing real sigop cost against the real sigop ceiling. Two limits, two rulers, which is what the ranking rule never needed to be involved in.
What it does not change
No consensus rule moved, and no block was ever invalid. Every template the old code produced was a legal block. It just left money on the table, and only in the narrow case where a group's signature density pushed its adjusted weight above the space left.
It is not a bug an ordinary user can be hurt by. A transaction skipped from one template stays in the mempool and is picked up by the next block or by another miner running different software. Fee estimation is unaffected: nothing here changes what a wallet should bid.
And it is not yet fixed for anyone running a release. Bitcoin Core 31.0, of 18 March 2026, and 31.1, of 8 July 2026, both carry the original comparison; the 30.x series does not, because it predates the chunk-based assembler. A miner who wants the fix today builds from master or waits.
Context
Core has spent this August on the arithmetic around blocks rather than on the rules inside them. The mempool fee estimator merged a week earlier takes the lower of two estimates precisely so that a new signal cannot raise a recommendation on its own. Both changes are about not trusting one number to do a second number's job.
The transferable lesson is narrower than "check your units". Ranking and capacity are separate jobs. A ranking number is allowed to be a fiction, because its only purpose is to order things against each other, and charging a signature-heavy transaction as though it were bigger is a deliberate fiction that works. A capacity number has to be true, because something physical is being filled. Code that lets the first stand in for the second gets sound blocks that are worth less than they should be, and nothing anywhere reports it.