Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.
Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
This change fixes a Bitcoin Core wallet bug where the `importprunedfunds` RPC command could only re-import transactions that sent money to the wallet, not transactions that spent money from it. After this fix, both incoming and outgoing tr…
Logic bug in wallet transaction import scopeIncorrect balance possible after removing and re-importing spending transactionFix routes import through existing involvement check (IsMine + IsFromMe)
This commit adds a new Bitcoin Core wallet startup option called -maxfeerate. It lets users set a maximum fee rate (fee per unit of transaction size) that the wallet will allow when creating or broadcasting transactions. Previously, the wa…
New wallet startup option -maxfeerate to cap transaction fee rateNew transaction error type MAX_FEE_RATE_EXCEEDEDBroadcastTransaction now checks both max absolute fee and max fee rate
This Bitcoin Core update fixes a wallet-signing quirk. When a user chose the SIGHASH_SINGLE signature mode, an input that had no matching output index would sign essentially nothing meaningful. That signature could then stay valid even if …
Funds-redirection footgun from SIGHASH_SINGLE signatures with no committed outputInconsistent guard between SignTransaction and SignPSBTInput pathsFix centralizes the guard in the low-level signature creator to cover future signing paths
This change updates Bitcoin Core's I2P (Invisible Internet Project) privacy network settings to use newer, stronger encryption for the published 'leaseset' that describes how other peers can contact a node. The old setting included ElGamal…
Cryptographic algorithm update (ElGamal to MLKEM-768)Use of I2P 'legacy' encryption type removedConfiguration-only change in network privacy layer
This change fixes a labeling bug in Bitcoin Core's first-run disk-space warning. The estimate was stored in GiB (binary gigabytes, 1024-based) but displayed as GB (decimal gigabytes, 1000-based), and for pruned nodes it showed the full-cha…
This is a wallet bug, not a theft or remote-code bug. When a Bitcoin Core user turns on the optional 'avoidpartialspends' or 'avoid_reuse' setting, an output group rejected during coin selection could be counted twice as 'discarded.' That …
Logic error causing double-counting of discarded UTXO groupsCan trigger false 'insufficient funds' failure in coin selectionAffects avoidpartialspends / avoid_reuse wallets only
This is a documentation-only fix in a tutorial file. It changes two shell examples from using '>>' (append to file) to '>' (overwrite file). If a user followed the old instructions and ran the same command twice, the file would contain two…
No security signal: change is limited to documentationNo code changes to Bitcoin Core binaries, RPC, wallet, or consensus logicNo cryptographic, network, or privilege-boundary implications
This is a large internal code reorganization (refactor) in Bitcoin Core. It creates a new BlockTemplateManager class that takes over block-template creation, block submission, and tip-waiting helpers that were previously spread across seve…
Large refactor touching mining, RPC, interfaces, and test shutdown pathsNew object lifetime dependency: BlockTemplateManager holds references to mempool, chainman, and notifications; explicit reset ordering added in Shutdown/InitAndLoadChainstate/test setupsRemoval of early-init node.mining interface; BlockTemplateManager is now created after chainstate load, with a comment that it must exist before setChainstateLoaded(true) unblocks IPC waiters
This commit adds the first implementation of BIP352 (Silent Payments) to Bitcoin Core. Silent Payments are a new type of privacy-preserving Bitcoin address that lets someone receive payments without publicly revealing a fixed address. The …
New cryptographic feature implementation (BIP352 Silent Payments)Extensive use of secp256k1 silentpayments moduleInput public key extraction from P2PKH, P2WPKH, P2SH-P2WPKH, and P2TR inputs
This update fixes a wallet database loading bug where a damaged or tampered Bitcoin wallet file could cause the program to read past the end of a stored extended public key (xpub). The patch makes the loader check the stored xpub length be…
Out-of-bounds read in wallet descriptor cache deserializationASan container-overflow triggered by malformed on-disk recordMissing length validation between record size prefix and fixed-size decoder
This commit adds a new wallet RPC called listrawtransactions to Bitcoin Core. It is a feature addition that lets users list every transaction their wallet knows about, including internal transfers and consolidations that the existing listt…
No security-relevant bug fix or vulnerability patch is present in the diff.New RPC exposes additional wallet transaction metadata, but only to callers already authorized for wallet RPCs.Code is a refactor of existing gettransaction logic into shared helpers; no new cryptographic, network, or consensus code.
This Bitcoin Core update fixes several wallet bugs where a failed database write could leave a wallet in an inconsistent state. For example, encrypting a wallet or changing its passphrase could appear to succeed in memory while the change …
Atomicity fix for encryption state and descriptor key persistenceFailure to persist master key during encryption previously reported success in memoryPassphrase change could activate new passphrase only in memory
This commit only changes Bitcoin Core's internal functional test code. It replaces hard-coded test keys and addresses with ones generated from a new test helper class, and unifies how tests tell nodes not to create a default wallet. There …
This commit only adds a new automated test to Bitcoin Core. It checks that when two partially-signed Bitcoin transactions (PSBTs) are combined, any custom 'unknown' data fields attached to them are preserved correctly. There is no change t…
This is a Bitcoin Core wallet maintenance patch. It speeds up a wallet function that checks whether a descriptor already exists by caching a hash of the descriptor's canonical text, instead of rebuilding that text every time. It also tidie…
No security-relevant signal in commit message or diffChange is described as performance improvement and code cleanupBackwards-compatibility test notes a known miniscript wallet loading incompatibility between v31.0/v31.1 and other versions, but this is a documented compatibility quirk, not a vulnerability
This is a documentation-only fix for Bitcoin Core's machine-readable RPC help data. It changes several default values from literal strings to 'hint' labels (because the real default depends on context) and corrects one boolean default from…
OpenRPC schema/default mismatch correctionRPC help metadata type correction (string 'false' to boolean false)No executable code path changes
This commit fixes documentation metadata for six Bitcoin Core RPC arguments. It changes how default values are described so that automatically generated API docs and schemas are accurate. The actual behavior of the software when running is…
No runtime code changesOnly RPC help/schema metadata modifiedVendor explicitly states runtime behavior is unchanged
This commit fixes a bug in Bitcoin Core's MuHash3072 cryptographic code where dividing a MuHash object by itself (x /= x) produced the wrong mathematical result. The fix is straightforward: the code now saves the divisor's numerator before…
Cryptographic correctness bug in MuHash3072 division operatorSelf-aliasing in operator/= produces incorrect 1/D result instead of empty setNo production code path identified that triggers self-division
This is a build-compatibility fix, not a security patch. It changes how some constant data is stored internally so that Apple's macOS linker (ld64) can build Bitcoin Core correctly. The change avoids a linker bug that caused build failures…
No security-relevant code logic changedChange is a linker bug workaround, not a vulnerability fixConstants remain read-only; no new attack surface introduced
This commit refactors Bitcoin Core's wallet descriptor import feature so the same logic can be used by both the RPC command and a new GUI-facing interface. It also tightens one input rule: negative timestamps are now rejected, and the mini…
Refactor of security-sensitive wallet import code into shared CWallet pathNew input validation: negative timestamps rejected for importdescriptorsCentralization of descriptor range bound checks in CheckDescriptorRangeBounds
Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
Security candidatewallet: reject sendtoaddress and sendmany for external signersby Sjors Provoost · 2fe34808 · Jun 11, 2026 · 2 filesMessage 83 · StrongInformational 24Details
Commit message · Sjors Provoost
wallet: reject sendtoaddress and sendmany for external signers
The sendtoaddress and sendmany RPCs always go through SendMoney(), which expects to sign internally. External signer wallets should use the PSBT flow instead, via the send RPC.
Return a more specific error for external signer wallets and add functional test coverage for both RPCs.
83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 24/100
This change makes Bitcoin Core refuse two older wallet commands (sendtoaddress and sendmany) when the wallet is controlled by an external signer, such as a hardware wallet. Previously these commands could be called but would fail in a confusing way because they expect to sign transactions internally. Now they return a clear message telling the user to use the newer send command instead. It is a usability and safety improvement, not a fix for an active attack.
Lower-prioritycoins: compact chainstate in backgroundby Lőrinc · 394e473d · Jun 11, 2026 · 4 filesMessage 68 · AdequateInformational 18Details
Commit message · Lőrinc
coins: compact chainstate in background
Full chainstate compaction can take minutes on large databases. Move `CCoinsViewDB::CompactFull()` to a named `utxocompact` one-shot background thread so validation only schedules the work.
When validation selects compaction after a full flush, the chainstate was just written and another write is less likely to be needed immediately. The coins view destructor waits for completion, and a mutex prevents compaction from using `m_db` while `ResizeCache()` replaces it.
Co-authored-by: Andrew Toth <andrewstoth@gmail.com>
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 18/100
This change moves Bitcoin Core's full chainstate database compaction from the main validation thread into a one-shot background thread named 'utxocompact'. The goal is to avoid blocking validation for minutes on large databases. The patch adds a destructor that waits for the background job to finish, a mutex to prevent the database from being resized while compaction is running, and catches exceptions so compaction failures don't crash the node. It is a performance and robustness improvement, not a fix for an active security vulnerability.
Full chainstate flushes are convenient maintenance points for long-term LevelDB cleanup because the chainstate was just written. Randomize the trigger so nodes that flush near the same height do not compact together.
Add blocking chainstate compaction through `CCoinsViewDB::CompactFull()` and give each post-IBD full flush on the normal chainstate a 1/320 chance to start compaction. With hourly flushes this averages roughly every two weeks and makes a six-month miss about one in a million. This keeps the schedule stateless and leaves last-compaction height or timestamp bookkeeping out of chainstate metadata.
Co-authored-by: Andrew Toth <andrewstoth@gmail.com>
This change makes Bitcoin Core occasionally clean up its chainstate database after a normal full flush, and randomizes when that cleanup happens so different nodes don't all do it at the same time. It is a maintenance/performance improvement, not a security fix, and does not introduce a known vulnerability.
AI review queueddoc: add taproot descriptor to getdescriptors exampleby woltx · bd5a32f7 · Jun 11, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · woltx
doc: add taproot descriptor to getdescriptors example
Wallets import descriptors for all supported address types in a BIP44/49/84/86 compatible manner, so show the BIP86 tr() descriptor in the example response as well.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathdocumentation-only discountsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit only updates a documentation example in external-signer.md to include a Taproot (BIP86 tr()) descriptor alongside existing address-type examples. It is a documentation-only change with no code modifications, no functional changes, and no security implications.
AI review queueddoc: clarify which commands receive --chain, --fingerprint and --stdinby woltx · 7131c829 · Jun 11, 2026 · 2 filesMessage 73 · AdequateInformational 15Details
Commit message · woltx
doc: clarify which commands receive --chain, --fingerprint and --stdin
Bitcoin Core passes --chain and --fingerprint to every signer command except enumerate, so mark them "(required except for enumerate)" and name the current commands only as examples. Keep --stdin documented as required for all commands so the interface stays flexible, noting that Bitcoin Core currently only uses it for signtx.
Add the missing flags to the getdescriptors and displayaddress usage examples and the corresponding doxygen comments, matching the order and form of the actual invocations, add testnet4 to the chain name lists, and drop the getaddressinfo implementation detail from the walletdisplayaddress description.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit only updates documentation and code comments for Bitcoin Core's external signer interface. It clarifies which command-line flags are passed to which signer commands and fixes usage examples to match the actual implementation. No code behavior changes, no security bug fix, and no vulnerability is present.
Security candidatedoc: replace stale signtransaction wording with current signtx flowby woltx · 4fdd4d8d · Jun 11, 2026 · 2 filesMessage 81 · StrongInformational 15Details
Commit message · woltx
doc: replace stale signtransaction wording with current signtx flow
The protocol documentation still described a "signtransaction" command driven by sendtoaddress and sendmany. Those RPCs never gained external signer support: it was effectively precluded by #21201, which was merged a few days before external signer support landed in #16546, so the interaction was missed in review (#33112 has a commit making the rejection explicit). Spending from an external signer wallet uses send/sendall (and bumpfee for fee-bumping), which invoke the signer with `<cmd> --stdin` and pass the `signtx` subcommand and PSBT over stdin.
Update the spending example and the protocol description accordingly, using `bitcoin rpc` for the example since it enables -named by default.
81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100
This commit only updates documentation and a code comment to match how external (hardware) signers actually work in current Bitcoin Core. It does not change any executable code, RPC behavior, or security logic. There is no security vulnerability here.
AI review queueddoc, rpc: document enumerate model field and fingerprint deduplicationby woltx · fab92257 · Jun 11, 2026 · 2 filesMessage 73 · AdequateInformational 15Details
Commit message · woltx
doc, rpc: document enumerate model field and fingerprint deduplication
The external signer "enumerate" response uses the optional "model" field, not "name". Document that Bitcoin Core maps it to the "name" field of the enumeratesigners RPC result, and that signers with duplicate master key fingerprints are skipped.
Also document that wallet operations require exactly one connected signer.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit only updates documentation and RPC help text. It explains how Bitcoin Core talks to external hardware wallets: the signer's 'model' field becomes the 'name' shown to users, duplicate fingerprints are skipped, and wallet operations require exactly one connected signer. No code behavior changed, so there is no security issue here.
Lower-prioritycoins: test chainstate flush baselineby Lőrinc · b10889d1 · Jun 11, 2026 · 5 filesMessage 78 · AdequateInformational 15Details
Commit message · Lőrinc
coins: test chainstate flush baseline
Add `CDBWrapper::GetProperty()` and expose it through `CCoinsViewDB::GetDBProperty()` so coins tests can inspect LevelDB runtime properties through the coins view. Use it in a coins DB flush baseline that records the LevelDB layout after flushing while keeping readback coverage for the flushed coin and best block.
Co-authored-by: Andrew Toth <andrewstoth@gmail.com>
78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 15/100
This commit adds a new test helper that lets the existing test suite read internal LevelDB statistics, and uses it to add a baseline test checking how many files LevelDB creates after flushing a small coins database. It is purely a testing/instrumentation change and does not alter production behavior.
Lower-prioritytest: ensure group data cluster pointers are liveby Greg Sanders · df9eb72b · Jun 11, 2026 · 1 fileMessage 67 · AdequateInformational 14Details
Commit message · Greg Sanders
test: ensure group data cluster pointers are live
67/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
AI analysis · Informational 14/100
This is a small change to an internal self-check (SanityCheck) inside Bitcoin Core's transaction graph code. It adds a new consistency check to make sure that certain cached cluster pointers actually point to currently live data structures. It does not change normal runtime behavior and is not a fix for an externally exploitable bug.
✓ Subject identifies a change✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
authentication path
AI analysis · Informational 15/100
This commit simply updates the version number of the Alpine Linux container used in Bitcoin Core's automated testing from Alpine 3.23 to Alpine 3.24. It is a routine CI (Continuous Integration) maintenance change with no visible security relevance.
AI review queuedtest: add abortscan unit testby Pol Espinasa · 2818a171 · Jun 11, 2026 · 1 fileMessage 82 · StrongInformational 15Details
Commit message · Pol Espinasa
test: add abortscan unit test
Co-authored-by: w0xlt <woltx@protonmail.com>
82/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit only adds a new unit test to Bitcoin Core's wallet test suite. It verifies that the wallet's rescan-abort mechanism behaves correctly in two scenarios: an abort requested before any rescan starts should not accidentally cancel a later scan, and an abort requested after a reservation but before the scan begins should cancel the scan. There is no change to production code, no bug fix, and no security-relevant behavior introduced.
AI review queuedwallet: move fAbortRescan reset into WalletRescanReserver reserve()by Pol Espinasa · bc30e951 · Jun 11, 2026 · 2 filesMessage 73 · AdequateLow 33Details
Commit message · Pol Espinasa
wallet: move fAbortRescan reset into WalletRescanReserver reserve()
Reserving the wallet rescan is the first thing done when starting a rescan. As part of the reservation, clear any leftover state from previous rescans (reset fAbortRescan). This prevents a race condition where an abort request arrives before the rescan loop starts; without this reset, the abort could be ignored and the rescan would proceed.
Co-authored-by: w0xlt <woltx@protonmail.com>
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: broader security terminologysecond-pass: security-sensitive path
AI analysis · Low 33/100
This Bitcoin Core wallet patch fixes a small but real timing bug: if a user clicked 'abort rescan' at exactly the wrong moment, the abort signal could be ignored and the rescan would keep running. The fix moves the 'clear any old abort signal' step to the moment the rescan reservation is taken, so a fresh abort request is always honored. It is a reliability/usability bug, not a theft-of-funds vulnerability.
AI review queuedbtcsignals: delete broken scoped_connection move assignmentby Thomas · b83a999b · Jun 11, 2026 · 1 fileMessage 73 · AdequateLow 33Details
The defaulted move assignment overwrites m_conn without disconnecting it first, so the previous callback stays registered with the signal and keeps firing, violating the RAII contract:
btcsignals::scoped_connection sc0 = sig.connect(IncrementCallback); btcsignals::scoped_connection sc1 = sig.connect(SquareCallback); sc0 = std::move(sc1); val = 3; sig(val); // both callbacks fire: 16 instead of 9
Move assignment is unused in the codebase, so delete it rather than fixing it. It can be implemented properly if a use case arises.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 33/100
This commit removes a broken move-assignment operator from a small helper class that manages automatic disconnection of signal callbacks. The broken operator could leave an old callback registered after a move, causing unexpected behavior. The commit states the operator is unused in the codebase, so it is deleted rather than fixed. There is no direct evidence this bug was exploitable for security harm.
Lower-priorityvalidation: check invariants when inserting into m_blocks_unlinkedby stratospher · d6359937 · Jun 11, 2026 · 3 filesMessage 93 · StrongModerate 59Details
Commit message · stratospher
validation: check invariants when inserting into m_blocks_unlinked
For an entry A -> B in m_blocks_unlinked, the entry B was added into m_blocks_unlinked either because: - some ancestor of B was never received (or) - some ancestor of B was pruned away.
Every insert must satisfy two invariants: 1. B has BLOCK_HAVE_DATA set. 2. No duplicate A -> B entries in m_blocks_unlinked (this is UB zone if this entry gets popped twice in ReceivedBlockTransactions and happens to be in setBlockIndexCandidates)
2 bugs (#35070 and #35168) discovered recently stemmed from the m_blocks_unlinked insertion sites not enforcing these invariants. So add a helper which wraps around insertion sites of m_blocks_unlinked with these invariants.
Co-authored-by: Martin Zumsande <mzumsande@gmail.com>
93/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
AI analysis · Moderate 59/100
This commit adds safety checks around a Bitcoin Core internal data structure called m_blocks_unlinked, which tracks blocks whose parent chain is missing. The change prevents two problems: inserting blocks that have no actual stored data, and inserting the same block twice. The commit message says both duplicate entries and missing-data entries could lead to undefined behavior inside the block validation engine, including corrupting the candidate-chain ordering. The patch is defensive hardening rather than a complete fix for the two referenced bugs.
test/doc: remove misleading comment and improve tests
remove misleading comment for m_blocks_unlinked since for pruned nodes: - usually A is the missing data (just like in non-pruned nodes) - in PruneOneBlockFile, we remove entries once data for B is missing.
Co-authored-by: Martin Zumsande <mzumsande@gmail.com>
83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 15/100
This commit only touches documentation and test code. It removes an outdated comment about how pruned nodes track partially downloaded blocks and fixes a timing bug in a test where wallet status was being checked from a stale snapshot instead of live data. There are no changes to production code, no security fix, and no vulnerability.
Lower-prioritytest: add coverage for UB caused by FindMostWorkChainby stratospher · ca4a3802 · Jun 11, 2026 · 1 fileMessage 95 · StrongInformational 12Details
Commit message · stratospher
test: add coverage for UB caused by FindMostWorkChain
when pruned node2 finally receives the blocks from node0, node2 will process duplicate entires in ReceivedBlockTransactions twice but it will only insert into setBlockIndexCandidates if the block has more work that the current chain tip.
the duplicate entries in m_blocks_unlinked in this test are from height 1171 to 1294.
before this commit - we invalidated height 1320 and chain tip became 1319. so we won't add duplicate entries (all have <1319) into setBlockIndexCandidates and won't have coverage for this UB scenario.
with this commit - we invalidate height 1295 and chain tip became 1294. so we will process the duplicate entry 1294 in m_blocks_unlinked and have coverage for this UB.
Co-authored-by: Martin Zumsande <mzumsande@gmail.com>
95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
defensive validation
AI analysis · Informational 12/100
This commit only changes a test file. It adjusts which block height is invalidated in an existing functional test so that the test exercises a specific edge case involving duplicate block processing in pruned nodes. There is no change to production code, so it does not introduce or fix a live vulnerability by itself. It is a test-coverage improvement.
Lower-priorityvalidation: avoid duplicates in m_blocks_unlinkedby stratospher · c787b3b9 · Jun 11, 2026 · 1 fileMessage 68 · AdequateModerate 54Details
Commit message · stratospher
validation: avoid duplicates in m_blocks_unlinked
In a pruned node undergoing a deep reorg, FindMostWorkChain can insert duplicate entries into m_blocks_unlinked.
This can happen when: - Traversing from one candidate tip to the fork point adds blocks whose parents have been pruned. - Traversing from another candidate tip over the same fork inserts the same pairs again, since the blocks are shared across both branches.
When we finally download the missing parent from our peer and call ReceivedBlockTransactions to process m_blocks_unlinked, the same entry may be processed multiple times.
This can lead to re-insertion into setBlockIndexCandidates with a modified nSequenceId, violating its ordering invariants and causing undefined behavior. So avoid duplicate insertions into m_blocks_unlinked here.
Co-authored-by: Martin Zumsande <mzumsande@gmail.com>
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Moderate 54/100
This Bitcoin Core update fixes a bug where, during a deep chain reorganization on a pruned node, the same block entries could accidentally be added twice to an internal waiting list. If processed twice later, this could corrupt an ordered set used to choose the best chain, potentially causing crashes or undefined behavior. The fix prevents duplicates and adds a safety check.
Also assert that the availability of the satisfaction weight estimate does not depend on the signature-size assumption, and that assuming non-max-size signatures never increases the estimate.
83/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundaryfuzzing or regression evidence
AI analysis · Informational 15/100
This commit is a small fuzz-test improvement. It fixes an obvious test bug where the same function was being called twice with the same argument, and instead calls it with both possible arguments, then adds assertions about the results. It does not change any production wallet, consensus, or networking code, and there is no security fix or vulnerability indicated.
Lower-priorityqa: Use custom assert_greater_than() over naked assertby Hodlinator · 472b950b · Jun 10, 2026 · 1 fileMessage 65 · AdequateInformational 15Details
Commit message · Hodlinator
qa: Use custom assert_greater_than() over naked assert
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
AI analysis · Informational 15/100
This is a tiny test-only cleanup that swaps a plain Python assert for a custom helper that prints better error messages when a test fails. It does not change any production code, network behavior, or security logic.
Lower-priorityfuzz: improve dbwrapper_concurrent_reads performanceby Andrew Toth · 1ce9e262 · Jun 10, 2026 · 1 fileMessage 50 · ThinInformational 15Details
✓ Specific, descriptive subject✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 15/100
This commit only changes a fuzz test file (a special kind of automated test that feeds random data to the code to find bugs). It rewrites how a concurrent-read fuzz target works, replacing a result-comparison approach with an oracle-based assertion approach and reusing a global thread pool. There is no change to production Bitcoin Core code, no fix to a real vulnerability, and no security-relevant change to how the software behaves on real networks or wallets.
AI review queuedtest: add coverage for importdescriptors when manually interrupting a wallet rescanby Pol Espinasa · ed11dd6a · Jun 10, 2026 · 1 fileMessage 87 · StrongInformational 15Details
Commit message · Pol Espinasa
test: add coverage for importdescriptors when manually interrupting a wallet rescan
Co-authored-by: w0xlt <woltx@protonmail.com>
87/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit adds a new automated test to Bitcoin Core. The test checks what happens when a user cancels a wallet rescan while importing descriptors. It does not change any production wallet code; it only adds test coverage. There is no security vulnerability here.
AI review queuedtest: add coverage for importdescriptors errors when using assumeutxoby Pol Espinasa · d90d7f0a · Jun 10, 2026 · 1 fileMessage 87 · StrongInformational 15Details
Commit message · Pol Espinasa
test: add coverage for importdescriptors errors when using assumeutxo
Co-authored-by: w0xlt <woltx@protonmail.com>
87/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit only adds a new test case to Bitcoin Core's test suite. It checks that the wallet's importdescriptors RPC returns a specific error message when used during an in-progress assumeutxo background sync. There is no change to production code, no bug fix, and no security vulnerability being introduced or patched.
AI review queuedtest: add coverage for importdescriptors while wallet is rescanningby Pol Espinasa · ad388bf2 · Jun 10, 2026 · 1 fileMessage 87 · StrongInformational 15Details
Commit message · Pol Espinasa
test: add coverage for importdescriptors while wallet is rescanning
Co-authored-by: w0xlt <woltx@protonmail.com>
87/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit only adds a new automated test to Bitcoin Core. It checks that if you try to import wallet descriptors while the wallet is already busy rescanning the blockchain, the second import attempt is rejected with a clear error message. There is no change to production wallet code, so this patch does not fix or introduce any live security issue by itself.
AI review queuedtest: updated different_key to be different_field and also used a single assert_equal with 3 args instead of multiple assert_equalsby kevkevinpal · ddceb4e6 · Jun 10, 2026 · 1 fileMessage 72 · AdequateInformational 15Details
Commit message · kevkevinpal
test: updated different_key to be different_field and also used a single assert_equal with 3 args instead of multiple assert_equals
72/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This is a minor cleanup of a Bitcoin Core test file. It renames a helper function parameter from 'different_key' to 'different_field' and combines two separate length checks into one three-argument equality assertion. There is no change to production code, no security fix, and no behavior change in what the test verifies.
Security candidateiwyu: Fix warnings in `src/bench` and treat them as errorby Hennadii Stepanov · 6751a323 · Jun 10, 2026 · 58 filesMessage 50 · ThinInformational 15Details
Commit message · Hennadii Stepanov
iwyu: Fix warnings in `src/bench` and treat them as error
50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
cryptography-sensitive pathsigning or wallet path
AI analysis · Informational 15/100
This commit is a code cleanup that adjusts which C++ header files are included in the project's benchmark code and a few related source files. It enables a stricter 'include what you use' (IWYU) check for the benchmark directory so missing or unnecessary #include lines are treated as errors in continuous integration. There is no change to program logic, no bug fix, and no security-relevant behavior.