BC
← All projectsBitcoin Core

Bitcoin Core

The Bitcoin network's reference node and wallet implementation.

BitcoinSupply chainNormal
Repository coverage

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

252security candidates603second-pass queue1092AI analyses
208commits · 30 days
493commits · 60 days
1517commits · 180 days
2878commits · 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
917Strong · 80–100
1187Adequate · 60–79
686Thin · 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 Poinsot2248170
Ava Chow15649130064
MarcoFalke40721110074
Lőrinc1772183081
fanquake2271976057
Hennadii Stepanov2081455063
rkrux57944074
Sjors Provoost89825074
Sebastian Falbesoner33717073
David Gumberg55638072
Pieter Wuille95518066
Hodlinator66523076
Analysis record

Published AI watches

Last scanned 53 minutes ago

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
Informational 15 AI analysisMessage 80 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

ci: update NetBSD cross-build SDK

This is a routine maintenance update to Bitcoin Core's continuous integration (CI) system. It changes the version number of the NetBSD operating system used for cross-compilation testing from a release candidate (11.0_RC6) to the final rel…

2c87337eby Lőrinc+1−11 file
No security note in commit
Informational 15 AI analysisMessage 72 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: require `TryGetTotalRam()` detection

This commit only changes a test file and build configuration. It removes the option to skip a test when the system cannot detect total RAM, and instead requires the RAM detection to succeed. It does not change any production wallet, networ…

6a2de55aby Lőrinc+3−112 files
No security note in commit
Informational 15 AI analysisMessage 68 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

scripted-diff: use `MIN_DBCACHE_BYTES`

This commit is a simple automated rename of a constant from MIN_DB_CACHE to MIN_DBCACHE_BYTES across five files. The value stays the same (4 MiB), and no behavior changes. It is a code-cleanup/refactoring change with no security relevance.

7cfa21d6by Lőrinc+5−55 files
No security note in commit
Informational 20 AI analysisMessage 68 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

kernel: allow setting chainstate `dbcache`

This commit adds a new public API knob to the Bitcoin Core 'libbitcoinkernel' library so that programs using the kernel can choose how much memory to use for the chainstate database cache. It also enforces minimum and maximum size limits. …

New configurable cache-size API with explicit min/max validationReplaces hard-coded DEFAULT_KERNEL_CACHE with caller-supplied valueAdds unit tests for out-of-range rejection and 32-bit upper-bound rejection
8bd9f460by Lőrinc+41−14 files
No security note in commit
Informational 15 AI analysisMessage 68 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

kernel, node: colocate dbcache bounds

This commit is a small code cleanup: it moves two constants that define the minimum and maximum size of the database cache (dbcache) into a shared kernel header so that both the node and kernel code use the same limits. There is no change …

8aa21e11by Lőrinc+7−74 files
No security note in commit
Informational 15 AI analysisMessage 62 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

node, qt: inline `DEFAULT_DB_CACHE`

This is a small code cleanup change in Bitcoin Core. It removes a misleading alias named DEFAULT_DB_CACHE and replaces it with the underlying name DEFAULT_KERNEL_CACHE in a few places. The behavior of the program is unchanged; only the nam…

cd086c16by Lőrinc+5−74 files
No security note in commit
Repository ledger

Explore captured commits

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

Lower-prioritytest: doc: remove `--perf` profiling from functional test frameworkby Sebastian Falbesoner · 9fae7e98 · Jun 13, 2026 · 6 filesMessage 95 · StrongTriage 0Details
Commit message · Sebastian Falbesoner

test: doc: remove `--perf` profiling from functional test framework

This feature was broken for more than a year and no developer apparently
even noticed, so one can conclude that it is largely unused; it seems
thus reasonable to remove it to reduce maintenance burden.

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
Lower-priorityci: bump MSan fuzz timeoutby Sjors Provoost · 17353f9d · Jun 13, 2026 · 1 fileMessage 98 · StrongTriage 0Details
Commit message · Sjors Provoost

ci: bump MSan fuzz timeout

The MSan fuzz job has little headroom on fork CI when caches miss.

Examples from Sjors/bitcoin:

- PR 116 timed out after 2h30m: https://github.com/Sjors/bitcoin/actions/runs/27465468297/job/81187008305?pr=116

- PR 117 passed in 2h24m47s: https://github.com/Sjors/bitcoin/actions/runs/27465461797/job/81186956747?pr=117

- PR 118 passed in 2h18m22s: https://github.com/Sjors/bitcoin/actions/runs/27465761345/job/81187860567?pr=118

Bump the timeout to 180 minutes to leave room for runner variance.

98/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✓ Links an issue, advisory, or supporting reference
Why it was queued
fuzzing or regression evidencedocumentation-only discount
Security candidaterpc: tighten setmocktime upper bound to UINT32_MAXby stringintech · 406c2348 · Jun 13, 2026 · 3 filesMessage 78 · AdequateLow 35Details
Commit message · stringintech

rpc: tighten setmocktime upper bound to UINT32_MAX

The previous bound (~year 2262) was too permissive: paths that add an offset to the mocked time (e.g. the future-time check in ContextualCheckBlockHeader) can overflow int64_t (caught by UBSan), and paths that assign it to a uint32_t field (e.g. pblock->nTime in miner.cpp) silently truncate it (caught by the integer sanitizer). UINT32_MAX is the natural ceiling since block header nTime is uint32_t, and mocking beyond it is meaningless for anything consensus-related.

Add setmocktime bound checks to the existing _test_y2106 case in rpc_blockchain.py, and remove the negative bound check from rpc_uptime.py.

78/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
memory safetydefensive validation
AI analysis · Low 35/100

This commit tightens the maximum allowed mock time in Bitcoin Core's testing-only RPC command `setmocktime` from the year 2262 down to the year 2106 (the maximum value a 32-bit unsigned timestamp can hold). The change prevents two types of bugs that can occur only when a developer or tester manually sets an extremely far-future mock time: signed 64-bit integer overflow in time calculations, and silent truncation when the mocked time is copied into a 32-bit block timestamp field. The command is not available in production nodes and cannot be triggered by ordinary network peers, so this is a low-severity hardening fix for a testing tool.

Lower-priorityRevert "build: exclude mptest target from compile commands"by fanquake · d186c390 · Jun 13, 2026 · 1 fileMessage 65 · AdequateTriage 0Details
Commit message · fanquake

Revert "build: exclude mptest target from compile commands"

This reverts commit 4731049ba4f8a820cc4aa13a745e41bdfbee284a.

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
AI review queuedrpc: extend TxDoc() for getblock verbosity 2/3by Renato Britto · 372ac283 · Jun 13, 2026 · 3 filesMessage 68 · AdequateInformational 15Details
Commit message · Renato Britto

rpc: extend TxDoc() for getblock verbosity 2/3

Add fee, hex, fee_doc, prevout_doc, and vin_item_doc
options to TxDocOptions, and use them to describe
getblock verbosity=2/3 with structured metadata instead
of inline ELISION-based reuse.

Add GetBlockFields() to share the block-level result layout
across verbosity levels.

68/100 · AdequateMessage clarity
✓ 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 code cleanup in Bitcoin Core's RPC help documentation. It restructures how the help text for the getblock command is generated, replacing duplicated inline descriptions with shared helper functions. It does not change what data the software returns, how it processes network data, or any security-sensitive logic.

AI review queuedrpc: extract ListSinceBlockTxFields() helperby Renato Britto · 8a615a88 · Jun 13, 2026 · 2 filesMessage 58 · ThinInformational 15Details
Commit message · Renato Britto

rpc: extract ListSinceBlockTxFields() helper

Extract the inline listsinceblock transaction field list into a reusable
helper. The removed entry replaces its Type::ELISION placeholder with an empty
string elision.

ToSections() render an empty std::string elision as "...", and suppress
the array continuation marker when the last inner element renders as a
std::string elision.

58/100 · ThinMessage clarity
✓ Descriptive subject✓ 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 code cleanup that extracts a repeated list of RPC help text fields into a reusable helper function. It only affects how the documentation/help output for the listsinceblock command is generated, not how transactions or wallet data are processed. There is no security issue visible in the change.

Lower-priorityrpc: extract fee estimate result helpersby Renato Britto · a9f9e7d1 · Jun 13, 2026 · 1 fileMessage 68 · AdequateTriage 0Details
Commit message · Renato Britto

rpc: extract fee estimate result helpers

Replace inline fee estimation field lists in estimaterawfee with
reusable FeeRateBucketDoc() and FeeEstimateHorizonDoc() helpers.

Use ElideGroup() to keep repeated horizon and bucket sections
compact in human-readable help while preserving explicit result
metadata.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI review queuedrpc: expand getaddressinfo embedded with explicit fieldsby Renato Britto · 88e2a6ae · Jun 13, 2026 · 1 fileMessage 73 · AdequateInformational 18Details
Commit message · Renato Britto

rpc: expand getaddressinfo embedded with explicit fields

Replace the ELISION entry inside getaddressinfo's embedded object
with explicit fields using ElideGroup().

Factor the embedded field list into a helper so the nested layout
can be reused without duplicating the full structure inline.

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

This commit is a documentation-only change for the Bitcoin Core wallet's 'getaddressinfo' RPC command. It replaces a vague placeholder in the help text with a detailed, explicit list of fields that can appear inside the 'embedded' object. No wallet logic, validation rules, or network behavior is changed.

Lower-priorityrpc: remove unused RPCResult::Type::ELISIONby satsfy (Renato Britto) · 2447385f · Jun 13, 2026 · 2 filesMessage 80 · StrongTriage 0Details
Commit message · satsfy (Renato Britto)

rpc: remove unused RPCResult::Type::ELISION

RPCResult::Type::ELISION is not used anymore because it is not machine
readable for OpenRPC specs. To prevent future usage, it has been removed.

80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI review queuedrpc: extend TxDoc() for getrawtransaction verbosity 2by Renato Britto · 0380a1c4 · Jun 13, 2026 · 4 filesMessage 73 · AdequateInformational 18Details
Commit message · Renato Britto

rpc: extend TxDoc() for getrawtransaction verbosity 2

Add prevout, elision_mode, and vin_inner_elision options
to TxDocOptions, and use them to describe getrawtransaction verbosity=2
with structured metadata instead of raw ELISION entries. Extract
verbosity=1 block fields into a local verbosity_1_block variable so
verbosity=2 can reuse them via ElideGroup.

When vin_inner_elision is set, vin fields are elided while keeping
prevout visible. With elision_mode == ElisionMode::Silent, every other
top level field is hidden, so the only rendered output comes from the
vin not elided.

Loosen elision_has_description() to accept any group with at least one
field that is not SKIP.

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

This commit is a code cleanup for Bitcoin Core's RPC help documentation. It restructures how the help text for getrawtransaction verbosity=2 is generated, making it more consistent with other RPC documentation. It does not change how transactions are fetched, validated, or returned at runtime. There is no indication this fixes a security bug.

Security candidaterpc: expand decodepsbt output script with explicit fieldsby satsfy (Renato Britto) · 7a851180 · Jun 13, 2026 · 1 fileMessage 65 · AdequateInformational 15Details
Commit message · satsfy (Renato Britto)

rpc: expand decodepsbt output script with explicit fields

Reuse ScriptPubKeyDoc(), which matches what ScriptToUniv() emits here
wrapped in ElideGroup().

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100

This commit is a documentation-only change in the Bitcoin Core RPC help output. It replaces a vague placeholder description for the 'script' field inside decodepsbt with an explicit, structured description reused from another part of the code. There is no code behavior change, no bug fix, and no security relevance.

Lower-prioritytest: remove redundant test suite uniqueness lintby Lőrinc · 946feb3f · Jun 12, 2026 · 1 fileMessage 98 · StrongTriage 0Details
Commit message · Lőrinc

test: remove redundant test suite uniqueness lint

Duplicate Boost test suite names are already rejected by CMake when the suites are registered as CTest tests.
Follow-up to https://github.com/bitcoin/bitcoin/pull/35451#discussion_r3403672298.

Co-authored-by: maflcko <6399679+maflcko@users.noreply.github.com>

98/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✓ Links an issue, advisory, or supporting reference
Security candidatedoc: use signing pubkey instead of aggregate xonly keyby kevkevinpal · b3371029 · Jun 12, 2026 · 1 fileMessage 50 · ThinInformational 15Details
Commit message · kevkevinpal

doc: use signing pubkey instead of aggregate xonly key

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

This is a one-word documentation comment change in a header file. It renames 'aggregate xonly key' to 'signing (aggregate) pubkey' in a comment describing how a session ID is computed. There is no code change, no behavior change, and no security issue.

Lower-priorityguix: add package.shby fanquake · 9bfdde74 · Jun 12, 2026 · 3 filesMessage 55 · ThinTriage 0Details
Commit message · fanquake

guix: add package.sh

Split out packaging code, so that it can be re-used by
build scripts.

55/100 · ThinMessage clarity
✓ Subject identifies a change✓ Provides an explanatory body✓ Explains rationale or failure mode
Lower-priorityundo "ui: Compile boost:signals2 only once"by MarcoFalke · 77772e7a · Jun 11, 2026 · 6 filesMessage 68 · AdequateTriage 0Details
Commit message · MarcoFalke

undo "ui: Compile boost:signals2 only once"

commit fa5ce27385bc60cdf6d9a4eeb2d32c916c9e07eb was done to gain a 5%
faster compilation. However, this is no longer needed after the slim
btcsignals implementation.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI review queuedmv btcsignals.h to src/utilby MarcoFalke · fa45783d · Jun 11, 2026 · 10 filesMessage 45 · ThinInformational 15Details
Commit message · MarcoFalke

mv btcsignals.h to src/util

This is a low-level utility header

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit simply moves a header file called btcsignals.h from the top-level src/ directory into src/util/ and updates all the source files that include it. The code inside the file is unchanged. It is a routine code reorganization with no security relevance.

AI review queuedrefactor: Make scoped_connection ctor explicitby MarcoFalke · fa4903db · Jun 11, 2026 · 2 filesMessage 88 · StrongInformational 15Details
Commit message · MarcoFalke

refactor: Make scoped_connection ctor explicit

This ensures that all constructions of scoped connections are explict,
making the intent explicit and review easier. This also follows the
default recommendation from
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c46-by-default-declare-single-argument-constructors-explicit

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
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This is a minor code cleanup change that makes a single-argument constructor require explicit syntax. It does not fix a security bug or change runtime behavior; it only prevents accidental automatic type conversions during compilation.

AI review queuedtest: Check btcsignals determinism in thread_safety test caseby MarcoFalke · fa1bc1fe · Jun 11, 2026 · 1 fileMessage 95 · StrongInformational 12Details
Commit message · MarcoFalke

test: Check btcsignals determinism in thread_safety test case

The test only checked that the single atomic value is greater than 3000.
However, by splitting the atomic into two, one can do one exact check,
and also increase the lower bound on the inexact check.

Also, test disconnect races for every second step, instead of only once
at the end (likely when only one thread is running anyway).

Both changes make the test stricter and may catch non-determinism issues
that are not detected by sanitizers alone.

The test added in this commit should also pass when applied on top of
commit 63c68e2a3f98d2466a7e766d861ba3a94e92cd20, which is still using
the boost implementation.

95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
defensive validationsigning or wallet pathsecond-pass: near security thresholdsecond-pass: security-sensitive path
AI analysis · Informational 12/100

This is a test-only change for Bitcoin Core. It makes an existing unit test stricter by checking that one part of a multi-threaded signal callback counter is deterministic, and by testing connection/disconnection races more frequently. It does not change any production code, runtime behavior, or network protocol.

AI review queuedrefactor: Properly return from ThreadSafeQuestion signalby MarcoFalke · fa86e5db · Jun 11, 2026 · 3 filesMessage 95 · StrongModerate 51Details
Commit message · MarcoFalke

refactor: Properly return from ThreadSafeQuestion signal

Previously, the signal was using btcsignals::optional_last_value<bool>.
However, this only worked by accident:

The return value was influenced by the order in which the connections
were done. The noui callbacks would always overwrite the return value
with false. This makes the code overall brittle, and confusing.

For example, the following patch that changes the order of connections
would break the only and single place where the return value actually
matters:

```diff
diff --git a/src/qt/bitcoin.cpp b/src/qt/bitcoin.cpp
index 0b89c605b9..976549470e 100644
--- a/src/qt/bitcoin.cpp
+++ b/src/qt/bitcoin.cpp
@@ -488,3 +488,2 @@ int GuiMain(int argc, char* argv[])
btcsignals::scoped_connection handler_message_box = ::uiInterface.ThreadSafeMessageBox_connect(noui_ThreadSafeMessageBox);
- btcsignals::scoped_connection handler_question = ::uiInterface.ThreadSafeQuestion_connect(noui_ThreadSafeQuestion);
btcsignals::scoped_connection handler_init_message = ::uiInterface.InitMessage_connect(noui_InitMessage);
@@ -663,2 +662,3 @@ int GuiMain(int argc, char* argv[])
app.createWindow(networkStyle.data());
+ btcsignals::scoped_connection handler_question = ::uiInterface.ThreadSafeQuestion_connect(noui_ThreadSafeQuestion);
// Perform base initialization before spinning up initialization/shutdown thread
```

This can be tested by applying the patch and then calling:

(May have to be started twice to trigger the question)

```
bitcoin-qt -regtest -datadir=/tmp -mocktime=123456789
```

Before the changes in this commit (on current master), pressing `OK`
would not have any effect and would abort the program.

After the changes in this commit, pressing `OK` will correctly trigger a
-reindex and leave the program running.

95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Moderate 51/100

This commit fixes a brittle signal-handling bug in Bitcoin Core's user-interface code. Previously, when the program asked the user a yes/no question (for example, whether to rebuild the database), the answer could be ignored depending on the order in which internal callbacks were connected. The commit changes the signal system so that a 'yes' answer from any relevant handler is respected, rather than being overwritten by a later handler. The commit message explicitly notes that, before the fix, clicking 'OK' could abort the program instead of performing the requested recovery.

Lower-priorityrefactor: Make ThreadSafeMessageBox signal voidby MarcoFalke · fa4badc0 · Jun 11, 2026 · 6 filesMessage 92 · StrongTriage 0Details
Commit message · MarcoFalke

refactor: Make ThreadSafeMessageBox signal void

The message will always return false (a constant) and the return value
is never used.

Also, annotate ThreadSafeMessageBox in the GUI code as [[nodiscard]],
because it may actually return a value, which is handled for questions
(but not for messages).

92/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI review queuedrefactor: Mark btcsignals operator [[nodiscard]]by MarcoFalke · faad9d64 · Jun 11, 2026 · 1 fileMessage 80 · StrongInformational 15Details
Commit message · MarcoFalke

refactor: Mark btcsignals operator [[nodiscard]]

This is only relevant in case the result_type is not void, in which case
the caller should either use the return value or mark it unused.

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
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This is a minor code-quality change that tells the compiler to warn when a developer ignores the return value of a specific function call. It does not change how the program behaves, fix a bug, or close a security hole. It is a routine refactoring to help catch future programming mistakes during compilation.

Security candidatewallet: reject sendtoaddress and sendmany for external signersby Sjors Provoost · 2fe34808 · Jun 11, 2026 · 2 filesMessage 83 · StrongInformational 24Details
Commit message · Sjors Provoost

wallet: reject sendtoaddress and sendmany for external signers

The sendtoaddress and sendmany RPCs always go through SendMoney(), which
expects to sign internally. External signer wallets should use the PSBT
flow instead, via the send RPC.

Return a more specific error for external signer wallets and add
functional test coverage for both RPCs.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 24/100

This change makes Bitcoin Core refuse two older wallet commands (sendtoaddress and sendmany) when the wallet is controlled by an external signer, such as a hardware wallet. Previously these commands could be called but would fail in a confusing way because they expect to sign transactions internally. Now they return a clear message telling the user to use the newer send command instead. It is a usability and safety improvement, not a fix for an active attack.

Lower-prioritycoins: compact chainstate in backgroundby Lőrinc · 394e473d · Jun 11, 2026 · 4 filesMessage 68 · AdequateTriage 0Details
Commit message · Lőrinc

coins: compact chainstate in background

Full chainstate compaction can take minutes on large databases.
Move `CCoinsViewDB::CompactFull()` to a named `utxocompact` one-shot background thread so validation only schedules the work.

When validation selects compaction after a full flush, the chainstate was just written and another write is less likely to be needed immediately.
The coins view destructor waits for completion, and a mutex prevents compaction from using `m_db` while `ResizeCache()` replaces it.

Co-authored-by: Andrew Toth <andrewstoth@gmail.com>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priorityvalidation: randomly compact chainstateby Lőrinc · aa021b26 · Jun 11, 2026 · 6 filesMessage 70 · AdequateTriage 0Details
Commit message · Lőrinc

validation: randomly compact chainstate

Full chainstate flushes are convenient maintenance points for long-term LevelDB cleanup because the chainstate was just written.
Randomize the trigger so nodes that flush near the same height do not compact together.

Add blocking chainstate compaction through `CCoinsViewDB::CompactFull()` and give each post-IBD full flush on the normal chainstate a 1/320 chance to start compaction.
With hourly flushes this averages roughly every two weeks and makes a six-month miss about one in a million.
This keeps the schedule stateless and leaves last-compaction height or timestamp bookkeeping out of chainstate metadata.

Co-authored-by: Andrew Toth <andrewstoth@gmail.com>

70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI review queueddoc: add taproot descriptor to getdescriptors exampleby woltx · bd5a32f7 · Jun 11, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · woltx

doc: add taproot descriptor to getdescriptors example

Wallets import descriptors for all supported address types in a
BIP44/49/84/86 compatible manner, so show the BIP86 tr() descriptor in
the example response as well.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathdocumentation-only discountsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit only updates a documentation example in external-signer.md to include a Taproot (BIP86 tr()) descriptor alongside existing address-type examples. It is a documentation-only change with no code modifications, no functional changes, and no security implications.