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 is a one-line documentation update to the macOS build guide. It adds a note telling users to pass a specific CMake option if they want ZeroMQ notification support. There is no code change and no security impact.
This commit only changes Bitcoin Core's internal fuzz testing code. It makes the fuzz tests exercise more of the transaction-handling code path by toggling Initial Block Download mode and resetting the mempool between test runs. There is n…
No production code modifiedNo consensus, validation, net_processing, or wallet logic changedOnly fuzz test harnesses and test utilities affected
This commit removes unused variables from Bitcoin Core's test and fuzzing code. It is a cleanup/refactoring change with no effect on the live network software or user funds. It does not fix or introduce any security vulnerability.
This commit is a routine code cleanup in Bitcoin Core. It switches the uint256 equality and comparison operators to use standard C++20 defaults, removes an old custom Compare() helper, and marks an internal assertion-failure function as ne…
This update fixes a counting bug in several Bitcoin Core RPC commands that scan descriptors. When a user requested a descriptor range ending at the maximum allowed value (2,147,483,647), the internal counter used a smaller integer type and…
Signed integer overflow in descriptor expansion loopCrash/undefined behavior on maximum-range descriptor scansAuthenticated RPC surface affected (scantxoutset, scanblocks, getdescriptoractivity, utxoupdatepsbt, descriptorprocesspsbt)
This is a small cleanup and documentation fix for Bitcoin Core's RPC help system. It removes a comment that incorrectly said a certain output type was 'for testing only' and makes the help text properly display those outputs. There is no d…
No memory safety, cryptography, consensus, or authorization changes observedChange is confined to RPC help/schema metadata generationComment-only/type-label change from 'for testing only' to general use
This is a code cleanup change that turns on a static-analysis rule to prevent a specific C++ coding pattern (anonymous namespaces in header files) and updates two headers to comply. It does not change how Bitcoin Core behaves at runtime an…
No security-relevant code changeNo memory safety, cryptography, consensus, or network changesTooling-only refactor (clang-tidy configuration)
This commit only adds new test cases to Bitcoin Core's functional test suite. It does not change any production wallet, node, or RPC code. The tests verify that the importdescriptors RPC reports errors in the right order, rejects bad times…
This change is purely a code cleanup: it moves two internal helper functions of a Bitcoin Core cache class into the private section of the class and removes a duplicate 'private:' label. There is no change to what the code does, no bug fix…
This Bitcoin Core change tightens how three RPC commands (scantxoutset, scanblocks, deriveaddresses) handle the value null when it is passed for optional parameters. Previously, explicitly passing null could be treated differently from sim…
RPC parameter validation changeNull value handling changeAddition of explicit error checks for missing required contextual parameters
This commit is a code cleanup: it turns on a clang-tidy style check called 'misc-definitions-in-headers' and suppresses that check around a large inline implementation block in a benchmark header. There is no change to Bitcoin's runtime be…
This commit only changes a linting configuration file for the project's code style checker. It enables a rule that prevents anonymous namespaces from being used in header files, which is a code-quality and build-hygiene practice. There is …
No security-relevant signals in the diff or commit message.Change is purely a static-analysis/linting configuration update.
This commit is a straightforward code cleanup: it replaces a small custom helper named IntIdentity with the standard C++20 std::identity from the <functional> header. The behavior of the ConvertBits function is unchanged; only the implemen…
This commit only adds a new automated test to Bitcoin Core. It checks that when a user asks the wallet to import multiple descriptors at once, the list of results comes back in the same order as the original request, including any error me…
This commit only adds new automated tests for the Bitcoin Core wallet's importdescriptors RPC. It checks that the command correctly rejects requests with a missing or invalid timestamp. No production wallet code is changed, so this cannot …
No changes to consensus, networking, wallet logic, or cryptographyOnly functional test code is modifiedAdded assertions are for expected error handling paths
This is a minor code cleanup that removes one unused header file include and swaps another for a more specific one. It does not change any program behavior or fix any security issue.
This commit is a routine code cleanup: it adjusts which C++ header files are included in several consensus-related source files and turns on a stricter compiler hygiene check (Include What You Use, or IWYU) for the src/consensus directory.…
This is a small fix to a Bitcoin Core fuzz test (an automated internal testing harness), not to the live network code. The fuzzer was sometimes creating fake P2P messages larger than the real protocol allows and passing them into a test he…
Test-only fuzz harness hardeningOversized message guard added before ReceiveMsgFrom() in fuzz targetNo change to production P2P message acceptance logic
This commit simply removes one failing test configuration (RISC-V 32-bit bare metal) from the project's GitHub Actions CI matrix because it was failing. It is a routine CI maintenance change with no security implications.
This change adds checksum verification to the build system's downloads of Apple, FreeBSD, NetBSD, and OpenBSD software development kits (SDKs). Before this patch, those SDK archives were downloaded at build time and extracted without confi…
Adds cryptographic digest verification for downloaded SDK archivesRemoves unchecked extraction of remote SDK archives in CIHardens CI supply chain for macOS/BSD cross-builds
txgraph: initialize Ref in AddTransaction (preparation)
Instead of returning a TxGraph::Ref from TxGraph::AddTransaction(), pass in a TxGraph::Ref& which is updated to refer to the new transaction in that graph.
This cleans up the usage somewhat, avoiding the need for dummy Refs in CTxMemPoolEntry constructor calls, but the motivation is that a future commit will allow a callback to passed to MakeTxGraph to define a fallback order on the transaction objects. This does not work when a Ref is created separately from the CTxMemPoolEntry it ends up living in, as passing the newly-created Ref to the callback would be UB before it's emplaced in its final CTxMemPoolEntry.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 14/100
This is a Bitcoin Core internal code cleanup that changes how transaction references are created and passed around. It does not fix a security bug, change network behavior, or affect how ordinary users' transactions are processed. The change is preparation for a future feature and is not itself a vulnerability patch.
Serialize `Coin` metadata using the canonical (height << 1) | coinbase packing across `Coin` serialization, undo records, and coinstats hashing.
Cast the 31-bit `nHeight` bitfield to `uint32_t` before shifting to avoid signed promotion undefined behaviour.
80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI analysis · Informational 24/100
This commit tidies up how Bitcoin Core packs two pieces of coin metadata—block height and whether the coin came from a coinbase transaction—into a single serialized number. It makes three different code paths use the exact same bit-packing formula and explicitly converts a signed height value to unsigned before shifting, which removes a technical C++ undefined-behavior risk. The actual serialized bytes do not change for normal values, so this is primarily a code-correctness and consistency fix rather than a fix for an active exploit.
`Coin` packs height and the coinbase flag into a single 32-bit value, so `utxo_size_inc(_actual)` should not count an additional boolean.
Update the calculation and adjust the `rpc_getblockstats` test expectations.
78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 21/100
This commit fixes an accounting error in a Bitcoin Core RPC command called getblockstats. The command reports how much UTXO set size grows when a block is processed. The old code incorrectly counted the coinbase flag as a separate boolean byte, but in reality it is packed into the same 32-bit value as the block height. The fix removes that extra byte from the overhead calculation and updates the corresponding test expectations. It is a correctness bug in statistics output, not a security vulnerability that lets anyone steal funds or crash nodes.
Lower-prioritycoins: make `Coin::fCoinBase` a boolby Lőrinc · 1f309d1a · Feb 9, 2026 · 6 filesMessage 68 · AdequateInformational 15Details
Commit message · Lőrinc
coins: make `Coin::fCoinBase` a bool
The coinbase flag is semantically boolean but was stored as an unsigned bitfield. Store it as a `bool : 1` bitfield to better reflect intent and avoid relying on implicit integral conversions at call sites.
Update users to prefer `Coin::IsCoinBase()` and to pass explicit `true`/`false` values where appropriate.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100
This is a small code-cleanup change in Bitcoin Core. It changes an internal flag that tracks whether a transaction output came from a coinbase (miner's special) transaction from an unsigned integer bitfield to a proper boolean bitfield. Call sites are updated to use true/false and a helper accessor. There is no security bug being fixed here.
Lower-priorityvalidation: don't update BLOCK_FAILED_VALID to BLOCK_FAILED_CHILD in InvalidateBlockby stratospher · 18f11695 · Feb 9, 2026 · 1 fileMessage 73 · AdequateInformational 18Details
Commit message · stratospher
validation: don't update BLOCK_FAILED_VALID to BLOCK_FAILED_CHILD in InvalidateBlock
- there is no functional difference between BLOCK_FAILED_VALID and BLOCK_FAILED_CHILD and it's unnecessary code complexity to correctly categorise them.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
defensive validation
AI analysis · Informational 18/100
This commit simplifies how Bitcoin Core marks blocks as invalid. Previously, the code tried to distinguish between a block that failed validation itself and a child of a failed block, using two different status flags. The commit removes that distinction and uses one flag for both cases, because the two statuses were functionally equivalent. It is a code-cleanup change with no apparent security impact.
Lower-prioritybench: add script verification benchmark for P2TR key path spendsby Sebastian Falbesoner · d339884f · Feb 9, 2026 · 1 fileMessage 60 · AdequateInformational 15Details
Commit message · Sebastian Falbesoner
bench: add script verification benchmark for P2TR key path spends
60/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
defensive validation
AI analysis · Informational 15/100
This commit adds a new performance benchmark to Bitcoin Core. It does not change any production code that runs the Bitcoin network; it only adds a test that measures how fast the software can verify a specific kind of modern Bitcoin transaction (a Taproot/P2TR key-path spend).
Lower-priorityci: Use ubuntu-slim for [meta] runnersby MarcoFalke · fa90277d · Feb 9, 2026 · 1 fileMessage 88 · StrongInformational 15Details
Commit message · MarcoFalke
ci: Use ubuntu-slim for [meta] runners
They should be sufficient for the task, and are based on containers, so may be minimally faster to schedule. Ref: https://docs.github.com/en/actions/reference/runners/github-hosted-runners#single-cpu-runners
88/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
documentation-only discount
AI analysis · Informational 15/100
This commit changes two GitHub Actions CI jobs to run on a smaller, container-based Ubuntu runner image instead of the standard one. It is purely an infrastructure/efficiency tweak for Bitcoin Core's continuous integration system and does not touch any code that handles money, network messages, cryptography, or user data. There is no security-relevant change visible in the diff.
This is the standard approach and avoids relying on VCPKG_INSTALLATION_ROOT and -DCMAKE_TOOLCHAIN_FILE= in the ci-windows.py script.
This makes it easier to run locally.
80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Why it was queued
documentation-only discount
AI analysis · Informational 15/100
This commit is a routine cleanup of Bitcoin Core's Windows CI build scripts. It switches the build process to use a standard CMake 'preset' configuration instead of manually passing a path to the vcpkg toolchain file. There is no security-relevant change here.
Lower-priorityci: Add check_manifests to ci-windows.pyby MarcoFalke · fa3f89ac · Feb 9, 2026 · 2 filesMessage 72 · AdequateInformational 15Details
Commit message · MarcoFalke
ci: Add check_manifests to ci-windows.py
This is mostly a refactor, except for placing the bitcoind.manifest into a different folder.
72/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body
Why it was queued
documentation-only discount
AI analysis · Informational 15/100
This commit moves the Windows CI manifest-checking logic from inline PowerShell in a GitHub Actions workflow file into a shared Python helper script. It does not change what is checked, only where the code lives and where a temporary bitcoind.manifest file is written during the CI run. There is no user-facing or security-relevant behavior change.
Lower-priorityci: Add run_tests step to ci-windows.pyby MarcoFalke · 1111079a · Feb 9, 2026 · 2 filesMessage 90 · StrongInformational 15Details
Commit message · MarcoFalke
ci: Add run_tests step to ci-windows.py
This is mostly a refactor, except for using the runner workspace (cwd) for: * fuzz qa-assets * functional temp prefix
This makes it easier to run the ci-windows.py locally.
90/100 · StrongMessage clarity
✓ 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
fuzzing or regression evidencedocumentation-only discount
AI analysis · Informational 15/100
This commit is a routine cleanup of Bitcoin Core's Windows CI (continuous integration) script. It moves the commands that run tests from the GitHub Actions YAML file into a shared Python helper, and changes where temporary test files are stored so the script can be run locally more easily. There is no indication this affects the security of the Bitcoin software itself or its users.
Security candidateMerge bitcoin/bitcoin#32621: contrib: utxo_to_sqlite.py: add option to store txid/spk as BLOBsby merge-script · 6d625af2 · Feb 8, 2026 · 2904 filesMessage 100 · StrongInformational 15Details
Commit message · merge-script
Merge bitcoin/bitcoin#32621: contrib: utxo_to_sqlite.py: add option to store txid/spk as BLOBs
7378f27b4fb512567b6152f986f67d9263d08d7a test: run utxo-to-sqlite script test with spk/txid format option combinations (Sebastian Falbesoner) b30fca7498c93356fbdb8c2ce881aa8e548bae17 contrib: utxo_to_sqlite.py: add options to store txid/spk as BLOBs (Sebastian Falbesoner)
Pull request description:
This PR is a late follow-up to https://github.com/bitcoin/bitcoin/pull/27432, introducing an option for the utxo-to-sqlite script to store the txid/scriptPubKey columns as bytes (= `BLOB` storage class in sqlite, see e.g. https://www.sqlite.org/datatype3.html in sqlite) rather than hex strings. This was proposed in earlier reviews (https://github.com/bitcoin/bitcoin/pull/27432#issuecomment-1516857024, https://github.com/bitcoin/bitcoin/pull/27432#issuecomment-1653739351) and has the obvious advantage of a significantly smaller size of the resulting database (and with that, faster conversion) and the avoidance of hex-to-bytes conversion for further processing of the data [1]. The rationale on why hex strings were chosen back then (and still stays the default, if only for compatibility reasons) is laid out in https://github.com/bitcoin/bitcoin/pull/27432#issuecomment-1516922824 [2].
The approach taken is introducing new parameters `--spk` and `--txid` which can either have the values "hex", "raw" (for scriptpubkey) and "hex", "raw", "rawle" (for txid). Thanks to ajtowns for providing this suggestion. Happy to take further inputs on naming and thoughts on future extensibility etc.
[1] For a concrete example, I found that having these columns as bytes would be nice while working on a SwiftSync hints generator tool (https://github.com/theStack/swiftsync-hints-gen), which takes the result of the utxo-to-sqlite tool as input. [2] note that in contrast what I wrote back then, I think there is no ambiguity on byte-string-serialization of txids; they are ultimately just hash results and hence, they should be stored as such, and adding a big/little endian knob wouldn't make much sense. The drawback of not being able to immediately show txid-strings (as one would need to do the bytes-reversal step first, which is not possible in sqlite, see e.g. https://github.com/bitcoin/bitcoin/pull/24952#issuecomment-1165499803) still remains though.
ACKs for top commit: ajtowns: ACK 7378f27b4fb512567b6152f986f67d9263d08d7a w0xlt: reACK https://github.com/bitcoin/bitcoin/pull/32621/commits/7378f27b4fb512567b6152f986f67d9263d08d7a sedited: ACK 7378f27b4fb512567b6152f986f67d9263d08d7a
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
cryptography-sensitive pathseed or entropy pathsigning or wallet pathboot or update pathauthentication pathparser or protocol pathmerge-commit duplicate discount
AI analysis · Informational 15/100
This commit is a normal feature addition to a helper script in the Bitcoin Core repository. It lets users of the contrib/utxo_to_sqlite.py tool choose whether transaction IDs and script public keys are stored as hexadecimal text or as raw binary data in the resulting SQLite database. This is purely an optional convenience/efficiency improvement for an offline analysis tool and does not change Bitcoin Core's node, wallet, consensus, or network behavior.
Lower-priorityvalidation: Use dirty entry count in flush warnings and disk space checksby Pieter Wuille · afb1bc12 · Feb 8, 2026 · 3 filesMessage 73 · AdequateInformational 19Details
Commit message · Pieter Wuille
validation: Use dirty entry count in flush warnings and disk space checks
Changes flush warnings to use the actual number of dirty entries being written rather than total cache size or memory usage: * Moves warning from `FlushStateToDisk` to `CCoinsViewDB::BatchWrite` so it applies to both regular flushes and `AssumeUTXO` snapshot writes * Changes threshold from `WARN_FLUSH_COINS_SIZE` (1 GiB) to `WARN_FLUSH_COINS_COUNT` (10M entries), approximately equivalent - this also helps with the confusion caused by UTXO size difference on-disk vs in-memory * Moves benchmark logging to `BatchWrite` where the actual disk I/O occurs to make sure AssumeUTXO also warns * Uses dirty count for disk space check (48 bytes per entry estimate) * Removes redundant `changed` counter since `dirty_count` is now tracked
This ensures users are warned appropriately even when only a fraction of the cache is dirty, and provides accurate warnings during `AssumeUTXO` loads.
Co-authored-by: l0rinc <pap.lorinc@gmail.com>
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 19/100
This Bitcoin Core commit changes how the software warns users and checks disk space before writing the UTXO cache to disk. It now counts the actual number of changed (dirty) entries instead of the total cache memory size. This makes warnings more accurate, especially during special operations like AssumeUTXO snapshot loads, and prevents unnecessary disk-space checks based on unchanged cached data. There is no indication this fixes an exploitable vulnerability; it is a correctness and logging improvement.
Lower-prioritycoins: Keep track of number of dirty entries in `CCoinsViewCache`by Pieter Wuille · b413491a · Feb 8, 2026 · 4 filesMessage 100 · StrongInformational 18Details
Commit message · Pieter Wuille
coins: Keep track of number of dirty entries in `CCoinsViewCache`
Adds `m_dirty_count` member to track the running count of dirty cache entries as follows: * Incremented when entries are marked dirty via `CCoinsCacheEntry::SetDirty` * Decremented when dirty entries are removed or cleaned * Passed through `CoinsViewCacheCursor` and updated during iteration
The dirty count is needed because after non-wiping flushes (introduced in #28280 and #28233), the percentage of dirty entries in the cache may be far below 100%. Using total cache size for flush warnings and disk space checks is therefore misleading.
Updates all test code to properly initialize and maintain the dirty count.
Co-authored-by: l0rinc <pap.lorinc@gmail.com> Co-authored-by: Andrew Toth <andrewstoth@gmail.com> Co-authored-by: optout <13562139+optout21@users.noreply.github.com>
100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
AI analysis · Informational 18/100
This Bitcoin Core change adds an internal counter that tracks how many unspent-coin cache entries are 'dirty' (modified but not yet saved to disk). It is a correctness and accounting improvement, not a fix for an active security flaw. The change helps flush warnings and disk-space checks reflect reality after a recent feature that allows partial, non-wiping flushes. No exploit or vulnerability is described in the commit.
Lower-priorityfuzz: call `EmplaceCoinInternalDANGER` as well in `SimulationTest`by Lőrinc · 7e52b1b9 · Feb 8, 2026 · 1 fileMessage 83 · StrongInformational 13Details
Commit message · Lőrinc
fuzz: call `EmplaceCoinInternalDANGER` as well in `SimulationTest`
Adds test coverage by randomly calling `EmplaceCoinInternalDANGER` in `SimulationTest` to verify it remains correct as we modify it in a future commit.
Co-authored-by: Andrew Toth <andrewstoth@gmail.com>
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
fuzzing or regression evidence
AI analysis · Informational 13/100
This change only adds a new test path inside an existing fuzz test. It makes the test randomly call an internal helper named EmplaceCoinInternalDANGER instead of always using AddCoin. There is no change to production code, no bug fix, and no security-relevant behavior in the commit itself.
Lower-prioritytest: add a test for txgraph stagingby Hao Xu · fe0b1513 · Feb 7, 2026 · 1 fileMessage 82 · StrongInformational 15Details
Commit message · Hao Xu
test: add a test for txgraph staging
staging is a batching mechanism for txgraph, add a test for this feature.
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
AI analysis · Informational 15/100
This commit only adds a new unit test for an existing feature called 'txgraph staging' in Bitcoin Core. It does not change any production code, so it cannot introduce a security vulnerability or fix one. It is purely a test addition.
Add block builder tests to make sure chunks for a cluster are all right.
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
AI analysis · Informational 15/100
This commit only adds and updates unit tests for an internal transaction-graph data structure. It does not change any production code that runs on the Bitcoin network, so it cannot introduce a security vulnerability or be exploited by attackers.
Lower-prioritytest: add a chunk test for txgraphby Hao Xu · 4a1ac31e · Feb 7, 2026 · 1 fileMessage 90 · StrongInformational 15Details
Commit message · Hao Xu
test: add a chunk test for txgraph
Add a test for GetWorstMainChunk(), which picks the worst chunk from txgraph.
Co-developed-by: rkrux <rkrux.connect@gmail.com>
90/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 15/100
This commit only adds a new unit test for an existing internal function in Bitcoin Core's transaction graph code. It does not change any production code, so it cannot introduce a security vulnerability or fix one.
The -blockreservedweight startup option should only affect RPC code, because IPC clients (currently) do not have a way to signal their intent to use the node default (the BlockCreateOptions struct defaults merely document a recommendation for client software).
Before this commit however, if the user set -blockreservedweight then ApplyArgsManOptions would cause the block_reserved_weight option passed by IPC clients to be ignored. Users who don't set this value were not affected.
Fix this by making BlockCreateOptions::block_reserved_weight an std::optional.
Internal interface users, such as the RPC call sites, don't set a value so -blockreservedweight is used. Whereas IPC clients do set a value which is no longer ignored.
Test coverage is added.
mining_basic.py already ensured -blockreservedweight is enforced by mining RPC methods. This commit adds coverage for Mining interface IPC clients. It also verifies that -blockreservedweight has no effect on them.
Co-Authored-By: Russell Yanofsky <russ@yanofsky.org>
95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
AI analysis · Low 33/100
This commit fixes a bug where a command-line option meant only for RPC mining clients was accidentally also overriding settings for IPC (inter-process communication) mining clients. IPC clients now have their own reserved block weight respected, while RPC clients still follow the startup option. The change is a correctness fix in how mining block templates are built, not a remote exploit.
Previously a lower value was silently clamped to MINIMUM_BLOCK_RESERVED_WEIGHT.
60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
AI analysis · Low 30/100
This change makes Bitcoin Core's inter-process communication (IPC) mining interface reject block reserved weight values that are too small, instead of quietly raising them to the minimum. Previously, an external program using the IPC mining interface could request a very low reserved weight and unknowingly have it silently increased. Now it gets a clear error. This is a defensive consistency fix rather than an active exploit.
Refactor the mining_create_block_template and mining_wait_next_template helpers in ipc_util.py to return None if they time out or fail. It makes the test easier to read and provides a more clear error message in case of a regression.
There were a few spots that didn't use mining_wait_next_template yet, which now do.
90/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 15/100
This is a test-only code cleanup. It changes two helper functions used only in Bitcoin Core's automated functional tests so they return None when a mining template request times out or fails, instead of returning a raw response object. The test code is updated to check for None. There is no change to the actual Bitcoin node software that runs on the network, so this cannot affect real users, funds, or network security.
AI review queuedrefactor: interfaces, make 'createTransaction' less error-proneby furszy · 4c0d4f6f · Feb 6, 2026 · 3 filesMessage 85 · StrongInformational 19Details
Commit message · furszy
refactor: interfaces, make 'createTransaction' less error-prone
Bundle all function's outputs inside the util::Result returned object.
Reasons for the refactoring: - The 'change_pos' ref argument has been a source of bugs in the past. - The 'fee' ref argument is currently only set when the transaction creation process succeeds.
85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 19/100
This is a code cleanup change in Bitcoin Core. It bundles the outputs of the 'createTransaction' function into a single result object instead of using separate reference arguments. The commit message says this makes the function less error-prone because the old way of passing back 'change position' and 'fee' through reference arguments had caused bugs before. There is no direct evidence in the diff of a currently exploitable security vulnerability being fixed.
AI review queuedrefactor: move CreatedTransactionResult to types.hby furszy · e2c3ec9b · Feb 6, 2026 · 2 filesMessage 77 · AdequateInformational 15Details
Commit message · furszy
refactor: move CreatedTransactionResult to types.h
So it can be used by external modules without requiring wallet.h dependency.
77/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body
Why it was queued
signing or wallet pathsecond-pass: broader security terminologysecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit is a simple code reorganization: it moves a data structure called CreatedTransactionResult from one internal header file to another so other parts of the codebase can use it without pulling in the entire wallet header. There is no change to behavior, no bug fix, and no security-related content.
AI review queuedgui: remove AmountWithFeeExceedsBalance error special caseby furszy · 45372175 · Feb 6, 2026 · 3 filesMessage 73 · AdequateInformational 20Details
Commit message · furszy
gui: remove AmountWithFeeExceedsBalance error special case
Since bitcoin#34299, the wallet handles the error internally and retrieves the proper message.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 20/100
This commit removes a special error message in the Bitcoin Core graphical wallet that told users when their balance was too small to cover both the payment amount and the transaction fee. The wallet now lets an underlying internal function produce the error message instead. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a code cleanup and user-experience simplification.
Lower-prioritytest: Ensure invalid block was processed before checking debug.logby Ava Chow · b73a62f6 · Feb 6, 2026 · 1 fileMessage 100 · StrongInformational 15Details
Commit message · Ava Chow
test: Ensure invalid block was processed before checking debug.log
In feature_assumevalid.py, we check that a modified block 102 is invalid by asserting a message in the debug.log. However, this can intermittently fail as exiting the assert_debug_log can occur before the block has actually been validated, thus causing the test to fail as the validation error message is not present in the chunk of the debug.log being examined.
We can wait for the block to make an invalid chain tip to ensure that the log line will be present.
100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
defensive validation
AI analysis · Informational 15/100
This is a fix to a flaky automated test, not a security fix in the Bitcoin software itself. The test was sometimes checking the debug log too quickly, before the program had finished evaluating a deliberately-invalid block. The patch makes the test wait until the block is confirmed as invalid before checking the log. It does not change how Bitcoin validates blocks or affect real users.
Lower-prioritytest: split interface_ipc_mining.py into subtestsby Sjors Provoost · 52ccd921 · Feb 6, 2026 · 1 fileMessage 90 · StrongInformational 15Details
Commit message · Sjors Provoost
test: split interface_ipc_mining.py into subtests
Split the Mining interface test into focused subtests.
Keep the initial tip-change pre-mine check in run_mining_interface_test. As a result run_block_template_test no longer has newblockref.
90/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 15/100
This commit is a routine cleanup of a Bitcoin Core functional test file. It splits one large test function into three smaller, focused subtests and moves shared setup code into a helper method. There are no changes to production code, no bug fixes, and no security-related content.
