BC
← All projectsBitcoin Core

Bitcoin Core

The Bitcoin network's reference node and wallet implementation.

BitcoinSupply chainNormal
Repository coverage

2900 commits in the local evidence base

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.

254security candidates607second-pass queue2881AI analyses
206commits · 30 days
502commits · 60 days
1535commits · 180 days
2884commits · 365 days
Backfill bands
Aug 5 → Feb 61351 seen45 candidatesComplete
Feb 6 → Jun 61033 seen63 candidatesComplete
Jun 6 → Jul 6281 seen11 candidatesComplete
Jul 6 → Aug 5207 seen5 candidatesComplete
Commit communication

Does the history explain itself?

Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.

70/100 average clarity
937Strong · 80–100
1188Adequate · 60–79
687Thin · 40–59
88Opaque · 0–39
6security candidates with opaque commit messaging
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
Antoine Poinsot22422170
Ava Chow15750157064
MarcoFalke41021406074
Lőrinc17721177081
fanquake22719226057
Hennadii Stepanov20914208063
rkrux57957074
Sjors Provoost89889074
Sebastian Falbesoner33733073
David Gumberg55655072
Pieter Wuille95595066
Hodlinator66566076
Analysis record

Published AI watches

Last scanned 18 minutes ago

Informational 15 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35928: doc: mention -DWITH_ZMQ=ON in macOS build guide

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.

8397e09eby merge-script+1−11 file
No security note in commit
Informational 15 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35482: fuzz: exercise the transaction-handling path in process_message(s)

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
f11dc617by merge-script+105−798 files
No security note in commit
Informational 15 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35914: test, fuzz: Remove unused variables

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.

d36bf709by merge-script+1−138 files
No security note in commit
Informational 15 AI analysisMessage 93 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35896: refactor: Default uint256::operator==, add operator<=>

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…

ed2c59abby merge-script+99−245 files
No security note in commit
Moderate 62 AI analysisMessage 96 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35872: rpc: avoid descriptor range counter overflow

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)
b388674aby Ava Chow+3−12 files
Vendor flagged security relevance
Informational 19 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35842: rpc: Properly make RPCResult::Type::ANY non-test-only

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
c36ffd87by merge-script+42−364 files
No security note in commit
Informational 15 AI analysisMessage 93 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35895: refactor: Enable clang-tidy rule to reject anon namespace in header

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)
c4fbd3c7by merge-script+9−123 files
No security note in commit
Informational 15 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35630: test: Add importdescriptors rpc error test coverage

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…

465196d0by merge-script+77−11 file
No security note in commit
Informational 15 AI analysisMessage 81 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35180: coins: group private cache helpers

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…

c940fd75by merge-script+13−141 file
No security note in commit
Low 29 AI analysisMessage 81 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35582: rpc: reject null for optional parameters

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
3db96eb5by merge-script+18−75 files
No security note in commit
Informational 15 AI analysisMessage 57 · Thin
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

refactor: Enable misc-definitions-in-headers

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…

fa93132dby MarcoFalke+3−02 files
No security note in commit
Informational 15 AI analysisMessage 85 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

refactor: Enable clang-tidy rule to reject anon namespace in header

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.
fa5ca877by MarcoFalke+2−11 file
No security note in commit
Informational 15 AI analysisMessage 62 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

refactor: Use C++20 std::identity over IntIdentity

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…

fafe5042by MarcoFalke+4−111 file
No security note in commit
Informational 15 AI analysisMessage 87 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: test the result order of a multiple import request is correct

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…

3ac8b806by Pol Espinasa+40−01 file
No security note in commit
Informational 15 AI analysisMessage 87 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: test invalid or missing timestamp throws importdescriptors

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
e4732bf0by Pol Espinasa+28−11 file
No security note in commit
Informational 15 AI analysisMessage 80 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

refactor: Remove unused #include in common/system

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.

fa7304f3by MarcoFalke+1−22 files
No security note in commit
Informational 15 AI analysisMessage 50 · Thin
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

iwyu: Fix warnings in `src/consensus` and treat them as errors

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.…

13b53f8bby Hennadii Stepanov+42−79 files
No security note in commit
Informational 15 AI analysisMessage 55 · Thin
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

fuzz: don't connman.ReceiveMsgFrom oversized msg

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
bb19f1daby Greg Sanders+5−01 file
No security note in commit
Informational 15 AI analysisMessage 97 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

ci: Temporarily remove riscv32 config from GHA matrix

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.

fa06ea42by MarcoFalke+0−61 file
No security note in commit
Low 47 AI analysisMessage 90 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

ci: verify cross-build SDK archives

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
873550beby Lőrinc+25−126 files
Vendor flagged security relevance
Repository ledger

Explore captured commits

Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.

AI review queuedclusterlin: rescale costs (preparation)by Pieter Wuille · 4eefdfc5 · Feb 24, 2026 · 4 filesMessage 35 · OpaqueInformational 15Details
Commit message · Pieter Wuille

clusterlin: rescale costs (preparation)

35/100 · OpaqueMessage clarity
✓ Descriptive subject! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI analysis · Informational 15/100

This commit is a non-security internal tuning change for Bitcoin Core's transaction mempool linearization logic. It multiplies several cost constants by 38 to prepare for future algorithm changes, and updates corresponding test/fuzz thresholds. There is no bug fix, no vulnerability, and no user-facing behavior change beyond slightly different internal cost budgets.

Lower-priorityinit refactor: Only initialize node.notifications one timeby Ryan Ofsky · a7cabf92 · Feb 24, 2026 · 3 filesMessage 73 · AdequateInformational 24Details
Commit message · Ryan Ofsky

init refactor: Only initialize node.notifications one time

Instead of having the InitAndLoadChainstate function delete and create the
KernelNotifications object each time it is called (it can be called twice when
reindexing) to clear cached state, create it just one time and add a
setChainstateLoaded() method to manage state as it is loaded and unloaded.

This refactoring should make sense by itself to be more explicit about how
KernelNotifications state is cleared, but it's also needed to make outside code
accessing KernelNotifications state (currently just mining code) safe during
node startup and shutdown so the KernelNofications mutex can be used for
synchronization and does not get recreated itself.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 24/100

This is a code cleanup in Bitcoin Core's startup sequence. It changes how an internal notification object is created so it is only created once instead of being deleted and recreated during startup. The commit message says this is needed so that other parts of the program (like mining code) can safely read this object's state while the node is starting up or shutting down, because the object's mutex would otherwise be destroyed and recreated, which could cause crashes or race conditions. There is no direct evidence in the diff of an exploitable security bug.

Lower-priorityipc mining: Prevent ``Assertion `m_node.chainman' failed`` errors on early startupby Ryan Ofsky · bbc8f1e0 · Feb 24, 2026 · 6 filesMessage 81 · StrongModerate 57Details
Commit message · Ryan Ofsky

ipc mining: Prevent ``Assertion `m_node.chainman' failed`` errors on early startup

This fixes ``Assertion `m_node.chainman' failed`` errors first reported
https://github.com/bitcoin/bitcoin/issues/33994#issuecomment-3602551596 when
IPC mining methods are called before ChainstateManager is loaded.

The fix works by making the `Init.makeMining` method block until chainstate
data is loaded.

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
AI analysis · Moderate 57/100

This commit fixes a crash in Bitcoin Core that could happen when external programs talk to the node over the IPC mining interface while the node is still starting up. Before the fix, calling mining methods too early could trigger an internal assertion failure and crash the node. The fix makes external mining clients wait until the node's chain data is fully loaded before they can proceed.

Lower-priorityclusterlin: use 'cost' terminology instead of 'iters' (refactor)by Pieter Wuille · ecc9a84f · Feb 24, 2026 · 12 filesMessage 50 · ThinInformational 15Details
Commit message · Pieter Wuille

clusterlin: use 'cost' terminology instead of 'iters' (refactor)

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Informational 15/100

This commit is a pure rename/refactor. It changes variable names, comments, and constant names from 'iterations'/'iters' to 'cost' throughout the cluster linearization and transaction graph code. No logic, behavior, or security properties are altered.

Lower-priorityclusterlin: introduce CostModel class (preparation)by Pieter Wuille · 9e7129df · Feb 24, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Pieter Wuille

clusterlin: introduce CostModel class (preparation)

This parametrizes the cost model for the SFL algorithm with another
class. Right now, the behavior of that class matches the naive cost
model so far, but it will be replaced with a more advanced on in a
future commit.

The reason for abstracting this out is that it makes benchmarking for
creating such cost models easy, by instantiating the cost model class
with one that tracks time.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100

This commit is a pure internal refactoring of Bitcoin Core's transaction linearization code. It replaces a simple numeric cost counter with a pluggable 'CostModel' class so future work can experiment with different ways of measuring algorithmic work. The default cost model behaves exactly like the old code. There is no user-facing change, no network change, and no security-relevant behavior change.

Lower-prioritytest: index, improve txospenderindex_initial_sync() test codeby furszy · e8f8b74a · Feb 24, 2026 · 1 fileMessage 95 · StrongInformational 15Details
Commit message · furszy

test: index, improve txospenderindex_initial_sync() test code

The index is now initialized after the setup phase (chain generation
and txs creation), since it doesn't participate on it at all.
This improves readability and splits setup from what we actually
want to check.

This also adds a check after Sync() to verify the index best block hash
matches the tip, so we know it fully synced before checking the
processed data. This will help catching errors as Sync() could have
aborted prematurely.

As a happy side effect, the SyncWithValidationInterfaceQueue() call at
the end of the test is no longer needed and has been removed.

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
AI analysis · Informational 15/100

This is a routine improvement to a Bitcoin Core unit test. It reorganizes when an index is started during the test and adds an extra check that the index fully catches up to the latest block. There is no change to production code, no security fix, and no vulnerability.

Lower-priorityinit refactor: Remove node.init accesss in AppInitInterfacesby Ryan Ofsky · c8e332cb · Feb 24, 2026 · 1 fileMessage 85 · StrongInformational 15Details
Commit message · Ryan Ofsky

init refactor: Remove node.init accesss in AppInitInterfaces

There's no change in behavior. This is just a refactoring to avoid a minor
layer violation in init code. The node.init object is intended to return
interface pointers for code outside the node (like wallet and gui code), not
used by node itself to initialize its internal state.

(Motivation for this change is to introduce a MakeMining wait_loaded option in
an upcoming commit that can only be used internally and not set by external
clients.)

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 15/100

This is a small internal code cleanup in Bitcoin Core's startup code. It changes how two internal interfaces (chain and mining) are created, using direct function calls instead of going through an intermediate 'init' object. The commit message explicitly states there is no change in behavior, and the diff shows only two lines changed in a straightforward way. There is no security issue visible here.

Lower-prioritytest: valgrind --trace-children=yes for bitcoin wrapperby MarcoFalke · fa5d4788 · Feb 24, 2026 · 2 filesMessage 72 · AdequateInformational 15Details
Commit message · MarcoFalke

test: valgrind --trace-children=yes for bitcoin wrapper

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
AI analysis · Informational 15/100

This commit changes the Bitcoin Core test framework so that when tests are run with the optional --valgrind flag, Valgrind now follows child processes spawned by the main 'bitcoin' wrapper executable. Previously, Valgrind only watched the wrapper itself and could miss memory errors in the actual node processes it launched. This is a testing/quality improvement, not a fix for a user-facing security bug.

Lower-prioritytest: Remove redundant warning about missing binariesby MarcoFalke · fa29fb72 · Feb 24, 2026 · 1 fileMessage 100 · StrongInformational 15Details
Commit message · MarcoFalke

test: Remove redundant warning about missing binaries

The error was added in commit 1ea7e45a1f445d32a2b690d52befb2e63418653b,
because there was an additional confusing `AssertionError: [node 0]
Error: no RPC connection` instead of just a single `FileNotFoundError:
[Errno 2] No such file or directory`.

This is no longer needed on current master.

Also, the test is incomplete, because it was just checking bitcoind and
bitcoin-cli, not any other missing binaries.

Also, after the previous commit, it would not work in combination with
--valgrind.

Instead of trying to make it complete, and work in all combinations,
just remove it, because the already existing error will be clear in any
case.

This can be tested via:

```sh
./test/get_previous_releases.py

mv releases releases_backup
# Confirm the test is skipped due to missing releases
./bld-cmake/test/functional/wallet_migration.py
# Confirm the test fails due to missing releases
./bld-cmake/test/functional/wallet_migration.py --previous-releases
mv releases_backup releases

mv ./releases/v28.2 ./releases/v28.2_backup
# Confirm the test fails with a single FileNotFoundError
./bld-cmake/test/functional/wallet_migration.py
mv ./releases/v28.2_backup ./releases/v28.2
# Confirm the test runs and passes
./bld-cmake/test/functional/wallet_migration.py

rm ./bld-cmake/bin/bitcoind
# Confirm the test fails with a single "No such file or directory",
# testing with and without --valgrind
./bld-cmake/test/functional/wallet_migration.py
./bld-cmake/test/functional/wallet_migration.py --valgrind
```

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
AI analysis · Informational 15/100

This commit removes a redundant warning in Bitcoin Core's test framework. It does not change production code, network behavior, or wallet security. The change only affects how functional tests report missing test binaries, and the commit message explicitly says the removed check is no longer needed because the underlying error message is now clear enough on its own.

Lower-prioritytest: Fix broken --valgrind handling after bitcoin wrapperby MarcoFalke · fa03fbf7 · Feb 24, 2026 · 4 filesMessage 100 · StrongInformational 15Details
Commit message · MarcoFalke

test: Fix broken --valgrind handling after bitcoin wrapper

Prior to this commit, tool_bitcoin.py was failing:

```sh
$ ./bld-cmake/test/functional/tool_bitcoin.py --valgrind
TestFramework (ERROR): Unexpected exception
Traceback (most recent call last):
File "./test/functional/test_framework/test_framework.py", line 138, in main
self.setup()
~~~~~~~~~~^^
File "./test/functional/test_framework/test_framework.py", line 269, in setup
self.setup_network()
~~~~~~~~~~~~~~~~~~^^
File "./test/functional/tool_bitcoin.py", line 38, in setup_network
assert all(node.args[:len(node_argv)] == node_argv for node in self.nodes)
~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
```

This commit fixes this issue by running `bitcoin` under valgrind. Also,
it comes with other improvements:

* Drop the outdated valgrind 3.14 requirement, because there is no
distro that ships a version that old anymore.
* Drop the VALGRIND_SUPPRESSIONS_FILE env var handling, because it was
presumably never used since it was introduced. Also, the use-case
seems limited.

Review note:

The set_cmd_args was ignoring the --valgrind test option.

In theory, this could be fixed by refactoring Binaries::node_argv() to
be used here. However, for now, just re-implement the node_argv logic in
set_cmd_args to prepend the valgrind cmd.

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
AI analysis · Informational 15/100

This is a test-only bug fix. The --valgrind option used in Bitcoin Core's functional tests had stopped working after a previous change introduced a 'bitcoin' wrapper executable. The patch moves valgrind handling into the test framework's binary helper so the wrapper is launched under valgrind, and it removes an outdated minimum valgrind version and an unused environment variable. There is no change to production Bitcoin node code, no user-facing behavior change, and no security vulnerability in the network software itself.

Lower-priorityci: use LLVM 22 in sanitizer tasksby fanquake · a28eedb8 · Feb 24, 2026 · 6 filesMessage 57 · ThinInformational 15Details
Commit message · fanquake

ci: use LLVM 22 in sanitizer tasks

57/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
defensive validation
AI analysis · Informational 15/100

This commit is a routine update to Bitcoin Core's continuous integration (CI) configuration. It changes the version of the LLVM compiler toolchain used in automated testing jobs that run sanitizers (tools that detect bugs during testing) from version 21 to version 22. There is no change to the Bitcoin Core software that users run, no fix for a security flaw, and no known security relevance.

Lower-priorityfuzz: prevent invalid `FRESH` entries and surface `BatchWrite` errorsby Lőrinc · 3281824e · Feb 23, 2026 · 1 fileMessage 95 · StrongInformational 17Details
Commit message · Lőrinc

fuzz: prevent invalid `FRESH` entries and surface `BatchWrite` errors

Modify fuzzer logic to avoid setting `FRESH` for an outpoint that already exists unspent in the parent view, and ensure `FRESH` implies `DIRTY`.
This keeps cursor invariants realistic and lets `BatchWrite` failures expose real bugs without resetting state.

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
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 17/100

This change only touches a fuzz test file, not the main Bitcoin Core wallet or consensus code. It removes a workaround that previously swallowed a specific logic error during fuzz testing and instead makes the fuzzer avoid creating the invalid condition in the first place. There is no indication this fixes a real-world vulnerability in production software.

Lower-priorityfuzz: avoid invalid `AddCoin` overwritesby Lőrinc · 780f4606 · Feb 23, 2026 · 1 fileMessage 78 · AdequateInformational 16Details
Commit message · Lőrinc

fuzz: avoid invalid `AddCoin` overwrites

The coins view fuzzer can call `AddCoin` with `possible_overwrite=false` for an outpoint that already exists unspent in the view, which violates the `AddCoin` caller contract.
Derive `possible_overwrite` from `PeekCoin` so `possible_overwrite=false` is only used when the outpoint is absent.
This matches the approach used by the `coinscache_sim` fuzzer, which derives the overwrite flag from simulated state.

78/100 · AdequateMessage clarity
✓ 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 16/100

This commit fixes a fuzz test (an automated random-input testing harness) so it no longer violates an internal rule of the coin cache. It does not change production Bitcoin node code, so it cannot directly affect real users or the network. The change makes the test harness follow the same contract as real callers of AddCoin.

Lower-priorityfuzz: make `AddCoins` query view for overwritesby Lőrinc · d7e0d510 · Feb 23, 2026 · 1 fileMessage 90 · StrongInformational 17Details
Commit message · Lőrinc

fuzz: make `AddCoins` query view for overwrites

In validation, `AddCoins(check_for_overwrite=false)` is only used after BIP30 has already ensured the transaction does not overwrite any unspent outputs in the UTXO view.
The coins view fuzz target can call `AddCoins` with arbitrary txids, so using the `check_for_overwrite=false` fast path on non-coinbase transactions may violate the `AddCoin` caller contract and trigger logic errors.
Only use `check_for_overwrite=false` when we have first confirmed that none of the outputs are currently unspent.
Otherwise, fall back to `check_for_overwrite=true` so `AddCoins` determines overwrites via the view.

90/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 17/100

This is a fix inside a Bitcoin Core fuzz test, not in the live network code. The fuzz test randomly feeds data into coin-handling functions to find crashes. Previously, the test could call AddCoins in a way that breaks an internal rule (overwriting an unspent coin while telling the function not to check for overwrites), causing assertion failures or logic errors. The patch makes the fuzz test check the coin view first, so it only uses the fast 'no overwrite check' path when it is actually safe. It does not change how real Bitcoin nodes validate transactions.

Lower-priorityutil: introduce `TrySub` to prevent unsigned underflowby Lőrinc · b8fa6f0f · Feb 23, 2026 · 3 filesMessage 85 · StrongLow 44Details
Commit message · Lőrinc

util: introduce `TrySub` to prevent unsigned underflow

Introduce `TrySub(T&, U)` which subtracts an unsigned integral `U` from an unsigned integral `T`, returning `false` on underflow.
Use with `Assume(TrySub(...))` at coins cache accounting decrement sites so invariant violations fail immediately rather than silently wrapping.

Co-authored-by: MarcoFalke <*~=`'#}+{/-|&$^_@721217.xyz>
Co-authored-by: Pieter Wuille <pieter@wuille.net>

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI analysis · Low 44/100

This change adds a safety check to subtraction operations in Bitcoin Core's coin-cache accounting. Previously, certain internal counters could silently wrap around to huge values if a bug caused them to be decremented more than they were incremented. Now the program will detect that impossible condition and abort, turning a silent accounting corruption into a visible failure. The patch is defensive hardening; it does not by itself prove an attacker can trigger the underflow.

Lower-prioritytest: improve rpc_gettxspendingprevout.py codeby furszy · ac3bea07 · Feb 23, 2026 · 1 fileMessage 90 · StrongInformational 15Details
Commit message · furszy

test: improve rpc_gettxspendingprevout.py code

Grouped changes to improve the overall readability and maintainability of the test.
A lot more can be done, but this is a good first step.

1) Use for-loops instead of duplicating lines to perform the same checks for each
node.

2) The {'txid': x, 'vout': y} dict is repeated everywhere in the test, both as
input to gettxspendingprevout and as part of its result when an output has no
known spender, making the test tedious to read and maintain.

This introduces a prevout(txid, vout) query helper and an unspent_out(txid, vout)
result helper to reduce the repetition. These two helpers are intentionally kept
separate to make it immediately clear whether a dict is an input to
gettxspendingprevout or an assertion on its result.

3) The same repetition problem mentioned above applies to other gettxspendingprevout
possible results:
Spent outputs returns {'txid': x, 'vout': y, 'spendingtxid': z} and
Spent outputs when requesting spending tx returns {'txid': x, 'vout': y,
'spendingtxid': z, 'blockhash': w, 'spendingtx': v}

To fix it, this introduces:
- spent_out(txid, vout, spending_tx_id): for outputs with a known spender
- spent_out_in_block(txid, vout, spending_tx_id, blockhash, spending_tx): for
outputs spent in a confirmed block, when full tx data is requested

4) Rename overloaded confirmed_utxo variable (used in three different tests) to more
descriptive names: root_utxo, reorg_replace_utxo, reorg_cancel_utxo to clarify
their roles in each of the tests.

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 pure test-code cleanup. It rewrites a single functional test file to use helper functions and for-loops instead of repeating dictionary literals. There is no change to Bitcoin Core's production code, consensus rules, network protocol, wallet logic, or RPC behavior. It cannot affect live nodes, funds, or security.

Lower-prioritytest: use port 0 for I2P addresses in p2p_private_broadcast.pyby Vasil Dimov · da7f70a5 · Feb 23, 2026 · 1 fileMessage 100 · StrongInformational 15Details
Commit message · Vasil Dimov

test: use port 0 for I2P addresses in p2p_private_broadcast.py

I2P addresses must use port=0, otherwise `bitcoind` refuses to connect.

The test `p2p_private_broadcast.py` cannot simulate connections to I2P
peers, so the I2P proxy is set to a dummy `127.0.0.1:1`. Still it is
good to pick I2P addresses and attempt connections to increase coverage.

However the test uses port=8333 for I2P addresses and thus the
connection attempts fail for the "wrong" reason:

```
Error connecting to ...i2p:8333, connection refused due to arbitrary port 8333
```

Using the proper port=0 makes the failures:

```
Error connecting to ...i2p:0: Cannot connect to 127.0.0.1:1
```

which will make possible simulated I2P connections once we have a test
I2P proxy.

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
AI analysis · Informational 15/100

This is a minor fix to a Bitcoin Core test script. It changes the network port number used for I2P test addresses from 8333 to 0, because Bitcoin Core requires I2P addresses to use port 0. The change only affects an automated functional test and does not change production code, so it has no direct security impact on real Bitcoin nodes or users.

Lower-prioritytest: let connections happen in any order in p2p_private_broadcast.pyby Vasil Dimov · a8ebcfd3 · Feb 23, 2026 · 1 fileMessage 100 · StrongInformational 15Details
Commit message · Vasil Dimov

test: let connections happen in any order in p2p_private_broadcast.py

If the following two events happen:

* (likely) the automatic 10 initial connections are not made to all
networks
* (unlikely) the network-specific logic kicks in almost immediately.
It is using exponential distribution with a mean of 5 minutes
(`rng.rand_exp_duration(EXTRA_NETWORK_PEER_INTERVAL)`).

So if both happen, then the 11th connection may not be the expected
private broadcast, but a network-specific connection.

Fix this by retrieving the connection type from
`destinations_factory()`. This is more flexible because it allows
connections to happen in any order and does not break if e.g. the 11th
connection is not the expected first private broadcast.

This also makes the test run faster:
before: 19-44 sec
now: 10-25 sec
because for example there is no need to wait for the initial 10
automatic outbound connections to be made in order to proceed.

Fixes: https://github.com/bitcoin/bitcoin/issues/34387

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✓ Links an issue, advisory, or supporting reference
AI analysis · Informational 15/100

This commit fixes a flaky automated test in Bitcoin Core. It does not change any production code, network protocol, or wallet behavior. The test previously assumed the 11th outbound connection would always be a private broadcast, which could fail under rare timing conditions. The fix reads the actual connection type from the node's debug log and routes test mock peers accordingly. It also makes the test faster by removing a hard wait for 10 initial connections.

Lower-prioritydoc: clarify `git range-diff` add/delete outputby Lőrinc · 45133c58 · Feb 23, 2026 · 1 fileMessage 98 · StrongInformational 15Details
Commit message · Lőrinc

doc: clarify `git range-diff` add/delete output

When `git range-diff` cannot match a commit between two versions of a branch, it shows the old commit as removed (`<`) and the new commit as added (`>`), and it does not show the patch contents.
This output is easy to misread as "no code changes" because the diff for that commit is effectively empty.
It really means the commits were considered unrelated and the new commit should be reviewed from scratch.
This is analogous to rename detection in `git diff`: if similarity is too low, a rename shows up as delete+add.

Example (exact SHAs from PR #34320):
B=ff338fdb53a66ab40a36e1277e7371941fc89840; A=dd76338a57b9b1169ac27f7b783d6d0d4c6e38ab; git fetch upstream $B $A
git range-diff 0ca4295f2e5f4443a1f8b3bae7cba0f6c054276f..$B 139aa4b27e4839291c83a04dcd1649c5595814ca..$A

This produced output like:
1: 4b32181dbb < -: ---------- test: add `HaveInputs` call-path unit tests
-: ---------- > 1: 277c57f0c5 test: add `HaveInputs` call-path unit tests

Even though the subject matches, the first commit had no matching diff shown.
That should be treated as "unmatched" rather than "unchanged".

If you expected a match, try increasing the creation factor so `git range-diff` searches harder:
git range-diff --creation-factor=95 <old_range> <new_range>

98/100 · StrongMessage clarity
✓ 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
documentation-only discount
AI analysis · Informational 15/100

This commit only updates developer documentation (doc/productivity.md) to explain how to correctly read `git range-diff` output. It contains no code changes, no configuration changes, and no security-relevant behavior. It is purely a documentation clarification about a Git tool used during code review.

Lower-prioritynet processing: Check if we are in ibd before processing block for txdownloadmanby sedited · e5f06135 · Feb 22, 2026 · 2 filesMessage 83 · StrongInformational 21Details
Commit message · sedited

net processing: Check if we are in ibd before processing block for txdownloadman

This avoids wasting work on calculating bloom filters that aren't
consumed during ibd and continuously re-calculated as now blocks get
validated.

Also update the functional test to document that transactions would now
be requested again once out of IBD.

Co-authored-by: Lőrinc <pap.lorinc@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
defensive validation
AI analysis · Informational 21/100

This commit is a performance optimization, not a security fix. It stops Bitcoin nodes from building unnecessary 'bloom filters' (a data structure used to track recently confirmed transactions) while they are still downloading the historical blockchain (IBD). Previously, the node wasted CPU recalculating these filters for old blocks even though it wasn't accepting new transactions from peers yet. The functional test was updated to reflect that transactions confirmed during IBD will now be requested again once the node is fully synced, because those filters were not built during IBD.

Lower-priorityAdd functional test exercising tx downloadman recently confirmed filterby Lőrinc · ce8b6928 · Feb 22, 2026 · 1 fileMessage 83 · StrongInformational 12Details
Commit message · Lőrinc

Add functional test exercising tx downloadman recently confirmed filter

This documents existing behaviour before the change in the following
commit: The bloom filter maintained by the txdownload manager tracks
recently confirmed transasctions even during ibd. If a peer sends an INV
once IBD is over it does not re-request them.

Co-authored-by: sedited <seb.kung@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 12/100

This commit only adds a new automated test to Bitcoin Core. It does not change any production code. The test documents that transactions confirmed during initial block download (IBD) are remembered and not re-requested from peers once IBD finishes. There is no security fix or vulnerability here.

Lower-prioritytest: don't always assert NUM_PRIVATE_BROADCAST_PER_TX broadcastsby Vasil Dimov · c462e54f · Feb 21, 2026 · 1 fileMessage 100 · StrongInformational 15Details
Commit message · Vasil Dimov

test: don't always assert NUM_PRIVATE_BROADCAST_PER_TX broadcasts

In `p2p_private_broadcast.py` in the function `check_broadcasts()` we
should assert that the broadcast was done to `broadcasts_to_expect`
peers, not to `NUM_PRIVATE_BROADCAST_PER_TX`. This is because in the
"Basic" test we check the first broadcast manually because it is done to
`nodes[1]` and then check the other two by
`check_broadcasts(..., NUM_PRIVATE_BROADCAST_PER_TX - 1, ...)`.
The first broadcast might not have fully concluded by the time we call
`check_broadcasts()` to check the remaining 2.

Demanding always `NUM_PRIVATE_BROADCAST_PER_TX` can lead to:

```
Traceback (most recent call last):
File "/home/vd/gh/bitcoin/bitcoin/test/functional/test_framework/test_framework.py", line 142, in main
self.run_test()
~~~~~~~~~~~~~^^
File "/tmp/build/clang22/test/functional/p2p_private_broadcast.py", line 347, in run_test
self.check_broadcasts("Basic", txs[0], NUM_PRIVATE_BROADCAST_PER_TX - 1, NUM_INITIAL_CONNECTIONS + 1)
~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/tmp/build/clang22/test/functional/p2p_private_broadcast.py", line 313, in check_broadcasts
assert_greater_than_or_equal(sum(1 for p in peers if "received" in p), NUM_PRIVATE_BROADCAST_PER_TX)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/vd/gh/bitcoin/bitcoin/test/functional/test_framework/util.py", line 94, in assert_greater_than_or_equal
raise AssertionError("%s < %s" % (str(thing1), str(thing2)))
AssertionError: 2 < 3
```

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
AI analysis · Informational 15/100

This is a one-line fix in a Bitcoin Core test script. It changes a test assertion to check the correct expected number of peer broadcasts, preventing a flaky test failure. It does not change any production code or network behavior, so it has no security impact on users.

Lower-prioritytest: move abortprivatebroadcast test at the endby Vasil Dimov · 37105663 · Feb 21, 2026 · 1 fileMessage 90 · StrongInformational 15Details
Commit message · Vasil Dimov

test: move abortprivatebroadcast test at the end

The piece of `p2p_private_broadcast.py` which tests the correctness of
`abortprivatebroadcast` issues a new `sendrawtransaction` call. That
call schedules up to 3 new connections: peer=13, peer=14 and possibly
peer=15 before it gets aborted.

These up to 3 in-the-process-of-opening private broadcast connections
have `CNode::m_connected` set early - when the `CNode` object is
created. Later in the test the mock time is advanced by 20 minutes and
those "old" connections pick a transaction for rebroadcast but that
triggers `PRIVATE_BROADCAST_MAX_CONNECTION_LIFETIME` immediately:

```
2026-02-21T13:28:14.209766Z [privbcast] [net.cpp:4006] [CNode] [net] Added connection peer=20
2026-02-21T13:28:14.309792Z (mocktime: 2026-02-21T13:48:14Z) [msghand] [net.cpp:4074] [PushMessage] [net] sending inv (37 bytes) peer=20
2026-02-21T13:28:14.309801Z (mocktime: 2026-02-21T13:48:14Z) [msghand] [net_processing.cpp:5745] [SendMessages] [privatebroadcast] Disconnecting: did not complete the transaction send within 180 seconds, peer=20
```

This prematurely stops the private broadcast connection and results in
a failure like:

```
AssertionError: ... not({} == {'ping': 1, 'tx': 1})
```

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 moves two test blocks to the end of a single functional test file. It fixes a flaky test failure caused by mock time advancing and prematurely disconnecting private broadcast connections. There is no change to production code, no security fix, and no vulnerability.

Lower-prioritycmake: Provide `install_name_tool` stub instead of disabling itby Hennadii Stepanov · 38a7a671 · Feb 21, 2026 · 1 fileMessage 85 · StrongInformational 15Details
Commit message · Hennadii Stepanov

cmake: Provide `install_name_tool` stub instead of disabling it

When running `enable_language()`, CMake checks the platform-specific
toolchain components, which includes `install_name_tool` for macOS.
We disable this check when cross-compiling on Linux because
`install_name_tool` is not used and our toolchain file does not provide
it.

However, the current workaround has been breaking CMake's assumptions
since commit eb8facd39606e9472f9ff6de40d7caf76767d0da (CMake 4.1.0,
backported to 4.0.5), which causes an error during configuration using
the Ninja generator.

This change fixes this behaviour by providing a stub executable instead
of `install_name_tool`, as we currently do in the depends build
subsystem.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
documentation-only discount
AI analysis · Informational 15/100

This is a build-system fix for Bitcoin Core's CMake configuration when cross-compiling macOS binaries from Linux. It replaces a workaround that disabled a CMake tool check with a harmless stub command, restoring compatibility with newer CMake versions. There is no security issue in the change itself.

Lower-prioritymining: add interrupt()by Sjors Provoost · 1e82fa49 · Feb 20, 2026 · 6 filesMessage 59 · ThinInformational 19Details
Commit message · Sjors Provoost

mining: add interrupt()

Both waitTipChanged() and createNewBlock() can take a long time to
return. Add a way for clients to interrupt them.

The new m_interrupt_mining is safely accessed with a lock on
m_tip_block_mutex, but it has no guard annotation. A more thorough
solution is discussed here:
https://github.com/bitcoin/bitcoin/pull/34184#discussion_r2743566474

59/100 · ThinMessage clarity
✓ Subject identifies a change✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
AI analysis · Informational 19/100

This commit adds a new 'interrupt()' button to Bitcoin Core's mining interface so outside callers can stop two long-running mining operations (waiting for a new chain tip and creating a new block) instead of waiting for them to finish on their own. It is a feature/refactoring change, not a fix for an active security bug. The only security-relevant note is that the new interrupt flag is accessed under a lock but is not formally marked as guarded by that lock, which the commit message itself flags as a known imperfection.