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.
Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
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
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
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
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.
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
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 …
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…
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
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
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
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
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
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
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
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
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
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 …
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
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
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 …
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.
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.
✓ 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:
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.
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.
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.
✓ 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
✓ 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.
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.
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.
✓ 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.
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.
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.