CommitWatch RSS
BC
← All projectsBitcoin Core

Bitcoin Core

The Bitcoin network's reference node and wallet implementation.

BitcoinSupply chainNormal
Source repository ↗
Repository coverage

2876 commits in the local evidence base

Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.

252security candidates603second-pass queue173AI analyses
210commits · 30 days
492commits · 60 days
1521commits · 180 days
2876commits · 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
915Strong · 80–100
1187Adequate · 60–79
686Thin · 40–59
88Opaque · 0–39
6security candidates with opaque commit messaging
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
Antoine Poinsot2243170
Ava Chow1564946064
MarcoFalke4062112074
Lőrinc1772113081
fanquake227198057
Hennadii Stepanov208147063
rkrux5797074
Sjors Provoost8985074
Sebastian Falbesoner3375073
David Gumberg5563072
Pieter Wuille9552066
Hodlinator6653076
Analysis record

Published AI watches

Last scanned 44 minutes ago

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

refactor: Make all `const static` class members `constexpr`

This commit is a code cleanup that changes many internal class constants from 'static const' to 'static constexpr'. In modern C++, constexpr constants are automatically inlined and avoid certain linker errors when used in specific ways. Th…

05c35c40by rustaceanrob+38−4024 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 83 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

scripted-diff: Use long form of shell options in Guix scripts

This commit is a purely cosmetic change in Bitcoin Core's Guix build scripts. It replaces the short shell command 'set -e' with its long-form equivalent 'set -o errexit'. Both forms do exactly the same thing: they make the script exit imme…

2cb3bfa8by Hennadii Stepanov+6−66 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 45 · Thin
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

guix: Add copyright headers to Guix scripts

This commit only adds or updates copyright and license header comments at the top of several helper scripts used for Bitcoin Core's Guix build process. It does not change any executable code, logic, or behavior. There is no security risk.

711eb10fby Hennadii Stepanov+20−27 files
No security note in commit
Open full analysis →Source commit ↗
Low 28 AI analysisMessage 96 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Squashed 'src/secp256k1/' changes from bd0287d650..d2d04864ef

This commit updates the secp256k1 cryptographic library inside Bitcoin Core to a newer version. The main change is adding support for a new optional feature called 'Silent Payments' (BIP352), which is a privacy-enhancing way to receive Bit…

New cryptographic module added (Silent Payments / BIP352)Field-element equality check magnitude bound corrected from 31 to 30X-only public key even-Y invariant enforced in extrakeys module
a33f2405by fanquake+13939−13434 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 90 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

scripted-diff: Use C.UTF-8 locale in Guix scripts

This commit is a routine cleanup that changes the locale setting in Bitcoin Core's Guix build scripts from the old ASCII-only 'C' locale to the modern 'C.UTF-8' locale. It is not a security fix and does not change any behavior that could b…

8916f796by Hennadii Stepanov+15−1515 files
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 68 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

p2p: Assume v2transport for addresses from seeds

This change makes Bitcoin Core assume that hard-coded and DNS seed nodes support the newer BIP324 encrypted transport (v2) when first connecting. If the guess is wrong, the software falls back to the older v1 protocol automatically. It is …

Adds NODE_P2P_V2 to assumed service flags for seed-derived addressesFallback to v1 transport exists if the v2 assumption is wrongNo input validation, memory safety, or cryptographic changes
cf0f2aeaby Martin Zumsande+10−22 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 90 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: add shared SipHash vectors

This commit only adds new test data and test code for the SipHash hashing function used in Bitcoin Core. It does not change any production code that handles transactions, networking, or wallets. The goal is to make sure the existing SipHas…

af50ba85by Lőrinc+797−237 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 72 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: compat, ensure downgrade preserves tx witness variants

This commit adds a new regression test to Bitcoin Core. It checks that when a wallet created on a newer version is loaded on an older version and then brought back to the newer version, the wallet still remembers alternative 'witness varia…

99bdcb06by furszy+74−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 68 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

fuzz: clang-format LIMITED_WHILE

This commit is purely a code-style cleanup. It adds a space between the macro name LIMITED_WHILE and its opening parenthesis across many fuzz test files, plus a few tiny formatting fixes like removing a redundant semicolon and fixing inden…

fab8eeedby MarcoFalke+91−14265 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 63 AI analysisMessage 90 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

net_processing: add a global delay queue for sending txs

This commit adds a global rate limiter to how many transaction announcements (INV messages) a Bitcoin node sends out. Before, each peer had its own queue, so a node could receive one transaction and announce it to over 100 peers, acting li…

Global rate limiting replaces per-peer queues to prevent transaction-announcement amplificationDual token buckets bound both INV count and relay bandwidthCommit message explicitly describes the change as limiting transaction-spam amplification and excessive memory/CPU usage
df31ee57by Anthony Towns+176−252 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 24 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: add regression test for in-memory SQLiteDatabase reopen

This commit only adds a new automated test. It checks that Bitcoin Core's in-memory SQLite wallet database correctly refuses to reopen after being closed, because reopening would silently create a fresh empty database and discard any previ…

Regression test for data-loss prevention behavior in wallet database layerIn-memory SQLite database reopen could silently discard wallet dataOpen() now throws std::runtime_error instead of returning a fresh connection
777d23f2by Pablo Martin+9−01 file
No security note in commit
Open full analysis →Source commit ↗
Low 43 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

refactor: Use u64 over size_t for all cache sizes to fix a 32-bit overflow

This commit fixes a bug in Bitcoin Core that only affects 32-bit computers. When the program calculated how much database cache to allocate, it multiplied a large default cache value by 10. On 32-bit systems that multiplication overflowed,…

Integer overflow in cache-size calculation on 32-bit systemsUnsigned multiplication overflow explicitly mentioned in commit message with runtime sanitizer outputType promotion from size_t to uint64_t to prevent platform-dependent width issues
fabafd91by MarcoFalke+37−285 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 23 AI analysisMessage 85 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

wallet: Use Descriptor::CanSelfExpand() in CanGetAddresses()

This is a small Bitcoin Core wallet change that lets the wallet generate addresses from certain descriptors even when it does not have private keys and has already used up its pre-derived address range. It only affects descriptors that can…

Changes address-derivation gating logic in wallet codeExpands conditions under which addresses can be produced without private keysNo explicit security framing, CVE, or advisory language in commit
1e996640by Ava Chow+1−11 file
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 58 · Thin
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

descriptor: Add CanSelfExpand()

This commit adds a new helper method called CanSelfExpand() to Bitcoin Core's descriptor system. It lets the code ask whether a wallet descriptor can produce its Bitcoin address(es) on its own, without needing a saved cache or private keys…

New API surface added to descriptor subsystem (CanSelfExpand)No change to existing expansion, signing, or key-derivation logicNo bounds, memory, or cryptographic operations modified
d2ee9227by Ava Chow+57−184 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: introduce NodeSigner, run feature_taproot.py without wallet compiled

This commit only changes Bitcoin Core's internal functional test code. It introduces a small test helper class called NodeSigner so that one specific test (feature_taproot.py) can run even when Bitcoin Core is compiled without its built-in…

91586f70by Sebastian Falbesoner+49−142 files
No security note in commit
Open full analysis →Source commit ↗
Informational 17 AI analysisMessage 83 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

scripted-diff: Rename `StatusLevel::{INFO,WARN,ERR}`

This is a straightforward code cleanup change that renames three internal status labels (INFO, WARN, ERR) to different capitalisation (Info, Warn, Error) because one of those names clashed with a system macro on illumos operating systems w…

41ceea40by Hennadii Stepanov+24−242 files
No security note in commit
Open full analysis →Source commit ↗
Informational 12 AI analysisMessage 72 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: cover common HTTP attacks and common malformed requests

This commit only adds new automated tests to Bitcoin Core. It does not change the actual server code that handles HTTP requests. The tests verify that the existing HTTP server correctly rejects or handles common web attacks such as path tr…

Adds regression tests for HTTP security boundary conditionsDocuments libevent leniency on duplicate Content-Length and line foldingNo changes to src/httpserver.cpp or any production HTTP handling code
881d4b6cby Matthew Zipkin+210−121 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 72 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: add extendedkey.py unit tests by using BIP32 test vectors

This commit only adds new unit tests for Bitcoin Core's internal test framework. It checks that a helper class for BIP32 extended keys produces the well-known public test-vector outputs. No production wallet, consensus, or networking code …

d2a03d50by rkrux+36−02 files
No security note in commit
Open full analysis →Source commit ↗
Informational 21 AI analysisMessage 96 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Squashed 'src/secp256k1/' changes from 7262adb4b4..bd0287d650

This commit is a routine subtree update of the secp256k1 cryptographic library inside Bitcoin Core. It pulls in a batch of upstream secp256k1 changes: build-system cleanups, new tests, documentation fixes, a minor MuSig nonce-generation cl…

MuSig secret-key wipe now happens on both success and failure paths in `secp256k1_musig_nonce_gen_counter`New `_ecmult_gen_ge` helper clears Jacobian intermediate state to reduce potential side-channel leakageForce-inlining of performance-critical field operations (mul/sqr) is a hardening/performance change, not a vulnerability fix
1f3f0a4eby fanquake+257−9025 files
No security note in commit
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 78 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

rpc: tighten setmocktime upper bound to UINT32_MAX

This commit tightens the maximum allowed mock time in Bitcoin Core's testing-only RPC command `setmocktime` from the year 2262 down to the year 2106 (the maximum value a 32-bit unsigned timestamp can hold). The change prevents two types of…

Integer overflow (int64_t) in time arithmetic when offsets are added to an overly large mock timeSilent truncation to uint32_t when mocked time is assigned to block header nTime fieldsUBSan/integer sanitizer findings motivating the bound change
406c2348by stringintech+6−63 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Repository ledger

Explore captured commits

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

Security candidatetest: cover common HTTP attacks and common malformed requestsby Matthew Zipkin · 881d4b6c · Jun 22, 2026 · 1 fileMessage 72 · AdequateInformational 12Details
Commit message · Matthew Zipkin

test: cover common HTTP attacks and common malformed requests

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
explicit security language
AI analysis · Informational 12/100

This commit only adds new automated tests to Bitcoin Core. It does not change the actual server code that handles HTTP requests. The tests verify that the existing HTTP server correctly rejects or handles common web attacks such as path traversal, request smuggling, null bytes, invalid HTTP versions, and malformed authentication headers. Because no production code is modified, the commit itself does not introduce or fix a vulnerability.

Security candidatetest: add extendedkey.py unit tests by using BIP32 test vectorsby rkrux · d2a03d50 · Jun 19, 2026 · 2 filesMessage 72 · AdequateInformational 15Details
Commit message · rkrux

test: add extendedkey.py unit tests by using BIP32 test vectors

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
secret or key materialfuzzing or regression evidence
AI analysis · Informational 15/100

This commit only adds new unit tests for Bitcoin Core's internal test framework. It checks that a helper class for BIP32 extended keys produces the well-known public test-vector outputs. No production wallet, consensus, or networking code is changed, and no security bug is being fixed.

Security candidateSquashed 'src/secp256k1/' changes from 7262adb4b4..bd0287d650by fanquake · 1f3f0a4e · Jun 18, 2026 · 25 filesMessage 96 · StrongInformational 21Details
Commit message · fanquake

Squashed 'src/secp256k1/' changes from 7262adb4b4..bd0287d650

bd0287d650 Merge bitcoin-core/secp256k1#1859: field: force-inline 5x52 mul and sqr
fdcf2d41e2 Merge bitcoin-core/secp256k1#1865: test: enable -Wunused-function in test suite (Fix #1831)
b2d2bd362d Merge bitcoin-core/secp256k1#1860: cmake: Emulate Libtool's behavior on NetBSD and OpenBSD
87bec430bf Merge bitcoin-core/secp256k1#1867: test: musig: fix dead "aggnonce encodes two points at infinity" check
71fcd8410e field: force-inline 5x52 mul and sqr
a77dacad9a test: enable -Wunused-function in test suite (Fix #1831)
aea86bc350 Merge bitcoin-core/secp256k1#1864: test: refactor: simplify tests by using `_ecmult_gen_ge` helper, add test
2ee79e77e6 test: add unit test for `_ecmult_gen_ge`
d7125e517d test: musig: fix dead "aggnonce encodes two points at infinity" check
1eab757207 cmake: Fix shared library versioning on OpenBSD
a401c5145a cmake: Fix shared library versioning on NetBSD
8a0f4002c7 cmake, refactor: Improve documenting in `SetLibtoolAbiVersion` module
acf2084aa7 cmake, refactor: Introduce `SetLibtoolAbiVersion` module
0f4a7e6bf9 Merge bitcoin-core/secp256k1#1855: bench: add internal benchmark for `secp256k1_fe_normalize_var`
ca68daf8e1 test: refactor: simplify tests by using `_ecmult_gen_ge` helper
13db747f2b Merge bitcoin-core/secp256k1#1861: refactor: introduce `_ecmult_gen_ge` helper (preventing accidental gej leaks)
9e017e5062 refactor: rename `_ecmult_gen` -> `_ecmult_gen_gej` for consistency
a3296d5e23 refactor: introduce `_ecmult_gen_ge` helper (preventing accidental gej leaks)
c63062380f Merge bitcoin-core/secp256k1#1852: Add exhaustive test for ECDH module
240578eef5 bench: add internal benchmark for `secp256k1_fe_normalize_var`
5698e66c64 Add exhaustive test for ECDH module
a39093de15 Merge bitcoin-core/secp256k1#1851: doc: correct API docs for ECDSA signing out-params (s/array/signature object/)
8363a2d8d1 Merge bitcoin-core/secp256k1#1854: tests: compare full MuSig aggregate nonce
af1fdd1215 tests: compare full MuSig aggregate nonce
40a0d874a6 doc: correct API docs for ECDSA signing out-params (s/array/signature object/)
b11340b3ce Merge bitcoin-core/secp256k1#1849: musig: always clear out secret key in `secp256k1_musig_nonce_gen_counter`
8479eafa57 musig: always clear out secret key in `secp256k1_musig_nonce_gen_counter`
c1a9e4fe64 Merge bitcoin-core/secp256k1#1848: ci: Bump GCC snapshot major version to 17
3cca6451a2 ci: Bump GCC snapshot major version to 17
ea174fe045 Merge bitcoin-core/secp256k1#1846: ci: Replace `ilammy/msvc-dev-cmd` with manual MSVC setup
285cb788e9 ci: Replace `ilammy/msvc-dev-cmd` with manual MSVC setup

git-subtree-dir: src/secp256k1
git-subtree-split: bd0287d650c24dc41e0362675a9f6a49ee952def

96/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
secret or key materialsigning boundarycryptography-sensitive path
AI analysis · Informational 21/100

This commit is a routine subtree update of the secp256k1 cryptographic library inside Bitcoin Core. It pulls in a batch of upstream secp256k1 changes: build-system cleanups, new tests, documentation fixes, a minor MuSig nonce-generation cleanup, and a refactor that adds a helper for converting secret-key multiplications into plain (non-Jacobian) curve points. None of the changes appear to fix an exploitable vulnerability in Bitcoin Core itself, and the commit message does not describe any security issue.

Security candidaterpc: tighten setmocktime upper bound to UINT32_MAXby stringintech · 406c2348 · Jun 13, 2026 · 3 filesMessage 78 · AdequateLow 35Details
Commit message · stringintech

rpc: tighten setmocktime upper bound to UINT32_MAX

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

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

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

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

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

rpc: expand decodepsbt output script with explicit fields

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

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

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

Security candidatedoc: use signing pubkey instead of aggregate xonly keyby kevkevinpal · b3371029 · Jun 12, 2026 · 1 fileMessage 50 · ThinTriage 18Details
Commit message · kevkevinpal

doc: use signing pubkey instead of aggregate xonly key

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing boundary
Security candidatewallet: reject sendtoaddress and sendmany for external signersby Sjors Provoost · 2fe34808 · Jun 11, 2026 · 2 filesMessage 83 · StrongInformational 24Details
Commit message · Sjors Provoost

wallet: reject sendtoaddress and sendmany for external signers

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

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

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

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

Security candidatedoc: replace stale signtransaction wording with current signtx flowby woltx · 4fdd4d8d · Jun 11, 2026 · 2 filesMessage 81 · StrongInformational 15Details
Commit message · woltx

doc: replace stale signtransaction wording with current signtx flow

The protocol documentation still described a "signtransaction" command
driven by sendtoaddress and sendmany. Those RPCs never gained external
signer support: it was effectively precluded by #21201, which was
merged a few days before external signer support landed in #16546, so
the interaction was missed in review (#33112 has a commit making the
rejection explicit). Spending from an external signer wallet uses
send/sendall (and bumpfee for fee-bumping), which invoke the signer
with `<cmd> --stdin` and pass the `signtx` subcommand and PSBT over
stdin.

Update the spending example and the protocol description accordingly,
using `bitcoin rpc` for the example since it enables -named by default.

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100

This commit only updates documentation and a code comment to match how external (hardware) signers actually work in current Bitcoin Core. It does not change any executable code, RPC behavior, or security logic. There is no security vulnerability here.

Security candidateci: Alpine 3.24by fanquake · 3be1115a · Jun 11, 2026 · 1 fileMessage 40 · ThinTriage 10Details
Commit message · fanquake

ci: Alpine 3.24

40/100 · ThinMessage clarity
✓ Subject identifies a change✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
authentication path
Security candidatefuzz: test non-max descriptor satisfaction weightby woltx · 526aae37 · Jun 10, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · woltx

fuzz: test non-max descriptor satisfaction weight

Also assert that the availability of the satisfaction weight estimate
does not depend on the signature-size assumption, and that assuming
non-max-size signatures never increases the estimate.

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

This commit is a small fuzz-test improvement. It fixes an obvious test bug where the same function was being called twice with the same argument, and instead calls it with both possible arguments, then adds assertions about the results. It does not change any production wallet, consensus, or networking code, and there is no security fix or vulnerability indicated.

Security candidateiwyu: Fix warnings in `src/bench` and treat them as errorby Hennadii Stepanov · 6751a323 · Jun 10, 2026 · 58 filesMessage 50 · ThinInformational 15Details
Commit message · Hennadii Stepanov

iwyu: Fix warnings in `src/bench` and treat them as error

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
cryptography-sensitive pathsigning or wallet path
AI analysis · Informational 15/100

This commit is a code cleanup that adjusts which C++ header files are included in the project's benchmark code and a few related source files. It enables a stricter 'include what you use' (IWYU) check for the benchmark directory so missing or unnecessary #include lines are treated as errors in continuous integration. There is no change to program logic, no bug fix, and no security-relevant behavior.

Security candidatefuzz: reset the mockable steady clock between iterationsby Hao Xu · 19b32a2e · Jun 7, 2026 · 1 fileMessage 83 · StrongInformational 24Details
Commit message · Hao Xu

fuzz: reset the mockable steady clock between iterations

CheckGlobalsImpl's constructor runs at the start of every fuzz iteration
and already resets the global RNG flags and the mockable NodeClock via
SetMockTime(0s), but it never reset the mockable steady clock. A value
written to g_mock_steady_time by one input therefore leaked into the
next one. For example, FuzzedSock's constructor calls
SetMockTime(INITIAL_MOCK_TIME) and never clears it, so the mocked steady
time stays set for all subsequent iterations.

Reset MockableSteadyClock symmetrically with NodeClock so each input
starts from an unmocked steady clock. This also brings the steady clock
under the same discipline as the system clock: a target that reads
MockableSteadyClock::now() without first mocking it is now caught by the
existing g_used_system_time check instead of silently reusing a leaked
value.

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

This is a small fix inside Bitcoin Core's internal fuzz-testing harness. Fuzz testing feeds the program many random inputs in sequence; the harness is supposed to reset global state between inputs so each test starts clean. The reset code already cleared the regular mock clock but forgot to clear a separate 'steady' mock clock. That meant one fuzz input could leave a fake time value behind, polluting later inputs and making fuzz results less reliable. The patch adds one line to clear that steady mock clock too. It is a test-infrastructure bug, not a vulnerability in live Bitcoin node code.

Security candidateBIP434: FEATURE message supportby Anthony Towns · 6a129983 · Jun 4, 2026 · 10 filesMessage 58 · ThinInformational 23Details
Commit message · Anthony Towns

BIP434: FEATURE message support

BIP434 defines FEATURE messages which are sent between VERSION and VERACK
to indicate support for new P2P protocol features. This commit provides
the infrastructure for easily using BIP434 negotiation when implementing
such new P2P protocol features. Note that advertised protocol version
is bumped to 70017, as per BIP434's specification.

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
Why it was queued
cryptography-sensitive pathparser or protocol path
AI analysis · Informational 23/100

This commit adds support for a new Bitcoin peer-to-peer message type called FEATURE, defined in BIP 434. It is infrastructure for negotiating optional protocol features during the initial handshake, not a finished feature itself. The code bumps the protocol version to 70017, registers the new message, and adds basic rules: FEATURE messages must appear between VERSION and VERACK, the peer must have negotiated the new version, and the payload must contain a feature ID of at least 4 characters plus up to 512 bytes of feature data. Unknown feature IDs are ignored. There is no immediate security issue visible in the diff, but the change touches network message handling and version negotiation, which are sensitive parts of the node.

Security candidateqa: Silence socket.timeout exception when substituting it for a JSONRPCExceptionby Hodlinator · f42226d5 · Jun 4, 2026 · 1 fileMessage 65 · AdequateTriage 10Details
Commit message · Hodlinator

qa: Silence socket.timeout exception when substituting it for a JSONRPCException

This prevents "During handling of the above exception, another exception occurred:" and an extra traceback.

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
authentication path
Security candidatep2p: Saturate LocalServiceInfo::nScore updates at INT_MAXby codeabysss · 2189a6f5 · Jun 3, 2026 · 2 filesMessage 88 · StrongLow 37Details
Commit message · codeabysss

p2p: Saturate LocalServiceInfo::nScore updates at INT_MAX

Signed overflow on nScore updates is undefined behavior. Use
SaturatingAdd in AddLocal() and SeenLocal() so increments saturate at
INT_MAX instead of overflowing.

Add unit test coverage for saturation in both code paths.

88/100 · StrongMessage clarity
✓ Specific, 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 · Low 37/100

This commit fixes a subtle programming bug in Bitcoin Core's peer-to-peer networking code. A local network address score counter could, in theory, overflow when repeatedly incremented, which is 'undefined behavior' in C++ and could potentially cause the program to misbehave or crash. The fix makes the counter stop increasing once it reaches the maximum integer value, and adds tests to confirm that behavior.

Security candidatemigrate: Handle HD chains that have identical seeds but different IDsby Ava Chow · de92208c · Jun 3, 2026 · 2 filesMessage 78 · AdequateLow 41Details
Commit message · Ava Chow

migrate: Handle HD chains that have identical seeds but different IDs

The seed ID is calculated from a pubkey produced by treating the seed as
a private key. This calculation includes a pubkey compression parameter,
even thought that compression is completely irrelevant for the usage of
the seed as a BIP 32 seed. Thus migration should detect if a seed has
been used multiple times by checking if the computed master key was
already processed.

The spkm_migration fuzzer needs to have it's added descriptors
accounting to be updated for this fix.

78/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
secret or key materialfuzzing or regression evidencesigning or wallet path
AI analysis · Low 41/100

This commit fixes a wallet migration bug in Bitcoin Core. When converting old-style wallets to modern descriptor wallets, the migration code could process the same BIP 32 seed more than once because it identified seeds by a 'seed ID' that changes depending on a technical detail (public-key compression) that does not actually affect the seed's value. The fix now detects duplicate seeds by comparing the derived master extended public key, preventing redundant or conflicting descriptors from being created during migration. There is no direct evidence this is exploitable as an attack; it appears to be a correctness and robustness fix.

Security candidateversionbits: Limit live activation params and activation warnings per BIP323by Anthony Towns · f802edf5 · Jun 1, 2026 · 5 filesMessage 75 · AdequateLow 27Details
Commit message · Anthony Towns

versionbits: Limit live activation params and activation warnings per BIP323

Test bits are conserved. This only has an effect on the warnings.

Co-Authored-By: Antoine Poinsot <mail@antoinep.com>

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
secret or key material
AI analysis · Low 27/100

This Bitcoin Core change narrows which version bits trigger live 'unknown soft fork' warnings from 29 bits down to 5, following the new BIP323 specification. It does not change how many bits exist in block headers or how test networks behave; it only reduces false or misleading upgrade alerts for bits that the network no longer treats as active deployment candidates.

Security candidatekey: validate BIP32 seed length in CExtKey::SetSeedby Muhammad · 2cf9d79d · May 28, 2026 · 1 fileMessage 81 · StrongLow 42Details
Commit message · Muhammad

key: validate BIP32 seed length in CExtKey::SetSeed

BIP32 specifies that seed must be between 128 and 512 bits
(16 to 64 bytes). CExtKey::SetSeed currently accepts any length,
including empty seeds, which could lead to weak master keys.

Add an Assert at the start of SetSeed to enforce the valid seed
length range.

Fixes #35308

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
secret or key materialdefensive validation
AI analysis · Low 42/100

This commit adds a safety check to Bitcoin Core's code that creates master cryptographic keys from a seed. The BIP32 standard says seeds must be 16 to 64 bytes long, but the function previously accepted any length, including empty seeds. The fix rejects out-of-range seeds with an internal assertion. It is a hardening change rather than a fix for an active exploit path, because callers in the current codebase already supply valid-length seeds.

Security candidateguix, refactor: Remove unused `out_name()` functionby Hennadii Stepanov · d4c69a72 · May 28, 2026 · 1 fileMessage 50 · ThinTriage 12Details
Commit message · Hennadii Stepanov

guix, refactor: Remove unused `out_name()` function

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
boot or update path
Security candidateci: Exclude feature_dbcrash.py under --v2transport --usecliby MarcoFalke · faf14755 · May 28, 2026 · 1 fileMessage 100 · StrongTriage 18Details
Commit message · MarcoFalke

ci: Exclude feature_dbcrash.py under --v2transport --usecli

The test should now be passing, but it is slow.

For example, the commit that enabled the test, took ~47 minutes on a
fast CPU, but using a heavy debug build:

https://github.com/bitcoin/bitcoin/actions/runs/26434786214/job/77815064664?pr=35363#step:11:4101

...
Model name: AMD Ryzen 9 7950X3D 16-Core Processor
...
C++ compiler .......................... GNU 15.2.0, /usr/bin/g++
CMAKE_BUILD_TYPE ...................... Debug
Preprocessor defined macros ........... DEBUG DEBUG_LOCKORDER DEBUG_LOCKCONTENTION RPC_DOC_CHECK ABORT_ON_FAILED_ASSUME _GLIBCXX_DEBUG _GLIBCXX_DEBUG_PEDANTIC _LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_DEBUG
C++ compiler flags .................... -m64 -O0 -ftrapv -O1 -g3 -g3 -std=c++20 ...
...
feature_dbcrash.py | ✓ Passed | 2806 s

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✓ Links an issue, advisory, or supporting reference
Why it was queued
defensive validationauthentication path
Security candidatewallet, test: remove -walletrbf startup option from rpc_psbt.pyby rkrux · a2a2b174 · May 27, 2026 · 3 filesMessage 75 · AdequateInformational 15Details
Commit message · rkrux

wallet, test: remove -walletrbf startup option from rpc_psbt.py

Also, include PSBT_GLOBAL_FALLBACK_LOCKTIME key/value while making the PSBT v2
blank for combinepsbt RPC.

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
signing boundarysigning or wallet path
AI analysis · Informational 15/100

This commit only changes Bitcoin Core's own test code. It removes the obsolete -walletrbf startup option from two functional tests and adds a missing PSBT v2 field (fallback locktime) to a test helper that creates blank PSBTs. There is no change to production wallet or node code, so it does not affect real users' funds, transactions, or network security.

Security candidateutil: Require integers for SaturatingAdd() and AdditionOverflow()by Hodlinator · 0774eaaf · May 25, 2026 · 1 fileMessage 73 · AdequateLow 33Details
Commit message · Hodlinator

util: Require integers for SaturatingAdd() and AdditionOverflow()

Previously we could fall back to using an unspecialized implementation of std::numeric_limits<T> which would compile as long as the numeric operators existed, but would return 0 for min() & max().

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
memory safety
AI analysis · Low 33/100

This change tightens two low-level math helper functions so they only accept whole-number (integer) types. Previously, a non-integer type could slip through and silently produce wrong min/max values because the generic fallback for numeric limits returns 0. The patch prevents that misuse at compile time rather than relying on an internal check.

Security candidatetest: remove the lazy import of util in authproxyby rkrux · 7be0d6fa · May 25, 2026 · 1 fileMessage 82 · StrongTriage 10Details
Commit message · rkrux

test: remove the lazy import of util in authproxy

This lazy import prompted the removal of the circular dependency, so
remove it now that we can.

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
Why it was queued
authentication path
Security candidatetest: move out JSONRPCException from authproxy to utilby rkrux · 779f4446 · May 25, 2026 · 10 filesMessage 100 · StrongInformational 15Details
Commit message · rkrux

test: move out JSONRPCException from authproxy to util

So that util is not dependent on authproxy at all and going
forward authproxy can use util methods.

Reviewing with --color-moved=dimmed-zebra option can be helpful.

100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
signing or wallet pathauthentication path
AI analysis · Informational 15/100

This is a harmless internal code cleanup in Bitcoin Core's test suite. It moves a Python exception class named JSONRPCException from one test helper file (authproxy.py) to another (util.py) and updates the files that import it. There is no change to how Bitcoin nodes behave, no fix for a security bug, and no change that affects real users or live networks.

Security candidateci: switch to GitHub cache for all runnersby willcl-ark · c03107ac · May 22, 2026 · 5 filesMessage 80 · StrongTriage 0Details
Commit message · willcl-ark

ci: switch to GitHub cache for all runners

Cirrus is winding down and github now offers more than 10GB cache.

Switch to GH cache for all runner-types. Simplify docker build arg
construction, and reduce the number of needed action permissions.

80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Why it was queued
credential or privilege statedocumentation-only discount