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
Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
Lower-prioritytxgraph: update chunk index on Compact (preparation)by Pieter Wuille · 7427c7d0 · Feb 9, 2026 · 1 fileMessage 73 · AdequateInformational 16Details
Commit message · Pieter Wuille
txgraph: update chunk index on Compact (preparation)
This makes TxGraphImpl::Compact() invoke Cluster::Updated() on all affected clusters, in case they have internal GraphIndex values stored that may have become outdated with the renumbering of GraphIndex values that Compact() caused.
No such GraphIndex values are currently stored, but this will change in a future commit.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 16/100
This is a small internal preparation change in Bitcoin Core's new transaction-graph code. It makes the index-compaction routine notify affected transaction clusters after graph indexes are swapped, so that future code can safely store extra index-based data. The commit itself does not introduce or fix any currently reachable bug; it only lays groundwork and adds defensive consistency checks.
Lower-prioritytxgraph: clear cluster's chunk index in ~Ref (preparation)by Pieter Wuille · 6c1bcb2c · Feb 9, 2026 · 1 fileMessage 85 · StrongInformational 18Details
Commit message · Pieter Wuille
txgraph: clear cluster's chunk index in ~Ref (preparation)
Whenever a TxGraph::Ref is destroyed, if it by then still appears inside main-level clusters, wipe the chunk index entries for those clusters, to prevent having lingering indexes for transactions without Ref.
This is preparation for enabling a callback being passed to MakeTxGraph to define a fallback order on objects. Once the Ref for a transaction is gone, it is not possible to invoke the callback anymore. To prevent the index becoming inconsistent, we need to immediately get rid of the index entries when the Ref disappears.
This is not a problem, because such destructions necessarily will trigger a relinearization of the cluster (assuming there are transactions in it left) before becoming acceptable again, and the chunk ordering is not observable (through CompareMainOrder, or through the BlockBuilder interface) until that point. However, the index itself needs to remain consistent in the mean time, even if not meaningful.
85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI analysis · Informational 18/100
This is a small internal cleanup in Bitcoin Core's new transaction graph code. It makes sure that when a transaction reference object is destroyed, any cached 'chunk index' bookkeeping for its cluster is wiped out. The commit message explicitly says this is preparation for a future feature and is not currently a problem, because the index is not observable by outside code until the cluster is reprocessed anyway. There is no direct evidence this fixes an exploitable security bug.
Lower-priorityclusterlin: sort tx in chunk by feerate and size (feature)by Pieter Wuille · e0bc73ba · Feb 9, 2026 · 2 filesMessage 78 · AdequateInformational 15Details
Commit message · Pieter Wuille
clusterlin: sort tx in chunk by feerate and size (feature)
This changes the order of transactions within a chunk to be: 1. Topology (parents before children) 2. Individual transaction feerate (high to low) 3. Individual transaction weight (small to large) 4. Random tiebreak (will be changed in a future commit)
To do so, use a heap of topology-ready transactions within GetLinearization(), sorted by (2), (3), and (4).
This is analogous to the order of chunks within a cluster, which is unchanged: 1. Topology (chunks after chunks they depend on) 2. Chunk feerate (high to low) 3. Chunk weight (small to large) 4. Random tiebreak (will be changed in a future commit)
78/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
AI analysis · Informational 15/100
This commit changes how Bitcoin Core orders transactions inside a 'chunk' during a process called cluster linearization. Previously, transactions within a chunk were picked in a random order; now they are sorted by fee rate (highest first) and then by size (smallest first), while still respecting parent-before-child dependencies. This is a deliberate feature change, not a security fix, and includes new fuzz tests to verify the ordering rules.
Lower-prioritytxgraph: use fallback order to sort chunks (feature)by Pieter Wuille · 6f113cb1 · Feb 9, 2026 · 3 filesMessage 73 · AdequateInformational 19Details
Commit message · Pieter Wuille
txgraph: use fallback order to sort chunks (feature)
This makes TxGraph also use the fallback order to decide the order of chunks from distinct clusters.
The order of chunks across clusters becomes: 1. Feerate (high to low) 2. Equal-feerate-chunk-prefix (small to large) 3. Max-txid (chunk with lowest maximum-txid first)
This makes the full TxGraph ordering fully deterministic as long as all clusters in it are optimally linearized.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 19/100
This commit changes how Bitcoin Core orders groups of related transactions (called 'chunks') in its internal transaction graph. It replaces a non-deterministic tie-breaker based on internal cluster sequence numbers with a deterministic one based on transaction IDs. The goal is to make the mempool ordering fully predictable, which helps with testing and may reduce subtle consensus or network behavior differences between nodes. There is no indication this fixes an active security vulnerability.
Lower-prioritytxgraph test: subclass TxGraph::Ref like mempool does (preparation)by Pieter Wuille · 941c432a · Feb 9, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Pieter Wuille
txgraph test: subclass TxGraph::Ref like mempool does (preparation)
This is a small change to the txgraph fuzz test to make it used objects derived from TxGraph::Ref (SimTxObject) rather than TxGraph::Ref directly. This matches how the mempool uses CTxMemPoolEntry, which derives from TxGraph::Ref.
This is preparation for a future commit which will introduce simulated txids to the transactions in this fuzz test, to be used as fallback order.
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 15/100
This commit only changes an internal fuzz test file. It replaces direct use of a base class (TxGraph::Ref) with a new empty subclass (SimTxObject) inside the test code, so the test structure better matches how the real mempool uses derived objects. There is no change to production code, network behavior, wallets, consensus, or any user-facing functionality.
AI review queuedtxgraph: pass fallback_order to TxGraph (preparation)by Pieter Wuille · fba004a3 · Feb 9, 2026 · 7 filesMessage 73 · AdequateInformational 15Details
Commit message · Pieter Wuille
txgraph: pass fallback_order to TxGraph (preparation)
This adds an std::function<strong_ordering(Ref&,Ref&)> argument to the MakeTxGraph function, which can be used by the caller (e.g., mempool code) to provide a fallback order to TxGraph.
This is just preparation; TxGraph does not yet use this fallback order for anything.
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 is a pure internal refactoring in Bitcoin Core. It adds a new optional tie-breaker function (called fallback_order) to the transaction graph (TxGraph) code, but explicitly does not use it yet. It is preparation for future work and does not change any network behavior, consensus rules, or security properties.
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.
