miner: ensure block_max_weight is flattened before limit checks
What the developer wrote
Authored by Sjors Provoost
miner: ensure block_max_weight is flattened before limit checks
Suggested in https://github.com/bitcoin/bitcoin/pull/33966#discussion_r3303462087
What changed, and why it matters
This is a small hardening change in Bitcoin Core's block-building code. It adds internal safety checks (assertions) to make sure a configuration value called block_max_weight has been converted from an optional value to a plain number before it is used in limit comparisons. The change does not by itself fix a known exploitable bug, but it guards against a class of programming mistakes where an unset value could silently behave as zero and cause incorrect block-size decisions.
Treat as a routine hardening commit. Reviewers should verify that block_max_weight is indeed always flattened before these code paths are reached, so the new assertions cannot be triggered by normal operation. No urgent action is warranted absent additional context showing an exploitable unflattened path.
Security signals we found
Defensive assertion added around optional dereference
Mining/block-assembly limit check touched
No functional change when value is present; guards against absent-value path
No disclosed vulnerability or exploit referenced
Evidence from the diff
The patch modifies TestChunkBlockLimits() and addChunks() in src/node/miner.cpp to assert that m_options.block_max_weight is engaged (non-nullopt) before dereferencing it. The surrounding code already dereferenced the optional implicitly or via operator*, so the functional behavior is unchanged when the value is present. The commit message says the value ‘has been flattened before block assembly limit checks,’ indicating this is a defensive assertion rather than a logic change. No vulnerability disclosure, CVE, or researcher attribution is present in the commit or supplied references.
Changed components
src/node/miner.cppBlockAssembler::TestChunkBlockLimitsBlockAssembler::addChunksblock_max_weight option handlingInspect captured patch +6 / −2
diff --git a/src/node/miner.cpp b/src/node/miner.cpp
index ccd9cc7c..32a21440 100644
--- a/src/node/miner.cpp
+++ b/src/node/miner.cpp
@@ -245,7 +245,9 @@ std::unique_ptr<CBlockTemplate> BlockAssembler::CreateNewBlock()
bool BlockAssembler::TestChunkBlockLimits(FeePerWeight chunk_feerate, int64_t chunk_sigops_cost) const
{
- if (nBlockWeight + chunk_feerate.size >= m_options.block_max_weight) {
+ // block_max_weight has been flattened before block assembly limit checks.
+ Assert(m_options.block_max_weight);
+ if (nBlockWeight + chunk_feerate.size >= *m_options.block_max_weight) {
return false;
}
if (nBlockSigOpsCost + chunk_sigops_cost >= MAX_BLOCK_SIGOPS_COST) {
@@ -318,8 +320,10 @@ void BlockAssembler::addChunks()
m_mempool->SkipBuilderChunk();
++nConsecutiveFailed;
+ // block_max_weight has been flattened before block assembly limit checks.
+ Assert(m_options.block_max_weight);
if (nConsecutiveFailed > MAX_CONSECUTIVE_FAILURES && nBlockWeight +
- BLOCK_FULL_ENOUGH_WEIGHT_DELTA > m_options.block_max_weight) {
+ BLOCK_FULL_ENOUGH_WEIGHT_DELTA > *m_options.block_max_weight) {
// Give up if we're close to full and haven't succeeded in a while
return;
}
Why this scored 23/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.