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.

AI review queuedrefactor: use SignOptions for SignTransactionby Sjors Provoost · 5ed41752 · Apr 28, 2026 · 9 filesMessage 57 · ThinInformational 15Details
Commit message · Sjors Provoost

refactor: use SignOptions for SignTransaction

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

This is a straightforward code cleanup change. It replaces a plain integer parameter for the signature hash type with a small options structure called SignOptions. All existing callers are updated to pass the same value inside the new structure. There is no change to what the code actually does or to any security behavior.

Security candidaterefactor: use PSBTFillOptions for filling and signingby Sjors Provoost · dc4a5d12 · Apr 28, 2026 · 20 filesMessage 93 · StrongInformational 15Details
Commit message · Sjors Provoost

refactor: use PSBTFillOptions for filling and signing

Replace the sign, finalize , bip32derivs and sighash_type arguments which
are passed to FillPSBT() and SignPSBTInput() with a PSBTFillOptions struct.

This makes it easier to add additional options later without large code
churn, such as avoid_script_path proposed in #32857. It also makes the
use of default boolean options safer compared to positional arguments
that can easily get mixed up.

93/100 · StrongMessage clarity
✓ Specific, 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
secret or key materialsigning boundarysigning or wallet path
AI analysis · Informational 15/100

This is a straightforward code cleanup (refactor) that bundles several PSBT signing options into a single structure. It does not change what the software does; it only changes how the options are passed around internally. There is no security vulnerability here.

Security candidaterefactor: use SignOptions for MutableTransactionSignatureCreatorby Sjors Provoost · eab72d14 · Apr 28, 2026 · 11 filesMessage 62 · AdequateInformational 15Details
Commit message · Sjors Provoost

refactor: use SignOptions for MutableTransactionSignatureCreator

62/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100

This commit is a straightforward code cleanup: it replaces a raw integer parameter representing the signature hash type with a small structured options object called SignOptions. All call sites are updated to pass the same value inside the new structure. There is no change to what the program actually does, no bug fix, and no security-relevant behavior change.

AI review queueddbwrapper: reuse iterator scratch streamby Lőrinc · 032223f4 · Apr 28, 2026 · 2 filesMessage 90 · StrongInformational 13Details
Commit message · Lőrinc

dbwrapper: reuse iterator scratch stream

`CDBIterator::Seek()` and `CDBIterator::GetValue()` only need a temporary owning buffer for immediate use.

Keep one preallocated `DataStream` scratch member on the non-copyable iterator and guard each use with `ScopedDataStreamUsage`.
`SeekImpl()` consumes the serialized key during the immediate LevelDB seek, and `GetValue()` still copies LevelDB value bytes into the owning scratch stream before in-place deobfuscation.

A single stream is enough because these methods cannot overlap on the same iterator without re-entering or concurrently using it, which the guard asserts against.
The preceding test covers repeated seeks and failed value deserialization followed by a successful read from the same entry.

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

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 performance cleanup in Bitcoin Core's database iterator code. It replaces repeatedly created temporary data buffers with a single reusable scratch buffer stored on the iterator object. There is no indication this fixes a security bug; it appears aimed at reducing memory allocations and object churn.

Lower-prioritytest: cover repeated dbwrapper stream useby Lőrinc · cb1ab0a7 · Apr 28, 2026 · 1 fileMessage 90 · StrongInformational 14Details
Commit message · Lőrinc

test: cover repeated dbwrapper stream use

The next commits reuse scratch streams on `CDBBatch` and `CDBIterator`.

Extend dbwrapper tests to reuse a batch after `Clear()`, seek repeatedly on one iterator, and fail a too-large `CDBIterator::GetValue()` decode before reading the same entry successfully.
This locks down the reuse and failed-decode contracts before the production changes.

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

This commit only adds new test cases for the database wrapper code. It checks that a database batch can be reused after being cleared, and that a database iterator can be seeked multiple times and recover from a failed value decode. There are no changes to production code, so this commit does not introduce or fix a security vulnerability by itself.

Lower-prioritydbwrapper: guard `CDBBatch` scratch streamsby Lőrinc · 7403c0f9 · Apr 28, 2026 · 2 filesMessage 68 · AdequateInformational 16Details
Commit message · Lőrinc

dbwrapper: guard `CDBBatch` scratch streams

`CDBBatch` already owns key and value serialization buffers, but manually reserved and cleared them on each call.

Reserve those scratch buffers once in the constructor, then guard `Write()` and `Erase()` use with `ScopedDataStreamUsage`, requiring empty streams on entry and clearing them on every exit path.
`WriteImpl()` and `EraseImpl()` pass the bytes immediately to LevelDB's write batch, which copies them and does not retain pointers.

`Clear()` now asserts the guards left both scratch streams clean.

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

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

This change is a small internal cleanup in how Bitcoin Core prepares database writes. It reuses temporary memory buffers instead of repeatedly reserving and clearing them, and adds a helper to make sure those buffers are empty before and after each use. There is no direct evidence this fixes an active security bug; it is best described as defensive hardening or code-quality improvement.

Lower-prioritystreams: add `ScopedDataStreamUsage`by Lőrinc · 31ce729b · Apr 28, 2026 · 2 filesMessage 58 · ThinInformational 18Details
Commit message · Lőrinc

streams: add `ScopedDataStreamUsage`

Some DB paths reuse caller-owned `DataStream` scratch buffers across calls.

Add a small RAII helper that asserts the stream is empty on entry and clears it on exit.
This preserves the old temporary-stream contract while making accidental nested reuse fail fast in debug builds.

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
AI analysis · Informational 18/100

This commit adds a small helper class that wraps a temporary data buffer used internally by Bitcoin Core's database code. It makes sure the buffer is empty when use starts and clears it when use ends, and in debug builds it will crash the program if a buffer is accidentally reused while still in use. It is a defensive hardening change, not a fix for a known exploitable bug.

Lower-priorityvalidation: Don't add pruned blocks to m_blocks_unlinked on startupby marcofleon · 0e4b0bac · Apr 27, 2026 · 1 fileMessage 81 · StrongModerate 53Details
Commit message · marcofleon

validation: Don't add pruned blocks to m_blocks_unlinked on startup

LoadBlockIndex() adds to m_blocks_unlinked based only on nTx > 0, without
checking BLOCK_HAVE_DATA. Pruning preserves nTx but clears BLOCK_HAVE_DATA,
so a pruned block whose parent was header-only gets re-added on every
restart, causing the CheckBlockIndex() assertion that entries must have
data on disk to fail.

Check that BLOCK_HAVE_DATA is set before inserting into m_blocks_unlinked.

Fixes #35050.

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

This commit fixes a bug where Bitcoin Core could crash on startup with a failed internal consistency check. The crash happened when a node had 'pruned' old block data while also having some header-only blocks, causing the program to incorrectly re-add pruned blocks to an internal list that is supposed to contain only blocks still stored on disk. The fix adds a check to skip pruned blocks when rebuilding that list during startup.

Lower-priorityfuzz: send blocktxn messages in cmpctblock harnessby Eugene Siegel · c8d688f4 · Apr 27, 2026 · 1 fileMessage 80 · StrongInformational 15Details
Commit message · Eugene Siegel

fuzz: send blocktxn messages in cmpctblock harness

Sometimes, blindly take an existing block and choose random
transactions to request in a blocktxn message.

80/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 15/100

This commit adds a new test case to an existing fuzzing harness for Bitcoin Core's compact block (cmpctblock) handling. It does not change production code, network behavior, or wallet logic. The new code only runs inside a fuzz test and randomly sends 'blocktxn' messages to exercise more code paths during automated testing. There is no security vulnerability here.

Lower-priorityfuzz: send compact blocks in cmpctblock harnessby Eugene Siegel · d0333bfe · Apr 27, 2026 · 1 fileMessage 78 · AdequateInformational 15Details
Commit message · Eugene Siegel

fuzz: send compact blocks in cmpctblock harness

Using an existing block or a newly created block, send a compact
block message to the target node. Some of the time, the harness
will prefill multiple transactions from the block. Adds a
FuzzedCBlockHeaderAndShortTxIDs class that's used to populate the
protected prefilledtxn and shorttxids fields.

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

This commit only adds new fuzz testing code for Bitcoin Core's compact block (CMPCTBLOCK) handling. It does not change any production network or consensus code, so it cannot introduce a runtime security vulnerability in the software users run. It is a test-harness improvement.

Security candidatefuzz: mine blocks and send headers for them in cmpctblock harnessby Eugene Siegel · 3c58efe2 · Apr 27, 2026 · 3 filesMessage 95 · StrongInformational 15Details
Commit message · Eugene Siegel

fuzz: mine blocks and send headers for them in cmpctblock harness

The blocks may include mempool and non-mempool transactions. If the
block index was added to, reset the rng, mempool, and chainman. Also
move FinalizeHeader from p2p_headers_presync.cpp to util.h so that
the mining function can use it to create valid headers.

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
entropy or randomnessfuzzing or regression evidence
AI analysis · Informational 15/100

This commit only changes Bitcoin Core's internal fuzz testing code. It expands a fuzz harness so that the test can mine fake blocks and send headers for them, improving test coverage for compact block processing. There is no change to production network code, wallets, consensus rules, or RPC interfaces, so it does not introduce a security vulnerability in the software users run.

Security candidatefuzz: create and send transactions in cmpctblock harnessby Eugene Siegel · 65162243 · Apr 27, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Eugene Siegel

fuzz: create and send transactions in cmpctblock harness

If the mempool is modified at all (determined by a change in the sequence
counter), reset the rng, mempool, and the chainman for the next iteration.

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
entropy or randomnessfuzzing or regression evidence
AI analysis · Informational 15/100

This commit only changes a fuzz test file (src/test/fuzz/cmpctblock.cpp). It makes the compact-block fuzzing harness create and send fake transactions during testing, and resets internal test state if the mempool changes. There is no change to production Bitcoin Core code, network rules, or wallet behavior. It does not fix or introduce a real security vulnerability.

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.

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.

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