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 queue2748AI 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 Chow15750156064
MarcoFalke40921402074
Lőrinc17721167081
fanquake22719213057
Hennadii Stepanov20914203063
rkrux57957074
Sjors Provoost89879074
Sebastian Falbesoner33733073
David Gumberg55655072
Pieter Wuille95591066
Hodlinator66566076
Analysis record

Published AI watches

Last scanned 34 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.

AI review queuedrefactor: replace `DataStream` with `SpanReader` in block deserialization testsby Lőrinc · 13c8df4d · Apr 21, 2026 · 1 fileMessage 95 · StrongInformational 15Details
Commit message · Lőrinc

refactor: replace `DataStream` with `SpanReader` in block deserialization tests

These benchmark inputs are immutable fixture bytes, so `DataStream` adds an unnecessary owned buffer and the setup needed to recreate or preserve its state.

Use `SpanReader` for block deserialization in `checkblock` instead.
This keeps `DeserializeBlockTest` focused on deserialization work, while `CheckBlockTest` still uses untimed setup only to rebuild a fresh uncached `CBlock` for the timed `CheckBlock()` call.

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

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
second-pass: broader security terminology
AI analysis · Informational 15/100

This is a small internal cleanup in Bitcoin Core's benchmark code. It swaps one helper class for another when reading a fixed test block, removes unused header includes, and simplifies how the benchmark obtains mainnet chain parameters. There is no change to how real network blocks are validated or to any user-facing behavior.

AI review queuedrefactor: use `SpanReader` in `PrevectorDeserialize`by Lőrinc · 2529f255 · Apr 21, 2026 · 2 filesMessage 97 · StrongInformational 15Details
Commit message · Lőrinc

refactor: use `SpanReader` in `PrevectorDeserialize`

`PrevectorDeserialize` only needs a reusable read-only view over fixed serialized bytes.
Keeping a mutable `DataStream` around just to call `Rewind()` is unnecessary.

Rebuild a fresh `SpanReader` for each benchmark run and remove `DataStream::Rewind()`, whose remaining use was this benchmark-only reset path.
The benchmark can now serialize exactly the 1000 entries it deserializes, so drop the stale extra element that used to avoid full consumption.

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

97/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
Why it was queued
second-pass: broader security terminology
AI analysis · Informational 15/100

This is a code cleanup change in Bitcoin Core's internal benchmarking code. It swaps a mutable data stream for a simple read-only view in a performance test, and removes an unused helper function called Rewind(). There is no security issue here.

AI review queuedrefactor: use `SpanReader` in `TestBlockAndIndex`by Lőrinc · b8eb6c20 · Apr 21, 2026 · 1 fileMessage 92 · StrongInformational 15Details
Commit message · Lőrinc

refactor: use `SpanReader` in `TestBlockAndIndex`

`TestBlockAndIndex` still deserialized its fixed block fixture through `DataStream` and appended a dummy byte to avoid compaction after full consumption.

Use `SpanReader` for that fixture instead.
This removes the leftover dummy-byte workaround and reads the immutable fixture through a read-only view.

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
Why it was queued
second-pass: broader security terminology
AI analysis · Informational 15/100

This is a small internal cleanup in Bitcoin Core's benchmarking code. It swaps one way of reading a fixed test block fixture for another, read-only way, and removes a workaround that added a dummy byte. There is no user-facing or security-relevant change.

Lower-priorityrefactor: use `DataStream::clear` in `::read` and `::ignore`by Lőrinc · 61d678a6 · Apr 21, 2026 · 1 fileMessage 85 · StrongInformational 15Details
Commit message · Lőrinc

refactor: use `DataStream::clear` in `::read` and `::ignore`

When `DataStream` is fully consumed, both `read()` and `ignore()` reset it to an empty state by clearing the backing buffer and resetting the read position.

Call `clear()` in both places instead of open-coding the same state transition.
This keeps the behavior unchanged while documenting the fully-consumed reset in one place.

Remove the unused `Compact()` method as well - it has been unused for a long time and can be added back if it is ever needed.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
AI analysis · Informational 15/100

This is a small internal cleanup in Bitcoin Core's data-stream class. It replaces two snippets of identical code with a single call to an existing `clear()` method and removes an unused helper function. The commit message explicitly states the behavior is unchanged. There is no security-relevant change visible in the diff or references.

AI review queueddbwrapper: use `SpanReader` for iterator keysby Lőrinc · 5de2f97a · Apr 21, 2026 · 2 filesMessage 90 · StrongInformational 13Details
Commit message · Lőrinc

dbwrapper: use `SpanReader` for iterator keys

`CDBIterator::GetKey()` only deserializes the current LevelDB key once.
`GetKeyImpl()` already exposes the current key as a contiguous borrowed byte span, and `GetKey()` creates a fresh local reader and only performs immediate forward reads before returning.

Switch this path to `SpanReader` so the key bytes are read in place instead of being copied into a temporary `DataStream`.
This keeps the same exception swallowing and `bool` return semantics while avoiding the extra allocation and copy.

The preceding test locks down the subtle safety property that matters here: a failed decode must not consume the current iterator entry.
Note that the same simplification does not apply to `GetValue()`, because that path deobfuscates the value bytes in place first and still needs an owning mutable buffer.

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
second-pass: broader security terminology
AI analysis · Informational 13/100

This is a small internal code cleanup in Bitcoin Core's database wrapper. It changes how LevelDB iterator keys are read so the bytes are decoded directly from a borrowed memory view instead of being copied into a temporary buffer first. The commit message and diff show no security fix, bug correction, or behavior change—only a performance and clarity improvement.

AI review queuedtest: cover failed `CDBIterator::GetKey()` deserializationby Lőrinc · f0e498af · Apr 21, 2026 · 1 fileMessage 95 · StrongInformational 19Details
Commit message · Lőrinc

test: cover failed `CDBIterator::GetKey()` deserialization

The upcoming change will replace the temporary owning `DataStream` inside `CDBIterator::GetKey()` with a borrowed reader over the current LevelDB key bytes.
The copied `DataStream` currently insulates the iterator entry from a failed decode, so the optimization is only safe if a deserialization failure still returns `false` and leaves the same key/value readable afterward.

Extend `dbwrapper_iterator` to read a one-byte key as a `uint16_t`.
The read must fail, return `false`, and still allow the same key and value to be read afterward.
This would fail if `GetKey()` stopped swallowing deserialization exceptions, or if a failed decode started consuming shared iterator state instead of only temporary reader state.

Drop the dead `const_cast` in the test while here, since `dbw` is already non-const.

Locking down that contract first makes the following `SpanReader` switch a behavior-preserving optimization.

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
second-pass: broader security terminology
AI analysis · Informational 19/100

This commit only adds a new test to Bitcoin Core. It checks that when a database iterator tries to read a small one-byte key as a larger type and fails, the iterator is not broken and the same key/value can still be read afterward. The change itself is not a security fix; it is preparation for a future optimization in how keys are read from LevelDB.

Lower-priorityfuzz: apply node context reset pattern to p2p_handshakeby frankomosh · dfe5d6a8 · Apr 21, 2026 · 1 fileMessage 83 · StrongInformational 17Details
Commit message · frankomosh

fuzz: apply node context reset pattern to p2p_handshake

Apply the node context reset pattern from fabf8d1 to p2p_handshake. Previous pattern created local AddrMan and Warnings objects, leaving connman holding dangling references across iterations. Reset and reinstall node.addrman and node.peerman each iteration so sanitizers can detect stale pointer usage.

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 validationfuzzing or regression evidence
AI analysis · Informational 17/100

This change fixes a bug in a Bitcoin Core fuzz test (an automated testing harness, not production code). The test was creating new address-manager and peer-manager objects on every fuzzing iteration while leaving the connection manager pointing to the old, destroyed ones. That produced dangling pointers, which could cause crashes or false negatives during fuzzing but does not affect real Bitcoin nodes.

Lower-priorityfuzz: remove redundant CScript method calls from script harnessby Bruno Garcia · c9d85822 · Apr 21, 2026 · 2 filesMessage 83 · StrongInformational 15Details
Commit message · Bruno Garcia

fuzz: remove redundant CScript method calls from script harness

The script harness was calling GetSigOpCount, HasValidOps,
IsPayToAnchor, IsPayToScriptHash, IsPayToWitnessScriptHash, and
IsPushOnly on the fuzzed CScript. All of these are already covered
by the script_ops harness, which is the dedicated harness for
CScript member methods.

Also add the missing IsPayToAnchor call to script_ops so the move
preserves coverage.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 15/100

This commit is a minor cleanup of Bitcoin Core's fuzz testing code. It removes duplicate calls to CScript methods from one fuzz harness and adds one missing method call to another harness. There is no change to production code, consensus logic, networking, or wallet behavior, and no security issue is present.

AI review queuedwallet: remove fUpdate argument from AddToWalletIfInvolvingMeby rkrux · dc84a310 · Apr 20, 2026 · 2 filesMessage 50 · ThinInformational 15Details
Commit message · rkrux

wallet: remove fUpdate argument from AddToWalletIfInvolvingMe

Its only usage passes true.

50/100 · ThinMessage clarity
✓ Specific, 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 is a small internal code cleanup in Bitcoin Core's wallet module. It removes an unused function argument called fUpdate because every place that called the function always passed the value true. There is no change in behavior and no security issue.

AI review queuedwallet: remove update_tx argument from SyncTransactionby rkrux · 94845df0 · Apr 20, 2026 · 2 filesMessage 50 · ThinInformational 15Details
Commit message · rkrux

wallet: remove update_tx argument from SyncTransaction

Its only usage passes true.

50/100 · ThinMessage clarity
✓ Specific, 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 is a small internal cleanup in Bitcoin Core's wallet code. A function called SyncTransaction had an optional setting (update_tx) that was always being passed as 'true', so the developers removed that setting and hardcoded 'true' instead. There is no change in behavior and no security issue.

AI review queuedwallet: remove fUpdate argument from ScanForWalletTransactionsby rkrux · 6e796e1f · Apr 20, 2026 · 6 filesMessage 95 · StrongInformational 15Details
Commit message · rkrux

wallet: remove fUpdate argument from ScanForWalletTransactions

Only the unit test code passes false, the actual code passes
true always. I don't see a reason why the tests need to exercise
a behaviour that never happens in production.

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

This is a small code cleanup change in Bitcoin Core's wallet. It removes an optional argument called fUpdate from the ScanForWalletTransactions function because every real-world use passed true, while only test code ever passed false. The behavior in production is unchanged; the tests are simply adjusted to match the production behavior. There is no security issue here.

AI review queuedwallet: remove update argument from RescanFromTime methodby rkrux · 54e4c0be · Apr 20, 2026 · 3 filesMessage 50 · ThinInformational 15Details
Commit message · rkrux

wallet: remove update argument from RescanFromTime method

Its only usage passes true.

50/100 · ThinMessage clarity
✓ Specific, 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 is a small code cleanup change in Bitcoin Core's wallet code. It removes an unused option (the 'update' argument) from a method called RescanFromTime. The only place that called this method always passed 'true', so the developer simplified the code by hardcoding that value and removing the parameter. There is no security issue here.

Security candidaterefactor: use _MiB consistently for Mebibyte conversionsby Lőrinc · af0ee28e · Apr 20, 2026 · 36 filesMessage 100 · StrongInformational 20Details
Commit message · Lőrinc

refactor: use _MiB consistently for Mebibyte conversions

Replace hard-coded MiB byte conversions (e.g. `1024*1024`, `1<<20`, `1048576`) with the existing `_MiB` literal to improve readability and avoid repeating constants.
In the few spots where arithmetic involves signed values, the result is identical to the previous code assuming those quantities never turn negative.

Also switch to brace init on every declaration assigned from `_MiB`/`_GiB` literals so a future oversized value (e.g. `unsigned int x{4096_MiB}`) becomes a compile error through the C++11 narrowing check instead of silently truncating.

Extend unit tests to cover the 32-bit `size_t` overflow boundary and to assert equivalence for integer and floating-point conversions.

Co-authored-by: MarcoFalke <*~=`'#}+{/-|&$^_@721217.xyz>
Co-authored-by: w0xlt <94266259+w0xlt@users.noreply.github.com>

100/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✓ Names security-relevant behavior explicitly
Why it was queued
memory safetyseed or entropy path
AI analysis · Informational 20/100

This is a code cleanup change that replaces scattered hard-coded byte counts like 1024*1024 with a single named helper, _MiB, and adds unit tests for it. It does not change any user-visible behavior or fix a known security bug. The main safety benefit is making future accidental mistakes (for example, writing the wrong number of zeros) less likely and turning some oversized-value mistakes into compile-time errors.

Security candidateutil: add _GiB for Gibibyte conversionsby Lőrinc · b3edd30a · Apr 20, 2026 · 6 filesMessage 83 · StrongInformational 15Details
Commit message · Lőrinc

util: add _GiB for Gibibyte conversions

Introduce `operator""_GiB`, sharing the overflow-checked conversion logic with the existing `operator""_MiB`.

Use `1_GiB` in a few existing places where it is a drop-in replacement (e.g. `1024_MiB`, `1<<30`) and extend unit tests to cover boundary behavior.

83/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
memory safety
AI analysis · Informational 15/100

This commit adds a new code helper for writing byte sizes in gigabytes (GiB) and replaces a few existing hard-coded numbers with the new helper. It is a code cleanup and readability change with no security-relevant behavior change.

Lower-priorityChange CChain::FindFork() to take refby optout · c5eb283b · Apr 20, 2026 · 8 filesMessage 60 · AdequateInformational 18Details
Commit message · optout

Change CChain::FindFork() to take ref

The internal null-guard in FindFork() was removed in favor of adding any missing guards at call sites.

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

This is a small internal code cleanup in Bitcoin Core. It changes one function, CChain::FindFork(), so that callers must pass a valid block object directly rather than a pointer that might be null. The function previously handled null pointers safely by returning null; now callers must check for null themselves before calling it. The commit adds those checks at every call site. It is a defensive refactoring, not a fix for an active security bug.

Lower-priorityChange pindexMostWork parameter of ActivateBestChainStep() to referenceby optout · 7c75244a · Apr 20, 2026 · 2 filesMessage 73 · AdequateInformational 15Details
Commit message · optout

Change pindexMostWork parameter of ActivateBestChainStep() to reference

ActivateBestChainStep() is always called with non-nullptr pindexMostWork parameter,
change the type of the parameter from pointer to reference to enforce this.
Also rename the parameter (prefix p doesn't make sense any more).

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

This is a small internal code cleanup in Bitcoin Core. It changes one function parameter from a pointer (which could theoretically be null) to a reference (which cannot be null), because the caller always passes a valid object anyway. There is no change to how the program behaves, no bug fixed, and no security issue introduced.

Lower-priorityChange CChain::Next() to take referenceby optout · 20b58e28 · Apr 20, 2026 · 7 filesMessage 80 · StrongLow 27Details
Commit message · optout

Change CChain::Next() to take reference

To minimize chance of erroneous nullptr dereference, `CChain::Next()`
is changed to take a reference instead of a pointer.
Call sites have been adapted. Notably, NextSyncBlock() now checks
the FindFork() result before calling into Next(), because
the fork lookup may return null.

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

This commit tightens up a low-level helper function in Bitcoin Core that finds the next block in the chain. It changes the function so callers must pass a real block object rather than a potentially-null pointer, and it adds a safety check in one place where the previous code could have passed a null pointer. The change is defensive hardening rather than a fix for a confirmed, exploitable bug.

AI review queuedChange CChain::Contains() to take referenceby optout · fe2d6e25 · Apr 20, 2026 · 12 filesMessage 80 · StrongLow 47Details
Commit message · optout

Change CChain::Contains() to take reference

The `CChain::Contains()` method dereferences its input without checking,
potentially resulting in nullptr-dereference if invoked with `nullptr`.
To avoid this possibility, its input is changed to a reference instead.
Call sites are adapted accoringly, extra nullptr-check is added as
needed.

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: security-sensitive path
AI analysis · Low 47/100

This commit hardens a core Bitcoin method called CChain::Contains() so it can no longer be accidentally called with a null (missing) block pointer, which would crash the node. The change turns the method's input from a pointer into a reference, forcing every caller to prove the block exists before calling it. Several call sites were updated, and one place in startup index syncing now explicitly handles a missing block instead of silently passing a null pointer. It is a defensive fix that removes a class of potential null-dereference crashes, but the commit message does not frame it as a critical security vulnerability and no exploit is demonstrated.

Lower-prioritytest: Add CChain::FindFork() testsby optout · db56bcd6 · Apr 20, 2026 · 1 fileMessage 82 · StrongInformational 15Details
Commit message · optout

test: Add CChain::FindFork() tests

Add (lengthier) unit tests for `CChain::FindFork()`.

Co-authored-by: l0rinc <pap.lorinc@gmail.com>

82/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body✓ Mentions testing or verification
AI analysis · Informational 15/100

This commit only adds new unit tests for an existing function called CChain::FindFork(). It does not change any production code, so it cannot directly introduce a security vulnerability or fix one. It is a routine test-only change.

Lower-prioritytest: Add CChain basic testsby optout · 8333abdd · Apr 20, 2026 · 1 fileMessage 82 · StrongInformational 15Details
Commit message · optout

test: Add CChain basic tests

Add basic unit tests to the `CChain` class, filling a gap.

Co-authored-by: l0rinc <pap.lorinc@gmail.com>

82/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body✓ Mentions testing or verification
AI analysis · Informational 15/100

This commit only adds new automated unit tests for the CChain class in Bitcoin Core. It does not change any production code, fix bugs, or introduce security-relevant behavior. The tests verify basic chain operations like height, tip, indexing, contains, next, and genesis on empty and two-block chains.

Lower-prioritynet: log SOCKS5 auth before sendingby takeshikurosawaa · 3bf3b6d5 · Apr 19, 2026 · 1 fileMessage 50 · ThinInformational 19Details
Commit message · takeshikurosawaa

net: log SOCKS5 auth before sending

50/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Names security-relevant behavior explicitly! No meaningful explanatory body
AI analysis · Informational 19/100

This commit simply moves a debug log message so it prints before the SOCKS5 username/password data is sent over the network, rather than after. It does not change what data is sent, how it is encrypted, or who can read it. The change only helps developers diagnose connection problems by ensuring the log appears at the correct moment.

Security candidatenet: cleanup SOCKS5 auth loggingby takeshikurosawaa · b2debc92 · Apr 19, 2026 · 1 fileMessage 73 · AdequateLow 49Details
Commit message · takeshikurosawaa

net: cleanup SOCKS5 auth logging

Do not log SOCKS5 auth credentials.

Keep the log entry for the auth path, but omit the
username and password.

No behavior change intended.

73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
credential or privilege state
AI analysis · Low 49/100

This commit removes a debug log line that printed SOCKS5 proxy usernames and passwords in plain text. The change prevents sensitive credentials from being written to log files, which could otherwise expose them to anyone with access to those logs. It is a straightforward cleanup with clear security benefit, though it only affects debug-level logging.

Security candidatetor: torcontrol disconnect on too many lines to avoid OOMby David Gumberg · 9fe5896a · Apr 17, 2026 · 2 filesMessage 98 · StrongModerate 62Details
Commit message · David Gumberg

tor: torcontrol disconnect on too many lines to avoid OOM

This commit ensures the `TorControlConnection::m_message` buffer doesn't
grow unbounded and exhaust memory, by limiting the number of lines
handled by `TorControlConnection::ProcessBuffer()` to `MAX_LINE_COUNT =
1000`. Now the most memory that can be occupied by `m_message` is on the
order of `MAX_LINE_LENGTH * MAX_LINE_COUNT= 100MB`

Although this is not compliant with the tor control protocol in general,
where commands like `GETINFO ns/all` will likely return thousands of
lines, it is more than sufficient for handling the replies from the
commands that are used by a node:

`AUTHENTICATE`: 1 line:
The server responds with 250 OK on success or 515 Bad
authentication if the authentication cookie is incorrect. Tor closes
the connection on an authentication failure.

https://spec.torproject.org/control-spec/commands.html#authenticate

`GETINFO net/listener/socks`: 2 lines
A quoted, space-separated list of the locations where Tor is
listening...

https://spec.torproject.org/control-spec/commands.html#getinfo

`AUTHCHALLENGE SAFECOOKIE`: 1 line
If the server accepts the command, the server reply format is:

```
"250 AUTHCHALLENGE" SP "SERVERHASH=" ServerHash SP "SERVERNONCE="
ServerNonce CRLF
```

https://spec.torproject.org/control-spec/commands.html#authenticate

`PROTOCOLINFO`: 4-5 lines

The server reply format is:

```
250-PROTOCOLINFO" SP PIVERSION CRLF \*InfoLine "250 OK" CRLF
InfoLine = AuthLine / VersionLine / OtherLine
```

(https://spec.torproject.org/control-spec/commands.html#protocolinfo)

`ADD_ONION`: 2-3 lines for Bitcoin Core's tor control client.

The server reply format is:

```
"250-ServiceID=" ServiceID CRLF
["250-PrivateKey=" KeyType ":" KeyBlob CRLF]
*("250-ClientAuth=" ClientName ":" ClientBlob CRLF)
"250 OK" CRLF
```

...

The server response will only include a private key if the server
was requested to generate a new keypair

...

If client authorization is enabled using the “BasicAuth” flag (which
is v2 only), the service will not be accessible to clients without
valid authorization data (configured with the “HidServAuth” option).
The list of authorized clients is specified with one or more
“ClientAuth” parameters. If “ClientBlob” is not specified for a
client, a new credential will be randomly generated and returned."

https://spec.torproject.org/control-spec/commands.html#add_onion

We don't set the `BasicAuth` flag, so the response will not include any
`ClientAuthLines`.

98/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
secret or key materialaccess controlcredential or privilege state
AI analysis · Moderate 62/100

This change fixes a memory safety issue in Bitcoin Core's connection to the Tor control port. A malicious or misbehaving Tor control server could send an endless stream of reply lines, causing Bitcoin Core to keep allocating memory until the system ran out. The patch caps the number of lines accepted in a single reply at 1,000, after which the connection is closed. The commit message explicitly says this is to avoid out-of-memory (OOM) exhaustion.

Lower-prioritytest: Make torcontrol max line length test stricter and test boundaries.by David Gumberg · 8b68287b · Apr 17, 2026 · 1 fileMessage 95 · StrongInformational 15Details
Commit message · David Gumberg

test: Make torcontrol max line length test stricter and test boundaries.

Adds a check that at the boundary of MAX_LINE_LENGTH, no disconnect
occurs.

Also makes the overlength test message exactly MAX_LINE_LENGTH + 1 to
test the boundary.

Drops the redundant node liveness check, which is covered by the later
check that the node reconnects.

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 commit only changes a test file. It makes the existing Tor control line-length test more precise by checking that a line exactly at the maximum allowed length does not cause a disconnect, while a line one character over still does. There is no change to Bitcoin Core's actual production code, so it cannot directly affect live node security.

Lower-prioritylogging: replace BufferedLog with log::Entryby stickies-v · 3b92ec20 · Apr 17, 2026 · 3 filesMessage 60 · AdequateInformational 12Details
Commit message · stickies-v

logging: replace BufferedLog with log::Entry

Avoids duplication and ensures timestamp and mocktime are captured
at the same time.

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

This is a small internal code cleanup in Bitcoin Core's logging system. It removes a duplicate log-entry structure and makes sure the real timestamp and the simulated 'mocktime' are recorded at the same instant. There is no indication this fixes a security bug or introduces a vulnerability.