BC
← All projectsBitcoin Core

Bitcoin Core

The Bitcoin network's reference node and wallet implementation.

BitcoinSupply chainNormal
Repository coverage

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

314security candidates665second-pass queue2999AI analyses
155commits · 30 days
332commits · 60 days
1303commits · 180 days
2860commits · 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.

71/100 average clarity
1162Strong · 80–100
1206Adequate · 60–79
701Thin · 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.
merge-script1964487389
Antoine Poinsot22422170
Ava Chow19165185068
MarcoFalke41421408074
fanquake23121228058
Lőrinc18121177081
Hennadii Stepanov22316211064
rkrux57957074
Sjors Provoost89889074
Sebastian Falbesoner33733073
David Gumberg55655072
Pieter Wuille95595066
Analysis record

Published AI watches

Last scanned 4 minutes ago

Informational 19 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35675: mining: add block template manager

This is a large internal code reorganization (refactor) in Bitcoin Core. It creates a new BlockTemplateManager class that takes over block-template creation, block submission, and tip-waiting helpers that were previously spread across seve…

Large refactor touching mining, RPC, interfaces, and test shutdown pathsNew object lifetime dependency: BlockTemplateManager holds references to mempool, chainman, and notifications; explicit reset ordering added in Shutdown/InitAndLoadChainstate/test setupsRemoval of early-init node.mining interface; BlockTemplateManager is now created after chainstate load, with a comment that it must exist before setChainstateLoaded(true) unblocks IPC waiters
5c726f20by Ryan Ofsky+561−44926 files
No security note in commit
Informational 12 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35301: Silent Payments: Implement bip352 (take 2)

This commit adds the first implementation of BIP352 (Silent Payments) to Bitcoin Core. Silent Payments are a new type of privacy-preserving Bitcoin address that lets someone receive payments without publicly revealing a fixed address. The …

New cryptographic feature implementation (BIP352 Silent Payments)Extensive use of secp256k1 silentpayments moduleInput public key extraction from P2PKH, P2WPKH, P2SH-P2WPKH, and P2TR inputs
be5d0b55by Ava Chow+6951−010 files
No security note in commit
Low 45 AI analysisMessage 96 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35440: wallet: check descriptor cache xpub length before decoding

This update fixes a wallet database loading bug where a damaged or tampered Bitcoin wallet file could cause the program to read past the end of a stored extended public key (xpub). The patch makes the loader check the stored xpub length be…

Out-of-bounds read in wallet descriptor cache deserializationASan container-overflow triggered by malformed on-disk recordMissing length validation between record size prefix and fixed-size decoder
b3f846ecby Ava Chow+225−8511 files
Vendor flagged security relevance
Informational 20 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35813: wallet, rpc: Add listrawtransactions RPC

This commit adds a new wallet RPC called listrawtransactions to Bitcoin Core. It is a feature addition that lets users list every transaction their wallet knows about, including internal transfers and consolidations that the existing listt…

No security-relevant bug fix or vulnerability patch is present in the diff.New RPC exposes additional wallet transaction metadata, but only to callers already authorized for wallet RPCs.Code is a refactor of existing gettransaction logic into shared helpers; no new cryptographic, network, or consensus code.
2b95b45aby Ava Chow+334−276 files
No security note in commit
Moderate 68 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35752: wallet: make encryption state updates atomic

This Bitcoin Core update fixes several wallet bugs where a failed database write could leave a wallet in an inconsistent state. For example, encrypting a wallet or changing its passphrase could appear to succeed in memory while the change …

Atomicity fix for encryption state and descriptor key persistenceFailure to persist master key during encryption previously reported success in memoryPassphrase change could activate new passphrase only in memory
7ee3d622by Ava Chow+379−16418 files
Vendor flagged security relevance
Informational 15 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35619: test: ExtendedPrivateKey follow-ups

This commit only changes Bitcoin Core's internal functional test code. It replaces hard-coded test keys and addresses with ones generated from a new test helper class, and unifies how tests tell nodes not to create a default wallet. There …

248ce46fby merge-script+18−244 files
No security note in commit
Informational 15 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36261: test: cover PSBT unknown field merging

This commit only adds a new automated test to Bitcoin Core. It checks that when two partially-signed Bitcoin transactions (PSBTs) are combined, any custom 'unknown' data fields attached to them are preserved correctly. There is no change t…

bbc40edeby merge-script+130−01 file
No security note in commit
Informational 18 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36230: wallet: Improve `HasWalletDescriptor` performance and other canonical descriptor string followups

This is a Bitcoin Core wallet maintenance patch. It speeds up a wallet function that checks whether a descriptor already exists by caching a hash of the descriptor's canonical text, instead of rebuilding that text every time. It also tidie…

No security-relevant signal in commit message or diffChange is described as performance improvement and code cleanupBackwards-compatibility test notes a known miniscript wallet loading incompatibility between v31.0/v31.1 and other versions, but this is a documented compatibility quirk, not a vulnerability
4a583f38by merge-script+97−429 files
No security note in commit
Informational 21 AI analysisMessage 81 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36297: rpc: Correct invalid OpenRPC defaults

This is a documentation-only fix for Bitcoin Core's machine-readable RPC help data. It changes several default values from literal strings to 'hint' labels (because the real default depends on context) and corrects one boolean default from…

OpenRPC schema/default mismatch correctionRPC help metadata type correction (string 'false' to boolean false)No executable code path changes
5f05d8c5by merge-script+6−63 files
No security note in commit
Informational 20 AI analysisMessage 68 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

rpc: Correct OpenRPC default metadata

This commit fixes documentation metadata for six Bitcoin Core RPC arguments. It changes how default values are described so that automatically generated API docs and schemas are accurate. The actual behavior of the software when running is…

No runtime code changesOnly RPC help/schema metadata modifiedVendor explicitly states runtime behavior is unchanged
b7f740c5by will+6−63 files
No security note in commit
Informational 24 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36286: crypto: Fix MuHash3072 division by itself

This commit fixes a bug in Bitcoin Core's MuHash3072 cryptographic code where dividing a MuHash object by itself (x /= x) produced the wrong mathematical result. The fix is straightforward: the code now saves the divisor's numerator before…

Cryptographic correctness bug in MuHash3072 division operatorSelf-aliasing in operator/= produces incorrect 1/D result instead of empty setNo production code path identified that triggers self-division
d48e76e6by merge-script+11−13 files
No security note in commit
Informational 18 AI analysisMessage 93 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36285: refactor: Use static const over inline const to work around ld64 bug

This is a build-compatibility fix, not a security patch. It changes how some constant data is stored internally so that Apple's macOS linker (ld64) can build Bitcoin Core correctly. The change avoids a linker bug that caused build failures…

No security-relevant code logic changedChange is a linker bug workaround, not a vulnerability fixConstants remain read-only; no new attack surface introduced
ad97933aby merge-script+8−82 files
No security note in commit
Informational 23 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#34861: wallet: Add importdescriptors interface

This commit refactors Bitcoin Core's wallet descriptor import feature so the same logic can be used by both the RPC command and a new GUI-facing interface. It also tightens one input rule: negative timestamps are now rejected, and the mini…

Refactor of security-sensitive wallet import code into shared CWallet pathNew input validation: negative timestamps rejected for importdescriptorsCentralization of descriptor range bound checks in CheckDescriptorRangeBounds
2bbbeaa6by Ava Chow+619−26415 files
No security note in commit
Low 30 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36260: torcontrol: Use reconnect backoff after dropped connections

This change fixes a bug in how Bitcoin Core reconnects to the Tor control port. A previous update accidentally removed the wait time between reconnect attempts when an already-established Tor control connection was dropped. Without the wai…

Uncontrolled retry loop causing resource exhaustion and log floodingLocal-only Tor control port interaction; no remote attacker path by defaultRegression introduced by prior refactor (#34158) and restored here
fb68c270by merge-script+32−332 files
No security note in commit
Informational 18 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36256: guix: Update osslsigncode to 2.14

This change updates the Windows code-signing tool used in Bitcoin Core's reproducible build process. It fixes a build-time failure where signature verification could not complete because a certificate package was missing and the old tool v…

Tooling update in release signing pipelineRestores CA certificate store for signature verificationDisables CRL/CDP network lookups during verification
7dedc454by Hennadii Stepanov+22−22 files
No security note in commit
Informational 19 AI analysisMessage 96 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#34566: feature: Use different datadirs for different signets

This change lets Bitcoin Core store different custom signet blockchains in separate data folders, using a unique suffix derived from each signet's network identifier. It also adds a friendlier error hint in bitcoin-cli when an RPC authenti…

Data isolation between distinct custom signets reduces risk of cross-network state corruption or accidental mainnet/testnet confusionNo memory-safety, cryptographic, or consensus changes observedNo privilege escalation, remote code execution, or denial-of-service vectors introduced in the diff
d32a515fby merge-script+211−4412 files
No security note in commit
Informational 19 AI analysisMessage 81 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36251: rest: add `generated` and `height` to spenttxouts JSON

This change adds two extra pieces of information—whether a spent output came from a coinbase transaction and the block height at which it was created—to a Bitcoin Core REST API endpoint. It is a feature/parity improvement to make the REST …

dadca55fby merge-script+13−54 files
No security note in commit
Low 33 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#34743: p2p: don't disconnect manual peers for block stalling

This change makes Bitcoin Core treat manually-added peers (from -addnode, -connect, or the addnode RPC) more gently during Initial Block Download (IBD). Previously, if such a peer was slow or stalled at sending blocks, the node would disco…

Behavior change in peer disconnection logic during IBDManual peers exempted from block-stalling disconnectionNew per-peer cooldown state m_block_download_paused_until introduced
cff00c54by merge-script+148−168 files
No security note in commit
Informational 20 AI analysisMessage 96 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36186: test: return False for a too-short ECDSA signature

This is a small fix in Bitcoin Core's own test helper code. A helper function used only in tests could crash with an IndexError when given an extremely short fake signature, instead of cleanly returning False. The change moves a length che…

Out-of-order bounds check leading to IndexError in test helperRegression test added for malformed short DER signaturesTest-only code path, no production validation logic changed
76343a09by merge-script+11−21 file
No security note in commit
Informational 15 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36083: test: cover getrawtransaction on a stale block via txindex

This commit only adds a new functional test to Bitcoin Core. It checks that the getrawtransaction RPC can retrieve a stale block's coinbase transaction via the optional txindex, and that the response correctly shows the block is no longer …

dd3c62c5by merge-script+41−341 file
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.

Security candidatenet_processing: add a global delay queue for sending txsby Anthony Towns · df31ee57 · Jul 11, 2026 · 2 filesMessage 90 · StrongModerate 63Details
Commit message · Anthony Towns

net_processing: add a global delay queue for sending txs

Without the per-peer rate limiting, nodes can act as an amplifier for
transaction spam -- receiving many transactions from one node, but
relaying each of them to over 100 other nodes. Limit the impact of this
by providing a global rate limit.

This is implemented using dual token buckets, one that consumes a
token for every transaction, and one that consumes a token for every
serialized byte. This rate limits both per-tx resource usage (eg INV
messages) and overall relay bandwidth.

Main bucket parameters:
* Count: 14tx/s rate, 420tx (30s) capacity
* Size: 12MB/600s rate (4-6 blocks per target block interval), 50MB capacity

The size bucket is expected to be large enough to almost never have an
impact in normal usage, even during transaction storms, and is primarily
intended to mitigate attack-like scenarios.

Outbound connections get a separate pair of buckets, with rates boosted
by a 2.5x multiplier.

This avoids the excessive memory and CPU usage due to the 100x multiplier
from the queues being per-peer.

Note that this also reduces the size of INV messages we send for general
tx relay back to a more reasonable level of under 600 txs in 99.999%
of cases.

90/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
Why it was queued
explicit security language
AI analysis · Moderate 63/100

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 like an amplifier for spam and wasting bandwidth and CPU. The new code caps both the number of transactions announced per second and the total bytes announced, with higher limits for outbound peers. It also changes transaction broadcast to use a single shared backlog sorted by mempool quality, rather than per-peer queues. This is a defensive hardening change, not an active vulnerability fix, and the commit message explicitly frames it as mitigating transaction-spam amplification.

Security candidatechainparams: delete my DNS seedby Pieter Wuille · d9080639 · Jul 9, 2026 · 2 filesMessage 45 · ThinInformational 19Details
Commit message · Pieter Wuille

chainparams: delete my DNS seed

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
seed or entropy path
AI analysis · Informational 19/100

A Bitcoin Core developer removed their own DNS seed (seed.bitcoin.sipa.be, run by Pieter Wuille) from the list of hardcoded network seeds that help new Bitcoin nodes find peers when they first start up. This is a routine operational/maintenance change, not a code vulnerability fix. It slightly reduces the number of default seed options available to users.

Security candidatetest: Redeclare variable as signed in `util_tests`by rustaceanrob · cd2a4bc5 · Jul 9, 2026 · 1 fileMessage 95 · StrongInformational 15Details
Commit message · rustaceanrob

test: Redeclare variable as signed in `util_tests`

Assigning `ToIntegral<int64_t>("-1")` to the `optional<uint64_t>` `n`
is a silent underflow. `BOOST_CHECK_EQUAL` then promotes `int` to
`uint64_t`, which also underflows. The correct check is to do this
inline.

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

This is a minor fix to a unit test file. A test variable was being assigned a negative value in an unsigned container, which caused a silent underflow and made the test assertion technically incorrect. The patch changes the test to check the negative result directly without storing it in the wrong type. It does not change any production code or affect real Bitcoin Core behavior.

Security candidatetest: add regression test for in-memory SQLiteDatabase reopenby Pablo Martin · 777d23f2 · Jul 8, 2026 · 1 fileMessage 100 · StrongInformational 24Details
Commit message · Pablo Martin

test: add regression test for in-memory SQLiteDatabase reopen

InMemoryWalletDatabase::Open() now throws to prevent silently returning
a fresh empty connection after close, which would discard all data. Add a
test to pin this behaviour.

Co-authored-by: Jan B <608446+janb84@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✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
access controlfuzzing or regression evidencesigning or wallet path
AI analysis · Informational 24/100

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 previous wallet data. The actual protective change (making Open() throw) is already in the codebase; this commit just pins the behavior with a regression test so it cannot accidentally break in the future.

Security candidaterefactor: Use u64 over size_t for all cache sizes to fix a 32-bit overflowby MarcoFalke · fabafd91 · Jul 8, 2026 · 5 filesMessage 100 · StrongLow 43Details
Commit message · MarcoFalke

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

This is a refactor on 64-bit systems, because size_t is equal to u64.

However, on 32-bit systems, it fixes an integer overflow while calculating the cache sizes:

src/node/caches.cpp:71:49: runtime error: unsigned integer overflow: 471859200 * 10 cannot be represented in type size_t (aka "unsigned int")

This happens while multiplying the default cache size (450MiB) by 10:

index_sizes.tx_index = std::min(total_cache * 10 / 100, ...)
^^^^^^^^^^^^^^^^

The issue was introduced in commit d06dabf26bea7d9ca8d635e8338f64aec74c56a8.

====

Also, add missing includes in touched files, according to IWYU.

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✓ Names security-relevant behavior explicitly
Why it was queued
memory safety
AI analysis · Low 43/100

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, producing a much smaller or incorrect number. The fix changes the internal type from size_t (32-bit on 32-bit systems) to uint64_t (always 64-bit) so the multiplication stays correct. On normal 64-bit computers the change is harmless and just a cleanup.

Security candidatedoc: improve offline-signing-tutorial after 32489by Pablo Martin · 68cb7840 · Jul 3, 2026 · 1 fileMessage 76 · AdequateInformational 15Details
Commit message · Pablo Martin

doc: improve offline-signing-tutorial after 32489

General improvements noted in the #32489 review and deferred by the
author:

- Remove a stale NOTE referencing walletcreatefundedpsbt; the tutorial
was updated to use the send RPC instead.
- Fix listtransactions example output from {...} to [...]; the RPC
returns a JSON array, not an object.

76/100 · AdequateMessage clarity
✓ 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 pathdocumentation-only discount
AI analysis · Informational 15/100

This commit only fixes two small mistakes in a documentation file: it removes an outdated note and corrects a JSON example from curly braces to square brackets. There is no code change and no security impact.

Security candidatedoc: update offline-signing-tutorial to use exportwatchonlywallet rpcby Pol Espinasa · a15bdc05 · Jul 2, 2026 · 1 fileMessage 50 · ThinInformational 15Details
Commit message · Pol Espinasa

doc: update offline-signing-tutorial to use exportwatchonlywallet rpc

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

This is a documentation-only update to the Bitcoin Core offline-signing tutorial. It replaces instructions that used manual descriptor export/import with instructions that use a newer built-in RPC command (exportwatchonlywallet / restorewallet). No code behavior changed, and there is no security vulnerability in the commit.

Security candidatewallet: Use Descriptor::CanSelfExpand() in CanGetAddresses()by Ava Chow · 1e996640 · Jul 2, 2026 · 1 fileMessage 85 · StrongInformational 23Details
Commit message · Ava Chow

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

If a descriptor does not need any caches or private keys in order to
expand, then CanGetAddresses() should return true for that descriptor.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
secret or key materialsigning or wallet path
AI analysis · Informational 23/100

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 expand entirely on their own (public-only, no cached data needed). The change is more of a correctness/availability fix than a security flaw, and there is no direct evidence in the commit that it fixes a vulnerability.

Security candidatedescriptor: Add CanSelfExpand()by Ava Chow · d2ee9227 · Jul 2, 2026 · 4 filesMessage 58 · ThinInformational 19Details
Commit message · Ava Chow

descriptor: Add CanSelfExpand()

CanSelfExpand() reports whether a descriptor can be expanded without
needing any caches or private keys to be provided by the caller of
Expand().

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
Why it was queued
secret or key materialsigning or wallet path
AI analysis · Informational 19/100

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. The change is mostly a new capability with matching tests; it does not by itself fix a known bug or change user-facing behavior, but it lays groundwork that could later be used to avoid loading private keys just to display addresses.

Security candidatetest: introduce NodeSigner, run feature_taproot.py without wallet compiledby Sebastian Falbesoner · 91586f70 · Jun 30, 2026 · 2 filesMessage 100 · StrongInformational 15Details
Commit message · Sebastian Falbesoner

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

Introduce a new simple `NodeSigner` wallet replacement that delegates
signing to a specified node via the `signrawtransactionwithkey` RPC,
and plug in that new class to the functional test feature_taproot.py,
so that it can be ran without the Bitcoin Core wallet compiled.

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

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 wallet. There is no change to production node or wallet code, and nothing in the commit suggests a security bug or fix.

Security candidatescripted-diff: Rename `StatusLevel::{INFO,WARN,ERR}`by Hennadii Stepanov · 41ceea40 · Jun 27, 2026 · 2 filesMessage 83 · StrongInformational 17Details
Commit message · Hennadii Stepanov

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

The `ERR` macro is defined on illumos-based systems in the `regset.h`
header included by the Boost.Test framework, which may cause a
compilation error.

-BEGIN VERIFY SCRIPT-

ren() { sed -i "s/\<$1\>/$2/g" $( git grep -l "$1" ./src/qt/psbtoperationsdialog.* ) ; }
ren StatusLevel::INFO StatusLevel::Info
ren INFO Info
ren StatusLevel::WARN StatusLevel::Warn
ren WARN Warn
ren StatusLevel::ERR StatusLevel::Error
ren ERR Error

-END VERIFY SCRIPT-

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

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 when running tests. It does not change program logic, user-facing behaviour, or security properties. It only prevents a possible build failure on an uncommon platform.

Security candidatebuild: Add option for building for bare metal envsby TheCharlatan · a9a1d92a · Jun 25, 2026 · 5 filesMessage 85 · StrongInformational 15Details
Commit message · TheCharlatan

build: Add option for building for bare metal envs

A bare metal build is now supported by setting CMAKE_SYSTEM_NAME=Generic

Skip the platform-dependent feature checks, such as threads and atomics,
which are typically not available on bare metal. Also only make the
boost headers mandatory if they exist for the target.

Also exclude aes from the crypto library, since that requires the secure
allocator, which uses more advance features, such as mutexes.

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
cryptography-sensitive path
AI analysis · Informational 15/100

This commit adds a new build option for Bitcoin Core that lets developers compile for 'bare metal' environments (systems without a full operating system). It only changes build configuration files to skip features like threads, atomics, and certain crypto components when the special CMAKE_SYSTEM_NAME=Generic setting is used. There is no change to the actual Bitcoin protocol code or to how normal builds work, and nothing in the commit suggests a security vulnerability or fix.

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 · ThinInformational 15Details
Commit message · kevkevinpal

doc: use signing pubkey instead of aggregate xonly key

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

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

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 · ThinInformational 15Details
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
AI analysis · Informational 15/100

This commit simply updates the version number of the Alpine Linux container used in Bitcoin Core's automated testing from Alpine 3.23 to Alpine 3.24. It is a routine CI (Continuous Integration) maintenance change with no visible security relevance.

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.