BC
← All projectsBitcoin Core

Bitcoin Core

The Bitcoin network's reference node and wallet implementation.

BitcoinSupply chainNormal
Repository coverage

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

253security candidates604second-pass queue2596AI analyses
206commits · 30 days
502commits · 60 days
1528commits · 180 days
2883commits · 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
927Strong · 80–100
1188Adequate · 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 Poinsot22418170
Ava Chow15750149064
MarcoFalke40921392074
Lőrinc17721157081
fanquake22719199057
Hennadii Stepanov20914190063
rkrux57957074
Sjors Provoost89875074
Sebastian Falbesoner33732073
David Gumberg55654072
Pieter Wuille95573066
Hodlinator66555076
Analysis record

Published AI watches

Last scanned 24 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-prioritynet, fuzz: move CMPCTBLOCK_VERSION to header, use in cmpctblock harnessby Eugene Siegel · 8c9a3fd0 · Apr 27, 2026 · 3 filesMessage 75 · AdequateInformational 15Details
Commit message · Eugene Siegel

net, fuzz: move CMPCTBLOCK_VERSION to header, use in cmpctblock harness

The cmpctblock harness now adds peers and processes the sendcmpct message.

75/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 15/100

This commit moves a constant for compact block version from one file to a shared header and updates a fuzz test to exercise the sendcmpct network message. It is a test/refactoring change with no visible security fix or behavior change in production code.

Lower-priorityfuzz: initial compact block fuzz harnessby Eugene Siegel · 6cd480f6 · Apr 27, 2026 · 2 filesMessage 70 · AdequateInformational 15Details
Commit message · Eugene Siegel

fuzz: initial compact block fuzz harness

Adds a fuzz harness cmpctblock to test BIP152 compact block relay.
Currently just sets mock time in a loop.

70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 15/100

This commit adds a new fuzz-testing harness for compact block relay in Bitcoin Core. Fuzz testing is an automated quality-assurance technique that feeds random or semi-random data into code to find crashes or bugs. The harness currently only sets mock time in a loop and does not change any production networking, consensus, or wallet code. It is purely a test addition.

Lower-prioritylog: clarify VerifyDB summary logby ViniciusCestarii · 1d669637 · Apr 27, 2026 · 1 fileMessage 45 · ThinInformational 15Details
Commit message · ViniciusCestarii

log: clarify VerifyDB summary log

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Informational 15/100

This commit only changes the wording of a log message produced when Bitcoin Core's database verification tool finishes. It does not alter security behavior, fix a bug, or change any code logic. The new message simply reports how many blocks were checked and at what verification level, and only claims 'no inconsistencies' when an appropriate deep check was actually performed.

AI review queuedrefactor: disable default std::hash for CTransactionRefby Sjors Provoost · a9301cfa · Apr 27, 2026 · 1 fileMessage 85 · StrongLow 29Details
Commit message · Sjors Provoost

refactor: disable default std::hash for CTransactionRef

The default std::hash for shared_ptr compares by pointer.

CTransactionRefHash or a custom hasher should be used instead.

Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>

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

This is a defensive coding change in Bitcoin Core. It removes the default way to use CTransactionRef (a shared pointer to a transaction) as a key in hash tables, because the default behavior would compare memory addresses instead of transaction content. The change forces developers to explicitly choose a proper hash function, reducing the risk of subtle bugs in the future. It does not by itself fix a known active vulnerability.

Lower-priorityci: backport iwyu PR 2013 std::hash mappingby Sjors Provoost · 47d68cd9 · Apr 27, 2026 · 3 filesMessage 90 · StrongInformational 15Details
Commit message · Sjors Provoost

ci: backport iwyu PR 2013 std::hash mapping

Cherry-pick include-what-you-use commit 52f85e1f4d99 onto the clang_22
branch tracked by ci/test/00_setup_env_native_iwyu.sh, fixing the false
positive where std::hash was mapped to <string_view>/<variant> instead of
its real provider (<functional>, <memory>, etc).

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 updates Bitcoin Core's continuous integration (CI) tooling. It adds a patch for the include-what-you-use (IWYU) static analysis tool so that IWYU correctly recognizes which C++ standard library headers provide std::hash. This is a tooling-only change and does not alter the Bitcoin Core software that users run, so it has no direct security impact on the Bitcoin network or node operators.

Lower-prioritycmake: Remove NetBSD-specific workaround from `add_boost_if_needed`by Hennadii Stepanov · e2ef54b8 · Apr 27, 2026 · 1 fileMessage 65 · AdequateInformational 15Details
Commit message · Hennadii Stepanov

cmake: Remove NetBSD-specific workaround from `add_boost_if_needed`

The patched package is available as of the `pkgsrc-2026Q1` release.

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
AI analysis · Informational 15/100

This commit removes a build-system workaround that was only needed for NetBSD's package manager. The workaround adjusted where the compiler looks for Boost header files on NetBSD. It is being removed because the upstream NetBSD package has been fixed. There is no indication this change fixes a security vulnerability in Bitcoin Core itself.

AI review queuedrpc: combinerawtransaction now rejects unmergeable transactionsby Adam Andrews · 6d86184a · Apr 27, 2026 · 2 filesMessage 73 · AdequateLow 29Details
Commit message · Adam Andrews

rpc: combinerawtransaction now rejects unmergeable transactions

Previously, combinerawtransaction would silently return the first tx when
asked to combine unrelated txs. Now, it will check tx mergeability and
throws a descriptive error if tx cannot be merged.

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

This change fixes a behavior in Bitcoin Core's combinerawtransaction RPC command. Previously, if you gave it transactions that didn't belong together, it would quietly return the first transaction as if nothing was wrong. Now it checks that the transactions are actually mergeable and returns a clear error if they aren't. It also now requires at least two transactions to be provided. This is mostly a robustness and usability improvement rather than a critical security fix.

AI review queuedtest: add coverage for loading a wallet in a non-writable directoryby furszy · 08925d5e · Apr 25, 2026 · 1 fileMessage 87 · StrongLow 33Details
Commit message · furszy

test: add coverage for loading a wallet in a non-writable directory

Previously, wallets in non-writable directories were loaded,
leading to crashes on any subsequent write.

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

This commit adds a new automated test to Bitcoin Core. The test checks that the program refuses to load a wallet stored in a directory where it cannot write files. The commit message says that, before this behavior existed, loading such a wallet would cause the node to crash whenever it later tried to write data. The change itself only adds a test; it does not change the wallet-loading code. So the actual crash-prevention logic must have been introduced in an earlier commit that is not shown here.

AI review queuedtest: add coverage for wallet creation in non-writable directoryby furszy · 0218966c · Apr 25, 2026 · 2 filesMessage 72 · AdequateInformational 14Details
Commit message · furszy

test: add coverage for wallet creation in non-writable directory

72/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 14/100

This commit only adds a new automated test that checks Bitcoin Core correctly refuses to create a wallet in a directory without write permission. It does not change the wallet-creation logic itself, so it does not fix or introduce a security issue in the software.

AI review queuedwallet: handle non-writable db directoriesby furszy · bc0090f1 · Apr 25, 2026 · 3 filesMessage 80 · StrongLow 44Details
Commit message · furszy

wallet: handle non-writable db directories

1) For wallet load, this fixes a crash.

We currently allow loading wallets located on non-writable directories.
This is problematic because the node crashes on any subsequent write.
E.g. generating a block is enough to trigger it.

2) For wallet creation, this improves the returned error msg.

Before: creating a wallet would return a generic error:
"SQLiteDatabase: Failed to open database: unable to open database file"

After: creating a wallet returns:
"SQLiteDatabase: Failed to open database in directory <dir_path>: directory
is not writable"

80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
signing or wallet pathsecond-pass: broader security terminologysecond-pass: security-sensitive path
AI analysis · Low 44/100

This Bitcoin Core commit fixes a bug where the program would crash if a wallet was loaded from a directory that cannot be written to. It also gives a clearer error message when someone tries to create a wallet in such a directory. The fix checks whether the directory is writable before opening the wallet database, and reports a helpful error instead of crashing or showing a generic failure.

Lower-prioritydoc: update llvm based coverage exampleby Max Edwards · ef21e292 · Apr 24, 2026 · 1 fileMessage 78 · AdequateInformational 15Details
Commit message · Max Edwards

doc: update llvm based coverage example

On some systems the old example of using xargs to pass list of profraw
files can exceed xargs's argument limit resulting in multiple executions
of llvm-profdata merge command which overwrites it's output file losing
coverage information. Switch to using a file with a list of filenames.

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
documentation-only discount
AI analysis · Informational 15/100

This commit only updates a documentation example for developers about how to merge code-coverage data files. It changes the suggested shell command from using xargs to using a file list, preventing a tool from running multiple times and accidentally overwriting its own output. There is no change to Bitcoin Core's actual code, network behavior, or wallet security.

Lower-priorityrefactor: Run ShouldWarnOversizedDbCache calculation in u64by MarcoFalke · fa43da21 · Apr 24, 2026 · 3 filesMessage 95 · StrongInformational 15Details
Commit message · MarcoFalke

refactor: Run ShouldWarnOversizedDbCache calculation in u64

This follows the approach of the MiB and GiB operators.

This allows to remove some `if constexpr (SIZE_MAX == UINT64_MAX)` in
the tests.

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 small internal cleanup change in Bitcoin Core. It changes a helper function that decides whether to warn users about an oversized database cache so that it always uses 64-bit unsigned integers instead of the platform-dependent `size_t` type. The tests are simplified accordingly. There is no user-facing behavior change and no security fix.

Lower-priorityutil: Return uint64_t from _MiB and _GiB operatorsby MarcoFalke · fa580176 · Apr 24, 2026 · 3 filesMessage 50 · ThinInformational 15Details
Commit message · MarcoFalke

util: Return uint64_t from _MiB and _GiB operators

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

This is a routine code-quality change in Bitcoin Core. It changes two helper functions that convert 'MiB' and 'GiB' values into byte counts so they always return a 64-bit unsigned integer instead of a size type that can be 32-bit on some platforms. It also removes runtime overflow exceptions for values that used to be too large on 32-bit systems. There is no security bug being fixed here.

Lower-prioritydoc: clarify clang-tidy in developer notesby rkrux · a1e534bb · Apr 24, 2026 · 1 fileMessage 68 · AdequateInformational 15Details
Commit message · rkrux

doc: clarify clang-tidy in developer notes

Recently, I ran clang-tidy in my system and had to figure out setting it up
correcty on my system (macOS) & understanding its output while tweaking
few arguments that made the output easier to parse.

This patch documents those in the developer notes.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
documentation-only discount
AI analysis · Informational 15/100

This is a documentation-only change to the developer notes. It adds clearer instructions for running the clang-tidy code-quality tool on Bitcoin Core. There are no code changes, no security fixes, and no behavior changes to the Bitcoin software itself.

Lower-priorityci: add --extended when using --usecliby Pol Espinasa · a49bc1e2 · Apr 24, 2026 · 1 fileMessage 90 · StrongInformational 15Details
Commit message · Pol Espinasa

ci: add --extended when using --usecli

Add the flag --extended to a test (00_setup_env_i686_no_ipc.sh) with the --usecli flag to cover all tests with --usecli.

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 changes a continuous integration (CI) test script to add the '--extended' flag when running tests with '--usecli'. It does not modify any production code, network behavior, wallet handling, or consensus logic. There is no security issue here.

Lower-prioritystreams: Remove confusing DataStream::in_avail()by MarcoFalke · fa204100 · Apr 24, 2026 · 2 filesMessage 80 · StrongInformational 15Details
Commit message · MarcoFalke

streams: Remove confusing DataStream::in_avail()

The alias of the size() method is confusing, because:

* It claims to be part of the Bitcoin Core stream subset (streams
interface), but this is not used by any other stream interface. Mostly
the `write(std::span)` and `read(std::span)` define the stream
interface.
* It casts the size_t to i32, but the only place that calls the function
casts that back to size_t.
* Providing this alias for size() without a proper reason is confusing.

Fix all issues by removing it and using the size() method.

80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI analysis · Informational 15/100

This commit is a simple code cleanup: it removes a confusing alias named `in_avail()` from a data stream class and replaces its only use with a direct call to `size()`. There is no security issue here.

Lower-prioritymove-only: Extract ProcessPong() helperby MarcoFalke · fa5ab022 · Apr 24, 2026 · 1 fileMessage 60 · AdequateInformational 15Details
Commit message · MarcoFalke

move-only: Extract ProcessPong() helper

This commit can be reviewed with the git options:
--color-moved=dimmed-zebra --color-moved-ws=ignore-all-space

60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
AI analysis · Informational 15/100

This commit simply moves the existing code that handles PONG network messages into a new helper function called ProcessPong(). There are no functional changes, no bug fixes, and no security changes. It is a code-cleanup refactor to make the large ProcessMessage() function easier to read and maintain.

Lower-prioritydoc: add release notes for PR 34911by rkrux · 8deed0df · Apr 24, 2026 · 1 fileMessage 45 · ThinInformational 15Details
Commit message · rkrux

doc: add release notes for PR 34911

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
documentation-only discount
AI analysis · Informational 15/100

This commit only adds release notes describing a previously merged change. It does not modify any executable code, network behavior, or RPC logic. There is no security issue in this documentation-only commit.

Lower-priorityrpc, mempool: rpcdeprecate `bip125-replaceable` key in mempool RPCs reponsesby rkrux · 1a85ca1d · Apr 24, 2026 · 2 filesMessage 73 · AdequateInformational 20Details
Commit message · rkrux

rpc, mempool: rpcdeprecate `bip125-replaceable` key in mempool RPCs reponses

RPCs: getrawmempool, getmempoolancestors, getmempooldescendants, getmempoolentry

This key has been marked deprecated since v29, it can be
removed from the RPC response now unless the user requests it via the
-deprecatedrpc=bip125 node argument.

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

This commit removes a long-deprecated 'bip125-replaceable' field from several Bitcoin mempool-related RPC responses by default. Users can still get the old field back by starting their node with -deprecatedrpc=bip125. It is a routine API cleanup, not a security fix.

Lower-priorityrpc, mempool: rpcdeprecate `fullrbf` key in getmempoolinfo RPC responseby rkrux · f89d18c3 · Apr 24, 2026 · 2 filesMessage 73 · AdequateInformational 15Details
Commit message · rkrux

rpc, mempool: rpcdeprecate `fullrbf` key in getmempoolinfo RPC response

mempoolfullrbf=1 behaviour has been the default since v28 and the argument has
been removed since v29 subsequently. The getmempoolinfo RPC need not return
the deprecated `fullrbf` key in the response anymore unless the user requests
it via -deprecatedrpc=fullrbf node argument.

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

This change removes a now-obsolete 'fullrbf' field from the getmempoolinfo RPC response by default, while still allowing it to appear if the user explicitly requests legacy behavior with -deprecatedrpc=fullrbf. It is a routine cleanup of a deprecated API field and does not fix or introduce any security vulnerability.

Lower-prioritybench: make `setup()` use single-iteration epochsby Lőrinc · e6430b27 · Apr 23, 2026 · 7 filesMessage 68 · AdequateInformational 15Details
Commit message · Lőrinc

bench: make `setup()` use single-iteration epochs

`setup()` in nanobench runs once per epoch, not once per timed call.
If an epoch executes the benchmark body multiple times, `setup()` can silently leave later iterations with different preconditions.

Make `setup()` force `epochIterations(1)` itself: keep rejecting incompatible larger explicit epoch sizes, but allow existing single-iteration callers such as `-sanity-check`.

With `setup()` handling this centrally, remove the redundant `epochIterations(1)` calls from the benchmarks that use it.

Co-authored-by: David Gumberg <davidzgumberg@gmail.com>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100

This commit fixes a correctness issue in Bitcoin Core's internal benchmarking tool. Previously, benchmark setup code could run once per batch of repeated measurements, meaning later repeats might not start from a clean state. The change forces setup to run before every single measurement. This only affects benchmark tests, not the live Bitcoin network software, so it has no direct security impact on users.

Lower-prioritybench: fix ephemeral spend inputsby Lőrinc · ba0078e3 · Apr 23, 2026 · 1 fileMessage 68 · AdequateInformational 16Details
Commit message · Lőrinc

bench: fix ephemeral spend inputs

`MempoolCheckEphemeralSpends` wrote every prevout to `tx2.vin[0]` instead of `tx2.vin[i]`.
That left only one child input pointing at the parent transaction, while the remaining inputs kept default prevouts.

Write each prevout to `vin[i]` instead.
Add an assertion that the last child input spends the last parent output.

Co-authored-by: David Gumberg <davidzgumberg@gmail.com>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 16/100

This commit fixes a bug in a Bitcoin Core benchmark test, not in the live network code. The benchmark was supposed to create a test transaction with multiple inputs spending outputs from a parent transaction, but due to a typo it kept writing all the input details to the first input slot only. The remaining inputs were left empty/default. The fix writes each input to its correct slot and adds a sanity check. It does not affect real Bitcoin transactions, wallets, or consensus rules.

AI review queuedbench: drop duplicate balance benchmarkby Lőrinc · b8b7f896 · Apr 23, 2026 · 1 fileMessage 68 · AdequateInformational 15Details
Commit message · Lőrinc

bench: drop duplicate balance benchmark

`WalletBalanceMine` duplicated `WalletBalanceClean` exactly.
Remove the duplicate registration so the balance benchmark list stays distinct.

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 removes a duplicate benchmark test in Bitcoin Core. The 'WalletBalanceMine' benchmark was identical to 'WalletBalanceClean', so registering it twice served no purpose. This change only affects internal performance testing code and has no impact on the actual Bitcoin wallet software or its users.

AI review queuedutil/stdmutex: Drop StdLockGuardby Anthony Towns · 904c0d07 · Apr 23, 2026 · 1 fileMessage 35 · OpaqueInformational 15Details
Commit message · Anthony Towns

util/stdmutex: Drop StdLockGuard

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 removes a two-line backwards-compatibility type alias named StdLockGuard from a header file. It is a routine cleanup with no functional change to how the software behaves or to its security.

Lower-prioritysupport: clamp RLIMIT_MEMLOCK to size_tby Sjors Provoost · 735b2551 · Apr 23, 2026 · 1 fileMessage 68 · AdequateLow 43Details
Commit message · Sjors Provoost

support: clamp RLIMIT_MEMLOCK to size_t

On 32-bit systems we build with _FILE_OFFSET_BITS=64 (see CMakeLists.txt),
which makes rlim_t 64-bit when building against glibc (see bits/resource.h).
Since size_t could be 32-bit, clamp RLIMIT_MEMLOCK to
std::numeric_limits<size_t>::max() in PosixLockedPageAllocator::GetLimit().

Co-authored-by: Luke Dashjr <luke-jr+git@utopios.org>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Low 43/100

This change fixes a type-size mismatch on 32-bit systems. On those systems, the operating system can report a memory-lock limit as a 64-bit number, but the program stores it in a 32-bit variable. Without the fix, a very large limit could wrap around to a tiny value, potentially causing the wallet to lock far less memory than intended and possibly mishandle sensitive key data. The patch clamps the value to the largest safe 32-bit size before using it.