CommitWatch RSS
BC
← All projectsBitcoin Core

Bitcoin Core

The Bitcoin network's reference node and wallet implementation.

BitcoinSupply chainNormal
Source repository ↗
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 51 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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source commit ↗
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
Open full analysis →Source 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
Open full analysis →Source commit ↗
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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source 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
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 candidateMerge bitcoin/bitcoin#35531: txindex: hash keys and pack positions to reduce disk usageby merge-script · c90c23d3 · Aug 15, 2026 · 12 filesMessage 91 · StrongInformational 18Details
Commit message · merge-script

Merge bitcoin/bitcoin#35531: txindex: hash keys and pack positions to reduce disk usage

25bed560bed370045bead21c27ea21aa228cd963 test: add forward-compat functional test for txindex (sedited)
703304ed8c19d4bc7a2bb7ff0800e5047ccc12c4 doc: add release notes for txindex disk usage and downgrading (Andrew Toth)
8e5320a2d2463131a6442f27d335c0a0f6b577fd tests: cover txindex hash prefix collisions and legacy fallback (Andrew Toth)
b75efa19ba806fbd13604a6bf67ee96a3f9eccf1 txindex: skip bloom filters and legacy lookups for new databases (Andrew Toth)
004d7c098cadecdf1915c77a95d0f856ef0c2ca5 txindex: hash key prefixes and pack block positions (Andrew Toth)
5a255970fd1b02052f669abe064ffa4d4776e40f refactor: move txindex db constants and legacy key to txindex_key.h (Andrew Toth)
327660134cb1629e31ecccb6b5a589e1e27609b2 txindex: pass the full block to DB::WriteTxs (Andrew Toth)
42771e79980cdcedd4876a168d6164c0fd26f5d2 txindex: use a new block locator for downgrade safety (Andrew Toth)
4b08baed72c4dba8d17fe68a85de459fd273d065 txindex: return optional tx and block hash from FindTx (Andrew Toth)

Pull request description:

The current txindex uses the full 32-byte txid as keys, which takes up about 66 GB of disk space today on mainnet. Using a 5-byte key prefix instead drops the disk usage to 26 GB - cutting the size to less than half.

Using the full 32-bytes is unnecessary since a 5-byte salted siphash will produce collisions in about 1 in 1.1 trillion. Some collisions will occur, but the penalty is just an extra disk read, deserialization and hash.
The tx position can be appended to the key instead of used as a value, and a LevelDB iterator can seek to the prefix and then scan for the correct tx. This is an almost identical approach to `txospenderindex`.

Also instead of storing the file position of the block, we can store only the sequence of the connected block and offset of the transaction in the block. This can be packed into a 6-byte key suffix using 3-byte representations of the sequence and offset in the block. The block file can be recovered by the CBlockIndex that is already in memory. The sequence is mapped to the block hash in the db, so we can lookup the block hash to find the CBlockIndex during reads.

If a tx is not found with this method, we fallback to looking up the legacy entry. With this method a user with an existing db can opt to erase the `indexes/txindex` folder and reindex, or keep the current index and new entries will be appended with the smaller footprint.

The time to index was faster on my machine with this method, 1h19m vs current 1h50m.
Lookups are roughly the same, around 0.2ms per lookup with `getrawtransaction`.
When testing on mainnet, I got 894,549 2-way collisions, 395 3-way collision, and 1 4-way collision that worst case could cause an extra 3 false positives when reading.

ACKs for top commit:
l0rinc:
diff reACK 25bed560bed370045bead21c27ea21aa228cd963
sedited:
ACK 25bed560bed370045bead21c27ea21aa228cd963
ajtowns:
ACK 25bed560bed370045bead21c27ea21aa228cd963

Tree-SHA512: a25c79ca7e722e2f372b65f5fc11c8b194ad49f2240b4881c7e606306aabbd3604aede3f1c33606b467486affac3a3f503638f513c896935cebbc02709cb60d8

91/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
Why it was queued
update trustsigning or wallet pathmerge-commit duplicate discount
AI analysis · Informational 18/100

This is a Bitcoin Core change that makes the optional transaction index (txindex) use much less disk space by storing shortened 5-byte transaction hash prefixes and packed block positions instead of full 32-byte transaction IDs. It is a deliberate optimization, not a security fix. The code keeps backward compatibility with old-format entries and adds tests for collision handling and mixed-format lookups. There is no evidence in the commit of a vulnerability, exploit, or undisclosed security issue.

Security candidateMerge bitcoin/bitcoin#32784: wallet: derivehdkey RPC to get xpub at arbitrary pathby Ava Chow · a8b582ec · Aug 15, 2026 · 19 filesMessage 96 · StrongLow 26Details
Commit message · Ava Chow

Merge bitcoin/bitcoin#32784: wallet: derivehdkey RPC to get xpub at arbitrary path

c3945bfd2bf87ae6fe7be1c0cee58b21c4269aec doc: use derivehdkey in multisig tutorial (Sjors Provoost)
3662e3366978e1ecff1924da100cd2606899126e test: use derivehdkey in M-of-N multisig demo (Sjors Provoost)
d9570f0838355bca638ac3287fd334905fb29e16 rpc: add derivehdkey (Sjors Provoost)
62da9f9614508f6bfd30126a73c59d0c4004066e wallet: add GetExtKey helper (Sjors Provoost)
aaf1548475ded41889d5041fc2d60e8b2ca9ddcd wallet: generalize GetActiveHDPubKeys helper (Sjors Provoost)
3821452c4af1440484ddd5ccc83f83cc4c307af3 refactor: add hardened derivation helper (Sjors Provoost)
0ab61caafd10d0539da626bd4354cb7e6df15e54 rpc: ParsePathBIP32 helper (Sjors Provoost)
e36c4b76e198751c14da8d32655e47bd5678abb6 util: reject out-of-range BIP32 keypath indices (Sjors Provoost)
ba78c31a00c912ec440dfb677997b51c72058bab fuzz: check ParseHDKeypath/WriteHDKeypath round-trip (Sjors Provoost)
8cce969085dbe3137c738cbe691008974059af1e Have ParseHDKeypath handle h derivation marker (Sjors Provoost)
fc5307776236c6f08aec94978672626f5aae1aaa test: move parse_hd_keypath test to bip32_tests (Sjors Provoost)
dab525eb7717af3b246a5aa32acea174cd9bd453 key: add DeriveExtKey() helper (Sjors Provoost)

Pull request description:

Adds a `derivehdkey` RPC that returns an xpub, or optionally the xprv, at an arbitrary BIP32 path (with at least one hardened step), derived from a wallet HD key.

The main use case is coordinating a multisig setup, where each participant shares an xpub derived at a hardened path (e.g. `m/87h/0h/0h`) distinct from their default single-signature descriptors. See the (updated) `doc/multisig-tutorial.md` and (updated) functional test to see how that workflow improves.

The first commits are some helpful helpers:

- _key: add DeriveExtKey() helper_ - performs the actual derivation
- _test: move parse_hd_keypath test to bip32_tests_ - from `psbt_wallet_tests`
- _Have ParseHDKeypath handle h derivation marker_
- _util: reject out-of-range BIP32 keypath indices_ - `ParseHDKeypath` would previously map overflowing values without `h` to hardened.
- _fuzz: check ParseHDKeypath/WriteHDKeypath round-trip_
- _rpc: ParsePathBIP32 helper_
- _refactor: add hardened derivation helper_ - `HasHardenedDerivation()`, to enforce the "at least one hardened step" rule
- _wallet: generalize GetActiveHDPubKeys helper_ - extracts code from `gethdkeys` which `derivehdkey` needs
- _wallet: add GetExtKey helper_ - reconstruct an xprv from a wallet xpub (analog of `GetKey()`); behavior-preserving prep, also simplifies `gethdkeys`.

Meat and potatoes:
- _rpc: add derivehdkey_ - the RPC itself, plus the `UnusedKey` filter on `GetHDPubKeys` that drives key selection.
- _test: use derivehdkey in M-of-N multisig demo_ - rewrites the functional multisig test to use the RPC and `<0;1>` syntax.
- _doc: use derivehdkey in multisig tutorial_ - same for the prose tutorial.

ACKs for top commit:
pseudoramdom:
code review ACK c3945bfd2bf87ae6fe7be1c0cee58b21c4269aec
achow101:
ACK c3945bfd2bf87ae6fe7be1c0cee58b21c4269aec
w0xlt:
That being the case, ACK c3945bfd2b

Tree-SHA512: 661f17c9bfe26017eb14c27ba7af37093387100d3baa25f5d29bba9c1aedc40d19afe1bdfc126a18d018857bb02f1fc84386f10b8f4f4b8e9d6f4b0691d9e302

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 boundarymemory safetydefensive validationfuzzing or regression evidencecryptography-sensitive pathsigning or wallet pathmerge-commit duplicate discount
AI analysis · Low 26/100

This commit adds a new Bitcoin Core wallet RPC called derivehdkey that lets a user derive an extended public key (xpub) — or optionally the matching extended private key (xprv) — at a chosen BIP32 path from one of the wallet's own HD keys. The main intended use is making multisig setup easier. The commit also fixes a small input-validation bug in BIP32 path parsing where very large numbers could previously be misinterpreted as hardened indices. There is no evidence in the commit of an active vulnerability being exploited; it reads as a feature addition with defensive hardening.

Security candidateMerge bitcoin/bitcoin#35852: scripted-diff: Use inline const(expr) over static constexpr in headersby merge-script · dec68f99 · Aug 14, 2026 · 102 filesMessage 81 · StrongInformational 15Details
Commit message · merge-script

Merge bitcoin/bitcoin#35852: scripted-diff: Use inline const(expr) over static constexpr in headers

fab74a0e922c6eb6501c3852ae08a24aade3850d refactor: Use C++14 digit separator for large int literals (MarcoFalke)
fae759be793043565f93957d150e482226c8ebb7 scripted-diff: Use inline constexpr over plain constexpr (MarcoFalke)
fa74f58a262096f25d5a3a4ec4951f4ce2a31792 scripted-diff: Use inline const over (static) const (MarcoFalke)
fab1a62c870e5bac92ee89b8444fd5910dfd5034 refactor: Use inline constexpr for string literals in headers (MarcoFalke)
fa08bbed8dd2e31ff1d6c6f015063b07008701fc contrib: Adjust generate-seeds.py to write inline constexpr (MarcoFalke)
fad753611b5c074f38120fd9c1a87e37cc44bf6a scripted-diff: Use inline constexpr over (static) const (MarcoFalke)
faedb52583e1c1eb6feb9cc03f4caf0bf52a8555 refactor: Make CFeeRate(integral) ctor constexpr (MarcoFalke)
5555d5dcb55969f6b5eefcf8733b628b2f36f8c7 scripted-diff: Use inline constexpr over static constexpr (MarcoFalke)
fa6e1a1e85e2e3ee6ec8fedfb5ee27f1b5bf13c4 refactor: Remove static from constexpr functions in headers (MarcoFalke)

Pull request description:

Both are fine and this refactor doesn't change any behavior.

However, `inline constexpr` from C++17 will ensure each symbol has a single address
across all TU, making the release binary minimally smaller. (For me it is smaller by about 1kB)

ACKs for top commit:
l0rinc:
reACK fab74a0e922c6eb6501c3852ae08a24aade3850d
rustaceanrob:
ACK fab74a0e922c6eb6501c3852ae08a24aade3850d
hebasto:
ACK fab74a0e922c6eb6501c3852ae08a24aade3850d, I have reviewed the code and it looks OK.

Tree-SHA512: 6ec94136c12bcbf696812d0661c9857318a69e367c79fc00b9ca0b4068f269d10e5548d95c9ba2070225308c12d7a54fe8cb8447de7e0979cba99f48892b35f9

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
cryptography-sensitive pathseed or entropy pathsigning or wallet pathparser or protocol pathmerge-commit duplicate discount
AI analysis · Informational 15/100

This is a large but purely mechanical code cleanup in Bitcoin Core. It changes how constants are declared in header files from older C++ styles (static const, static constexpr) to the modern C++17 inline constexpr/inline const form. The pull request author explicitly states this is a refactor that does not change behavior, only makes the release binary slightly smaller by ensuring each constant has a single address across the program. No security vulnerability is present.

AI review queuedReplace CTransaction::operator== with Equals that has optionsby Ava Chow · b973a355 · Aug 13, 2026 · 8 filesMessage 81 · StrongInformational 17Details
Commit message · Ava Chow

Replace CTransaction::operator== with Equals that has options

CTransaction::operator== is only used in a few places. In a few
instances of checking transaction equality, we want to control which
fields are actually being compared, so use a custom Equals() function
which takes a EqualsOptions struct to control the checks.

As suggested in https://github.com/bitcoin/bitcoin/pull/32723#issuecomment-3028112892

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

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

This commit is a code cleanup: it replaces a simple transaction equality operator with a more flexible Equals() function that lets callers choose whether to compare signature and witness data. The change does not fix a known bug or vulnerability on its own. It is a refactor that makes future code easier to write correctly, especially in the wallet where transactions need to be compared ignoring signatures.

AI review queuedtest: Bumping a transaction prevents bumping malleationsby Ava Chow · 2c6047df · Aug 13, 2026 · 1 fileMessage 72 · AdequateInformational 15Details
Commit message · Ava Chow

test: Bumping a transaction prevents bumping malleations

72/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit only adds and updates a test file. It does not change any production wallet code. The new test checks that when a user has both an original transaction and a malleated version of it in their wallet, bumping the fee on one of them correctly prevents the other from also being bumped. This is a regression test for existing behavior, not a security fix.

AI review queuedtest: Test rbf metadata sync of malleated txby Ava Chow · a44f9ad3 · Aug 13, 2026 · 1 fileMessage 67 · AdequateInformational 12Details
Commit message · Ava Chow

test: Test rbf metadata sync of malleated tx

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

This commit only adds a new automated test to Bitcoin Core. It checks that when a user creates a replace-by-fee (RBF) transaction and someone later alters (malleates) that transaction, the wallet still correctly preserves the user's original comment and the ID of the transaction it replaced. There is no change to production wallet code here, only a regression test.

AI review queuedwallet: Clarify IsEquivalentTo is actually checking malleationby Ava Chow · 34533d5d · Aug 13, 2026 · 3 filesMessage 73 · AdequateInformational 15Details
Commit message · Ava Chow

wallet: Clarify IsEquivalentTo is actually checking malleation

IsEquivalentTo is used to determine whether another CWalletTx is
actually a malleation of the current tx. Rename to clarify this.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit is a simple rename and documentation update. A wallet function called IsEquivalentTo is renamed to IsMalleation, and its comment is expanded to explain exactly what it checks. No behavior changes, no bug fixes, and no security implications are present in the diff.

AI review queuedtest: Test that metadata is synced to malleated transactionsby Ava Chow · fc718ade · Aug 13, 2026 · 1 fileMessage 72 · AdequateInformational 12Details
Commit message · Ava Chow

test: Test that metadata is synced to malleated transactions

72/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 12/100

This commit only adds a new test to Bitcoin Core. It checks that when a transaction is 'malleated' (changed slightly without invalidating it, for example by changing the signature type), any user-provided metadata such as a comment is still correctly copied to the modified transaction in the wallet. There is no code fix or behavior change in the main Bitcoin software—only a new automated test.

Security candidateMerge bitcoin/bitcoin#35959: Update secp256k1 subtree to latest masterby Ava Chow · 625f951b · Aug 12, 2026 · 26 filesMessage 81 · StrongLow 28Details
Commit message · Ava Chow

Merge bitcoin/bitcoin#35959: Update secp256k1 subtree to latest master

09cc345c3e323befc05bd6910704ed478f4e561e Squashed 'src/secp256k1/' changes from d2d04864ef..687155df6b (fanquake)

Pull request description:

We recently pulled the secp256k1 subtree (#35781), to get access to the recently-merged silent payments module (used in multiple PRs here). Since then, libsecp256k1 has merged more changes, and had a [`0.8.0` release](https://github.com/bitcoin-core/secp256k1/releases/tag/v0.8.0), so update to latest master again.

Includes:
* https://github.com/bitcoin-core/secp256k1/pull/1709
* https://github.com/bitcoin-core/secp256k1/pull/1776
* https://github.com/bitcoin-core/secp256k1/pull/1863
* https://github.com/bitcoin-core/secp256k1/pull/1869
* https://github.com/bitcoin-core/secp256k1/pull/1886
* https://github.com/bitcoin-core/secp256k1/pull/1896
* https://github.com/bitcoin-core/secp256k1/pull/1897
* https://github.com/bitcoin-core/secp256k1/pull/1899
* https://github.com/bitcoin-core/secp256k1/pull/1900
* https://github.com/bitcoin-core/secp256k1/pull/1901
* https://github.com/bitcoin-core/secp256k1/pull/1902
* https://github.com/bitcoin-core/secp256k1/pull/1903
* https://github.com/bitcoin-core/secp256k1/pull/1904
* https://github.com/bitcoin-core/secp256k1/pull/1906
* https://github.com/bitcoin-core/secp256k1/pull/1907

ACKs for top commit:
l0rinc:
ACK f464f6cd67e5c79c820532bba17f773928de6aec
achow101:
ACK f464f6cd67e5c79c820532bba17f773928de6aec
w0xlt:
ACK f464f6cd67e5c79c820532bba17f773928de6aec

Tree-SHA512: e7a3d0113c08fccd54f6734154aa6ed3aa06a6e52fb52eacb82c82c7079a23bfee8da9aa3934fc3c173097631394b4ba22d17ca6b73f6bf478dcb0c0a227d8d4

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
cryptography-sensitive pathmerge-commit duplicate discount
AI analysis · Low 28/100

This commit updates Bitcoin Core's embedded copy of the secp256k1 cryptographic library to a newer version. The update adds a new Silent Payments module, lets advanced users swap in a custom SHA256 compression function, removes some old deprecated names, and tightens one edge-case check in the ElligatorSwift key-exchange code. The change is a routine dependency refresh; nothing in the commit message or diff is described by the vendor as a security fix, and the one behavior change (rejecting certain oversized secret keys in ellswift_xdh) is explicitly called out as not being a security issue.

AI review queuedMerge bitcoin/bitcoin#35605: wallet: rpc: Deprecate `removeprunedfunds` RPCby Ava Chow · e9ed5e83 · Aug 12, 2026 · 5 filesMessage 91 · StrongInformational 23Details
Commit message · Ava Chow

Merge bitcoin/bitcoin#35605: wallet: rpc: Deprecate `removeprunedfunds` RPC

f280f5eb47497f53ff997e7d3bec9667cb60339a wallet: rpc: deprecate removeprunedfunds (David Gumberg)
e5b7785447fc130e8eb6d1a5e8ff051c68b0e8c6 test: wallet: resend: avoid internal behavior via removeprunedfunds (David Gumberg)

Pull request description:

Originally added in https://github.com/bitcoin/bitcoin/pull/7558 as a companion to `importprunedfunds`, this RPC has no known helpful use while being both dangerous and a maintenance burden.

Despite what the name says, it allows the deletion of arbitrary transactions, and `importprunedfunds` does not allow the importing of transactions not belonging to the user, and `listtransactions` does not list transactions not belonging to the wallet, so this RPC can only be used to delete transactions actually belonging to the wallet, and in the unlikely event that transactions not belonging to the wallet are present, they cause no harm except for occupying a few bytes on the users disk.

ACKs for top commit:
achow101:
ACK f280f5eb47497f53ff997e7d3bec9667cb60339a
polespinasa:
ACK f280f5eb47497f53ff997e7d3bec9667cb60339a
pablomartin4btc:
reACK f280f5eb47497f53ff997e7d3bec9667cb60339a

Tree-SHA512: ed9c30c50be514d637999b4c8f3fa9b9b1446a5553e3974703638b45d8f55f1291f5cfb82dd2ead6d0743e424e9e3b1edbd56fc04dae3dcdee4d175e2a1ce061

91/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
Why it was queued
signing or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Informational 23/100

This commit deprecates a Bitcoin Core wallet RPC command called removeprunedfunds. The command lets users delete transactions from their own wallet, which can alter displayed balances. The change does not fix a software bug; it is a cleanup that warns users the command will be removed in a future release and requires a special startup flag to keep using it. The main practical effect is that scripts or users relying on removeprunedfunds will now need to enable it explicitly or switch to a different approach.

AI review queuedMerge bitcoin/bitcoin#35930: wallet: post-#35501 cleanups in CWalletTxby Ava Chow · 512dc9af · Aug 11, 2026 · 5 filesMessage 91 · StrongInformational 18Details
Commit message · Ava Chow

Merge bitcoin/bitcoin#35930: wallet: post-#35501 cleanups in CWalletTx

4ca182ca4028b9e681d65ec21f79fd7fed3ce215 doc: clarify alternate_wtxids is empty when only one witness variant (pablomartin4btc)
fa48b5d28eb5c326115af246b12ff644279172c4 test: assert listsinceblock "removed" reports current canonical wtxid (pablomartin4btc)
9b96ee12881ef38a221f34ce26a3b4fcb5622b4b wallet, test: add unit test for variant txid validation in CWalletTx deserializer (pablomartin4btc)
9de6543cb55ff43aea950712a3148fed9d4a7e13 wallet: post-#35501 cleanup in CWalletTx (pablomartin4btc)

Pull request description:

Follow-up cleanups and clarifications after #35501 was merged.

Commit breakdown:

1. _post-[#35501](https://github.com/bitcoin/bitcoin/pull/35501) cleanup in_ `CWalletTx`
- Rename `arg_state` → `new_state` in `Update()` for consistency
- Simplify `RecomputeCanonical()` using `std::ranges::min_element` with a projection lambda (14 lines → 3 lines)
- Add variant txid validation in the `CWalletTx` deserialise constructor: throws `std::runtime_error` if any variant's txid doesn't match the canonical txid deserialized from the stream
- Move `Init()` to `private` and extend it to clear `m_txs` and reset `m_canonical_wtxid`, so a full re-deserialise via `Unserialize()` starts from a clean state

All [suggested](https://github.com/bitcoin/bitcoin/pull/35501#pullrequestreview-4854519083) by ajtowns.

2. _add unit test for variant txid validation in_ `CWalletTx` _deserializer_

3. _assert_ `listsinceblock` "removed" _reports current canonical wtxid_
Documents that removed entries reflect the wallet's current `CWalletTx` state, not a snapshot of the detached block. A future followup could improve this (requires per-block tracking of which witness variant was included).
[Suggested](https://github.com/bitcoin/bitcoin/pull/35501#discussion_r3632044472) by w0xlt.

4. _clarify_ `alternate_wtxids` _is empty when only one witness variant_
[Suggested](https://github.com/bitcoin/bitcoin/pull/35501#discussion_r3632113003) by polespinasa.

ACKs for top commit:
jeanpablojp:
re-ACK 4ca182ca4028b9e681d65ec21f79fd7fed3ce215
achow101:
ACK 4ca182ca4028b9e681d65ec21f79fd7fed3ce215
polespinasa:
ACK 4ca182ca4028b9e681d65ec21f79fd7fed3ce215

Tree-SHA512: 64eadeb11372d904c79edbfd264c4d8dc1b4fe4ce5e3acc301bfeba9e556efb5dce2c684f0e58c7b74e2c687cc7dd77389970662b3fd629ed034a97bcfdfb71c

91/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
Why it was queued
signing or wallet pathmerge-commit duplicate discountsecond-pass: broader security terminologysecond-pass: security-sensitive path
AI analysis · Informational 18/100

This is a follow-up cleanup and hardening patch for the Bitcoin Core wallet's handling of transactions that have multiple possible witness versions (same transaction ID but different witness data). It renames a variable, simplifies a helper function, adds validation so a corrupted wallet database cannot load a mismatched transaction variant, and improves documentation and tests. There is no direct evidence this fixes an active exploit, but it adds a defensive check against a potential data-integrity failure.

Security candidateMerge bitcoin/bitcoin#35729: refactor: test: Unroll `&&` conditions in macrosby merge-script · aa0e0f79 · Aug 11, 2026 · 19 filesMessage 91 · StrongInformational 15Details
Commit message · merge-script

Merge bitcoin/bitcoin#35729: refactor: test: Unroll `&&` conditions in macros

e8691056c0140f8fa850fc6837dde915ebeb22cc test: Unroll `&&` conditions in macros (rustaceanrob)

Pull request description:

Picked from #35713. Given that I think this is a strict debugging improvement, I opened as a separate pull:

Using `&&` in `BOOST_CHECK` is problematic as failures will not indicate which condition failed. By unrolling these checks, the user knows exactly which expression is the failing case.

As an example, here is a line that would be particularly hard to debug if it failed:

```
src/test/net_tests.cpp

BOOST_CHECK((*ret)[1] && (*ret)[1]->m_type == "headers" && std::ranges::equal((*ret)[1]->m_recv, MakeByteSpan(msg_data_2)));
```

If any one of these conditions fail, the whole expression fails, with no values printed or indication as to which condition failed.

This is also required when using test macros that support value decomposition, which requires `&&` and `||` are `delete`. Examples include `BOOST_TEST`, doctest, Catch2, etc.

ref: https://catch2-temp.readthedocs.io/en/latest/assertions.html#other-limitations
ref: https://fekir.info/post/decomposing-an-expression/

ACKs for top commit:
maflcko:
re-ACK e8691056c0140f8fa850fc6837dde915ebeb22cc 🌽
ismaelsadeeq:
reACK e8691056c0140f8fa850fc6837dde915ebeb22cc
sedited:
ACK e8691056c0140f8fa850fc6837dde915ebeb22cc

Tree-SHA512: 9eb74cecd47ee4fdc3f53beb7d50d5056d543303d023c68b8d47cbe52d37f1156488c8b943faf68dd52c192c43626037bbf08172e7cc24753e0f6070db6e3ab2

91/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
Why it was queued
cryptography-sensitive pathsigning or wallet pathmerge-commit duplicate discount
AI analysis · Informational 15/100

This commit only changes Bitcoin Core's internal test code. It splits combined conditions inside test-check macros (like BOOST_CHECK(a && b)) into separate checks so that when a test fails, the test output points to the exact failing condition. It does not change any production code, network behavior, wallet logic, or consensus rules, and it does not fix a security vulnerability.

Security candidateMerge bitcoin/bitcoin#35493: wallet, descriptor: Fix MuSig private key completeness checks on `importdescriptors`by merge-script · 2c01832f · Aug 11, 2026 · 4 filesMessage 100 · StrongLow 26Details
Commit message · merge-script

Merge bitcoin/bitcoin#35493: wallet, descriptor: Fix MuSig private key completeness checks on `importdescriptors`

0390338692a7d1dda8062b5b90eb36724da6195d test: check MuSig import private key warnings (woltx)
5e62fbf09c01a644b0b85f80ee101814ad2c330d wallet: check descriptor private key completeness on import (woltx)
cd8d01bf47a289a80e288fa6c38a56557f8f7dcf descriptors: require complete MuSig private keys (woltx)

Pull request description:

`importdescriptors` currently checks whether all private keys are present by expanding the descriptor and verifying that every expanded origin pubkey has a private key.

This is wrong for MuSig descriptors because expansion includes the synthetic aggregate pubkey. There is no individual private key for that aggregate pubkey, so importing a fully private MuSig descriptor such as `rawtr(musig(A_priv,B_priv))` incorrectly returns:

```
Not all private keys provided. Some wallet functionality may return unexpected errors
```

This PR fixes the issue by making descriptor private-key completeness account for MuSig participant keys, and by having `importdescriptors` use `Descriptor::HavePrivateKeys()` instead of duplicating its own manual completeness check.

The functional test covers both cases:

- `rawtr(musig(A_priv,B_priv))` imports without warnings.
- `rawtr(musig(A_priv,B_pub))` still warns that not all private keys were provided.

ACKs for top commit:
achow101:
ACK 0390338692a7d1dda8062b5b90eb36724da6195d
theStack:
Code-review ACK 0390338692a7d1dda8062b5b90eb36724da6195d

Tree-SHA512: a55fb084c63f725a0991556acdfb822f3a5a669f745a00b9f0bf0996b639986cdf5e2be2e8d3d0a2ee3fe5744355f20b40df576601792ef3db698e606629ad52

100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
secret or key materialsigning or wallet pathmerge-commit duplicate discount
AI analysis · Low 26/100

This commit fixes a bug in Bitcoin Core's wallet import logic for a new type of multi-signature setup called MuSig. Previously, when a user imported a MuSig descriptor that already contained all needed private keys, the wallet incorrectly warned that some private keys were missing. The fix makes the wallet correctly check the individual participant keys inside a MuSig group rather than looking for a private key for the combined group key, which does not exist. It is a correctness and usability fix, not a remote-exploitable vulnerability.

AI review queuedMerge bitcoin/bitcoin#35924: Wallet, refactor: Remove orphaned EraseWatchOnly functionby merge-script · b80cee03 · Aug 11, 2026 · 2 filesMessage 81 · StrongInformational 15Details
Commit message · merge-script

Merge bitcoin/bitcoin#35924: Wallet, refactor: Remove orphaned EraseWatchOnly function

6304789a18f9391ff70bf8eed649bdecf176a086 Wallet, refactor: Remove orphaned EraseWatchOnly function (vicjuma)

Pull request description:

**Summary**
This is a follow-up PR for #28710 by achow101 where `bool LegacyScriptPubKeyMan::RemoveWatchOnly(const CScript &dest)` which was the only remaining caller for the function `EraseWatchOnly` was removed. This PR is just a cleanup to remove the orphaned function.

ACKs for top commit:
jeanpablojp:
ACK 6304789a18f9391ff70bf8eed649bdecf176a086
pablomartin4btc:
ACK 6304789a18f9391ff70bf8eed649bdecf176a086

Tree-SHA512: 48546b3fa9155d6f9549ce8e77d9fe34cbfc738e6814ac9cd256b85668d0fa325e51404f962d491c6d4989baefd03815c680578bfcc73741cf9c4e65b141f92e

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 or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit removes an unused function called EraseWatchOnly from the Bitcoin Core wallet code. It is a routine cleanup with no functional change and no security relevance.

AI review queuedMerge bitcoin/bitcoin#35943: doc: fix dead link in txrequest.hby merge-script · 5d051c05 · Aug 11, 2026 · 1 fileMessage 81 · StrongInformational 15Details
Commit message · merge-script

Merge bitcoin/bitcoin#35943: doc: fix dead link in txrequest.h

a7b0b5084a4a75306a6e88481264f9e4c36a8f08 doc: fix dead link in txrequest.h (cyb3ralbert)

Pull request description:

The link is dead. Both the file and the whole `blockchainbib/` section return 404. The host certificate expired on 2026-08-07, so the site looks abandoned rather than moved.

It was a local copy of Miller et al. 2015, *Discovering Bitcoin's Public Topology and Influential Nodes*. The [`blockchainbib` bibliography](https://github.com/kernoelpanic/blockchainbib) that distributed it points to `cs.umd.edu/projects/coinscope/coinscope.pdf`, where the original is still accessible.

No other occurrences in the tree.

ACKs for top commit:
l0rinc:
ACK a7b0b5084a4a75306a6e88481264f9e4c36a8f08
sedited:
ACK a7b0b5084a4a75306a6e88481264f9e4c36a8f08

Tree-SHA512: 518b3c703417f544c7aa96d94db4cb92a669c0223eaefecd9847378061273258c45939376e47d616651e78eb090110a30ef9dc786506e1ae5d4ac7cd20cd0dcd

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

This commit only fixes a broken web link in a code comment. It replaces an outdated URL to a research paper with a working URL to the same paper. There is no change to program logic, no security fix, and no vulnerability.

AI review queuedMerge bitcoin/bitcoin#33186: wallet, test: Ancient Wallet Migration from v0.14.3 (no-HD and Single Chain)by merge-script · 757aa573 · Aug 10, 2026 · 4 filesMessage 100 · StrongInformational 15Details
Commit message · merge-script

Merge bitcoin/bitcoin#33186: wallet, test: Ancient Wallet Migration from v0.14.3 (no-HD and Single Chain)

ea59f1722097a620de6efd2fedc37b64a105ec96 test: cover v0.14.3 wallet migration (w0xlt)
18b8afd09333d19ffa6c51a08edda6af09b812b7 test: support v0.14.x in dumb_sync_blocks (w0xlt)

Pull request description:

This PR adds test coverage for migrating legacy Bitcoin Core wallets from v0.14.3 (released in 2017) to the descriptor wallet format. The test validates that users can safely upgrade their wallets while preserving all funds, transaction history, and addresses.

This test was originally developed on top of #32977, as it was requested in reviews.
However, since it also increases test coverage, it can be merged independently.

The test covers two wallet migration scenarios:

* Non-HD Wallet Migration - Tests migration of non-HD wallets (created with `-usehd=0`)
* Single Chain HD Wallet Migration - Tests migration of HD wallets from v0.14.3 (`VERSION_HD_BASE`)

The node v0.14.3 cannot be synced using the normal test framework helpers because it does not have the `syncwithvalidationinterfacequeue` RPC, so the test uses `dumb_sync_blocks` to submit blocks from the ancient node to the modern node before migrating the wallet.

Each scenario uses its own dedicated old/new node pair, which keeps the setup isolated and makes this testing best managed in a separate file rather than in the existing migration test files.

On the Windows cross-built CI job, this test is excluded from the main functional test runner and re-run sequentially in an ASCII-only tmpdir, because the v0.14.3 binary cannot handle non-ASCII characters in the temporary directory path.

ACKs for top commit:
furszy:
utACK ea59f1722097a620de6efd2fedc37b64a105ec96
pablomartin4btc:
reACK ea59f1722097a620de6efd2fedc37b64a105ec96

Tree-SHA512: 35ef7173e10fe52f20db0d6d1f144c5a1343ff406d294ab7d0e346d79546797f3f145f2893d99bb7b57d71aa14580690ab80eae148ec94b91498eb0938b2d15e

100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
defensive validationsigning or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit only adds new automated tests for migrating very old Bitcoin Core wallets (version 0.14.3 from 2017) to the modern descriptor wallet format. It does not change any wallet production code, consensus rules, or network behavior. There is no security-relevant change for users running Bitcoin Core.

AI review queuedMerge bitcoin/bitcoin#35925: wallet, rpc: Exclude non-owned addresses from listreceivedby*by Ava Chow · e8cc21c5 · Aug 10, 2026 · 2 filesMessage 91 · StrongLow 28Details
Commit message · Ava Chow

Merge bitcoin/bitcoin#35925: wallet, rpc: Exclude non-owned addresses from listreceivedby*

089c883c558e01c2a18a92f861fa7de9a7cc607a test: Add coverage for listreceivedby* excluding "send" addresses (pablomartin4btc)
873c0548059b2860b3718551078763d227186bd6 wallet: Exclude non-owned addresses from listreceivedby* (pablomartin4btc)

Pull request description:

Fixes #16159.

`listreceivedbyaddress`/`listreceivedbylabel` with `include_empty=true` walk the entire address book and return every entry that has no matching `mapTally` record — including addresses with a "send" purpose (foreign addresses that got a label via `setlabel`, the GUI, or `addmultisigaddress`) that this wallet never received funds to and doesn't own.

This excludes those via `IsMine()` rather than the address book's `purpose` field, since `purpose` is set inconsistently across several code paths and `IsMine()` is the same check `mapTally` itself is already built from.

Picks up prior work by kouloumos in #25973 and BrandonOdiwuor in #30972, both closed for
inactivity:
- [#25973](https://github.com/bitcoin/bitcoin/pull/25973) filtered on `purpose == "send"` directly. ryanofsky pointed out purpose "is set pretty haphazardly in code" and [suggested](https://github.com/bitcoin/bitcoin/pull/25973#discussion_r1269477246) `IsMine()` instead.
- [#30972](https://github.com/bitcoin/bitcoin/pull/30972) implemented that, then furszy pointed out `IsMine()` only needs to run for addresses missing from `mapTally`, not every one. rkrux further suggested dropping the redundant re-lock in favor of `EXCLUSIVE_LOCKS_REQUIRED` directly on the lambda — matching the existing pattern in `wallet/interfaces.cpp` — and simplifying the branching.

This PR carries that final approach forward on current master. The regression test is a small, standalone addition rather than reviving the test-file "split into subtests" refactor from the earlier PRs, which achow101 [flagged](https://github.com/bitcoin/bitcoin/pull/30972#issuecomment-3688186614) on #30972 as unrelated stylistic churn.

ACKs for top commit:
polespinasa:
lgtm re-ACK 089c883c558e01c2a18a92f861fa7de9a7cc607a
jeanpablojp:
ACK 089c883c558e01c2a18a92f861fa7de9a7cc607a
achow101:
ACK 089c883c558e01c2a18a92f861fa7de9a7cc607a

Tree-SHA512: d45488c93b9294258faaab5d1891ca5e8c4b8d0d4feb298403c7c3f20d6aa08989d548cddd25ccd47a1ed969e4a309ee68ad1541c6121fed39ed534c78c256e7

91/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
Why it was queued
fuzzing or regression evidencesigning or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Low 28/100

This update fixes a wallet reporting bug. When a user asked their Bitcoin wallet to list every address that had received money, including empty ones, the result incorrectly included foreign addresses that the wallet merely knew about (for example, an address labeled as a 'send' recipient). The fix ensures only addresses actually owned by the wallet are shown. It is a privacy/information-disclosure issue, not a theft-of-funds bug.

Security candidateMerge bitcoin/bitcoin#35937: test: Append print_suppressions=0 to LSAN_OPTIONS, and suppress bitcoin-qtby merge-script · 5973e075 · Aug 10, 2026 · 2 filesMessage 91 · StrongInformational 15Details
Commit message · merge-script

Merge bitcoin/bitcoin#35937: test: Append print_suppressions=0 to LSAN_OPTIONS, and suppress bitcoin-qt

fad9ab714b5512f204f75a94d8cc4fa164dd4061 test: Append print_suppressions=0 to LSAN_OPTIONS, and suppress bitcoin-qt (MarcoFalke)

Pull request description:

(see commit msg for rationale and background).

To test, one should be able to use the cmake options such as `-DCMAKE_C_COMPILER='clang' -DCMAKE_CXX_COMPILER='clang++' --preset=dev-mode -DBUILD_GUI=ON -DSANITIZERS=address` on e.g. Fedora. Then see that the current suppressions file is insufficient, and also confirm that `print_suppressions=0` is required.

ACKs for top commit:
fanquake:
ACK fad9ab714b5512f204f75a94d8cc4fa164dd4061

Tree-SHA512: 1830b4aeb072fa18b76522a124a268073675da14255e469a6d86ee5de52cd08d5613d0c3bd8a66465b0c4636345c9e967923cd1fb516906a58b614fe0e700033

91/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
Why it was queued
access controldefensive validationmerge-commit duplicate discount
AI analysis · Informational 15/100

This commit only changes test configuration. It tells the LeakSanitizer tool used during automated testing to stop printing long lists of suppressed memory leaks, and it narrows the list of ignored leaks to the bitcoin-qt GUI test binary. There is no change to the actual Bitcoin Core software that users run, and no security vulnerability is being fixed or introduced.

AI review queuedMerge bitcoin/bitcoin#35928: doc: mention -DWITH_ZMQ=ON in macOS build guideby merge-script · 8397e09e · Aug 7, 2026 · 1 fileMessage 91 · StrongInformational 15Details
Commit message · merge-script

Merge bitcoin/bitcoin#35928: doc: mention -DWITH_ZMQ=ON in macOS build guide

222855ed1129669e67785c9800292f017a301816 doc: mention -DWITH_ZMQ=ON in macOS build guide (cyb3ralbert)

Pull request description:

`doc/build-osx.md` currently says:

> Support for ZMQ notifications requires the following dependency.

The `zeromq` dependency is covered, but the `-DWITH_ZMQ=ON` CMake option is not
mentioned anywhere in that section. `WITH_ZMQ` defaults to `OFF`, so following the
guide as written results in a build with ZMQ disabled, even though the user completed
the ZMQ section. I verified this at the configure step on macOS: with `zeromq`
installed and no flag, CMake reports `ZeroMQ ... OFF`; with `-DWITH_ZMQ=ON` it
reports `ON`.

The same wording was added to the BSD build guides in #35283, but `doc/build-osx.md`
was not included.

Docs-only change. No tests run.

ACKs for top commit:
hebasto:
ACK 222855ed1129669e67785c9800292f017a301816.

Tree-SHA512: b7e7114e18ef10216780f6b549516c79bff67d7a909c5167f9c48cc8d2ef0b10f1524c7656452308914e5cd86425588f9f2dac07d4eeb2fe1e624f5478453d73

91/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
Why it was queued
documentation-only discountmerge-commit duplicate discountsecond-pass: broader security terminology
AI analysis · Informational 15/100

This is a one-line documentation update to the macOS build guide. It adds a note telling users to pass a specific CMake option if they want ZeroMQ notification support. There is no code change and no security impact.

Security candidateMerge bitcoin/bitcoin#35482: fuzz: exercise the transaction-handling path in process_message(s)by merge-script · f11dc617 · Aug 7, 2026 · 8 filesMessage 100 · StrongInformational 15Details
Commit message · merge-script

Merge bitcoin/bitcoin#35482: fuzz: exercise the transaction-handling path in process_message(s)

87b080fe2b66036184a54a0bfc320498dd416d74 fuzz: reset the reused mempool in process_message(s) (Hao Xu)
d522fd3196368d4be337bff7bc2a5f33ce3ed1c4 fuzz: prepare deterministic mempool rebuilds (Hao Xu)
b11456386b266b8c0a319b6fad3481b8eeb155cf fuzz: let the test input toggle IBD in the p2p fuzz targets (Hao Xu)
2a29cee68438e485b101e9a89c907f7a2ea38232 test: add helper to reset chainman and mempool (Hao Xu)
2a4ef42d34edf6499e4185c2fc7c6fed8b071ae7 fuzz: share a single FakeNodeClock in the chainman-resetting fuzz targets (Hao Xu)

Pull request description:

## Problem

`process_message` and `process_messages` keep the node in IBD (`ResetIbd()`) and
mine their coinbases with the default bare-`OP_TRUE` output script. As a result
`net_processing` returns early at the `IsInitialBlockDownload()` check and never
reaches the transaction-handling path; and even if it did, a tx spending a
bare-`OP_TRUE` coinbase is rejected as `NONSTANDARD` by
`ValidateInputsStandardness`. The reused mempool therefore always stays empty and
that path is never exercised.

## Changes

Both targets now get the same treatment:

1. **Toggle IBD from the test input** — a `bool` decides whether to also
`JumpOutOfIbd()`, exercising both the IBD and non-IBD paths. In
`process_message` it is consumed last, so existing corpus entries read `false`
and are unchanged. In `process_messages` the messages run in a loop, so the
bool must be consumed *first* (see the corpus note below).
2. **Use a spendable `P2WSH_OP_TRUE` coinbase** — both anyone-can-spend (an
`OP_TRUE` witness, no signature) and a standard witness output, so a fuzz-built
tx spending a mature coinbase can actually be accepted into the mempool.
3. **Reset the rng before rebuilding (preparation)** — rebuilding the chainman
(and, in the next commit, the mempool) consumes the global PRNG. Reset it with
`MakeRandDeterministicDANGEROUS()` first so the rebuild is deterministic across
iterations. Mirrors the `cmpctblock` harness.
4. **Reset the reused mempool** — now that the mempool can become non-empty,
rebuild it together with the chainman in `ResetChainmanAndMempool()` when the
block index grew or the mempool changed. A dirty mempool is detected by its
sequence number rather than its size, since a tx can be added and removed
within one iteration (leaving the size unchanged).

## Corpus note

~~In `process_messages` the IBD bool is consumed before the message loop (first
integral read), which shifts the `FuzzedDataProvider` layout. Existing
`process_messages` corpus entries can be migrated by appending a single `0x00`
byte at the end (read as `false`, keeping the IBD path); every other consumed
value stays the same. This is a qa-assets change accompanying this PR.~~

This note no longer applies because the IBD toggle is now consumed inside the
message loop. Appending a single `0x00` byte would not reliably target that bool
or preserve the rest of the input layout.

The accompanying `qa-assets` update should migrate or regenerate the affected
`process_messages` corpus entries for the current layout.

ACKs for top commit:
Crypt-iQ:
crACK 87b080fe2b66036184a54a0bfc320498dd416d74
maflcko:
review ACK 87b080fe2b66036184a54a0bfc320498dd416d74 🏁
frankomosh:
Review ACK 87b080fe2b66036184a54a0bfc320498dd416d74

Tree-SHA512: e557b2ca3329767a45fe8315c63df9c3191a3a46a17c5e75ea3e4ad0c25e0e500a687fa650297a386b0a2ebb95503d069089ca5ae3d0a34caab98367aeb28683

100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
entropy or randomnesssigning boundarydefensive validationfuzzing or regression evidencemerge-commit duplicate discount
AI analysis · Informational 15/100

This commit only changes Bitcoin Core's internal fuzz testing code. It makes the fuzz tests exercise more of the transaction-handling code path by toggling Initial Block Download mode and resetting the mempool between test runs. There is no change to production network, wallet, or consensus code, and no security vulnerability is being fixed or introduced.

AI review queuedMerge bitcoin/bitcoin#35914: test, fuzz: Remove unused variablesby merge-script · d36bf709 · Aug 7, 2026 · 8 filesMessage 91 · StrongInformational 15Details
Commit message · merge-script

Merge bitcoin/bitcoin#35914: test, fuzz: Remove unused variables

3175d576288f3118c6fee0d9f7cb57f976c52346 test, refactor: Remove unused `error` in `wallet_tests.cpp` (Hennadii Stepanov)
422f1bd92f15c35d8fa799d25889e2fcb7469a44 test, refactor: Remove unused `utxo_pool` in `coinselector_tests.cpp` (Hennadii Stepanov)
e550945a3941e31c8a31983fdce29c11e584bea1 test, refactor: Remove unused `removed_refs` in `txgraph_tests.cpp` (Hennadii Stepanov)
e50f422d25f98cc83d1d2251eca4e134be5453bd test, refactor: Remove unused variables in `test/rbf_tests.cpp` (Hennadii Stepanov)
b7ae50e2e27eb10414a8a2b327fee95e3db3cddc fuzz, refactor: Remove unused `header` in `p2p_transport_serialization.cpp` (Hennadii Stepanov)
3df0d067ade9574ef70e96f048f6178fb34f38f1 fuzz, refactor: Remove unused `random_string` in `locale.cpp` (Hennadii Stepanov)
fc28914de4e1251be7087e2a0cfa5b8fd3b0f0b9 fuzz, refactor: Remove unused `linearization` in `cluster_linearize.cpp` (Hennadii Stepanov)
da58e559865e128ca47571645a7d0e60f9caf317 test, refactor: Remove unused `warnings` in `wallet/test/util.cpp` (Hennadii Stepanov)

Pull request description:

Noted in https://my.cdash.org/builds/3868446/build.

See commit messages for more details.

Here is a related upstream change: https://github.com/llvm/llvm-project/pull/203084.

ACKs for top commit:
maflcko:
review ACK 3175d576288f3118c6fee0d9f7cb57f976c52346 🐕

Tree-SHA512: 49334f79aa0effa9bbc94c7bce69bd1869ded87926229e575ba3721108d08ad5b7451222959310773e8e6009125d98016d095ac1a915e2dfa22712c51d8903aa

91/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
Why it was queued
fuzzing or regression evidencesigning or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit removes unused variables from Bitcoin Core's test and fuzzing code. It is a cleanup/refactoring change with no effect on the live network software or user funds. It does not fix or introduce any security vulnerability.

AI review queuedMerge bitcoin/bitcoin#35896: refactor: Default uint256::operator==, add operator<=>by merge-script · ed2c59ab · Aug 7, 2026 · 5 filesMessage 93 · StrongInformational 15Details
Commit message · merge-script

Merge bitcoin/bitcoin#35896: refactor: Default uint256::operator==, add operator<=>

fa2e76d397a4be6d98d3a43f4df923fa592523ea bench: Add base_blob compare bench via uint256 (MarcoFalke)
fa588e9e0f8019d855dbc41199814564c27d5256 refactor: Mark assertion_fail as [[noreturn]] (MarcoFalke)
faec059dfe8bc5a90e273748ce5ced0e024dad81 refactor: Add uint256::operator<=>() (MarcoFalke)
fa6df14c2360f2b55daac0744e8a675eaf3e5eb4 refactor: uint256::operator==() = default (MarcoFalke)

Pull request description:

Some refactors with rationale:

* Default the `uint256` base blob equals operator, because this is standard C++20 practise.
* Add the `uint256` base blob `<=>` operator, because this is standard C++20 practise. Also, `transaction_identifier` already offers such an operator. This allows to remove the non-standard `Compare()` function.
* Add a `[[noreturn]]` to the assertion failure helper that does not return. This is standard C++11 practise.

ACKs for top commit:
optout21:
ACK fa2e76d397a4be6d98d3a43f4df923fa592523ea
Sjors:
ACK fa2e76d397a4be6d98d3a43f4df923fa592523ea
purpleKarrot:
ACK fa2e76d397a4be6d98d3a43f4df923fa592523ea
hebasto:
re-ACK fa2e76d397a4be6d98d3a43f4df923fa592523ea.
w0xlt:
ACK fa2e76d397a4be6d98d3a43f4df923fa592523ea as a simplification/refactor, not as a performance optimization.

Tree-SHA512: 2e64e09fabe71d84c05ed943664417dd1bc1cf6fe6bf31006a58dd9180c458f69915ba7770501537678f1ad51cce16018f79bdf6780e072b73b692ea44b60185

93/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit is a routine code cleanup in Bitcoin Core. It switches the uint256 equality and comparison operators to use standard C++20 defaults, removes an old custom Compare() helper, and marks an internal assertion-failure function as never returning. There is no security bug being fixed and no behavior change that would affect users or attackers.

Security candidateMerge bitcoin/bitcoin#35872: rpc: avoid descriptor range counter overflowby Ava Chow · b388674a · Aug 6, 2026 · 2 filesMessage 96 · StrongModerate 62Details
Commit message · Ava Chow

Merge bitcoin/bitcoin#35872: rpc: avoid descriptor range counter overflow

264555af3cc2ab2919e49e7dea3f8066b9336020 rpc: avoid descriptor range counter overflow (Lőrinc)
143a13fb2bd190e50c26bb5582c6c0a2af17867a test: characterize descriptor range endpoint (Lőrinc)

Pull request description:

**Problem:** The authenticated `scantxoutset`, `scanblocks`, `getdescriptoractivity`, `utxoupdatepsbt`, and `descriptorprocesspsbt` RPCs share a descriptor expansion helper that iterates inclusive `int64_t` ranges with an `int` counter.
A ranged descriptor with an explicit `[begin, end]` range ending at `2^31 - 1` expands that valid position, then overflows when advancing the counter to exit the loop.
Trap-enabled builds terminate, while other builds invoke undefined behavior.

**Fix:** Use `int64_t` for loop control so the one-past-the-end value is representable and every position passed to `Descriptor::Expand()` remains within its existing `int` range.

Related: [#26275](https://github.com/bitcoin/bitcoin/pull/26275) fixed the same endpoint overflow in `deriveaddresses`.

ACKs for top commit:
achow101:
ACK 264555af3cc2ab2919e49e7dea3f8066b9336020
polespinasa:
ACK 264555af3cc2ab2919e49e7dea3f8066b9336020
sedited:
ACK 264555af3cc2ab2919e49e7dea3f8066b9336020

Tree-SHA512: 4326182b5897b6f6672e5f7c7296eafdbb6e3b5ed901d61e8fa2cff9b19d372bb8adb88902368dc520ed400e12dd5264ea68677d9ce0feec76fa2ef55fa0d2f4

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
signing boundarymemory safetymerge-commit duplicate discount
AI analysis · Moderate 62/100

This update fixes a counting bug in several Bitcoin Core RPC commands that scan descriptors. When a user requested a descriptor range ending at the maximum allowed value (2,147,483,647), the internal counter used a smaller integer type and could wrap past its maximum, causing undefined behavior. In practice this could crash builds that catch such errors, or silently misbehave in others. The fix widens the loop counter to a 64-bit integer so it can safely reach and pass the endpoint. A test was added to confirm the edge case now works.

AI review queuedMerge bitcoin/bitcoin#35842: rpc: Properly make RPCResult::Type::ANY non-test-onlyby merge-script · c36ffd87 · Aug 6, 2026 · 4 filesMessage 91 · StrongInformational 19Details
Commit message · merge-script

Merge bitcoin/bitcoin#35842: rpc: Properly make RPCResult::Type::ANY non-test-only

fac4b06e997e197d6dca4c41bdec99c0ba84cfca refactor: Use CLIENT_NAME in buildOpenRPCDoc (MarcoFalke)
fa3aadbc32e01386ddf54263d756b7a89b30addf refactor: Use self.Arg<bool> in getopenrpcinfo (MarcoFalke)
fa1871a52816e7d79a29bd7cabe2901e67acf71e refactor: Remove stale NOLINTNEXTLINE above GetAddressInfoBaseFields (MarcoFalke)
fa2264791490a16e55e404687140d47c58972387 rpc: Properly make RPCResult::Type::ANY non-test-only (MarcoFalke)
fa1242dcc02212154913745bb41aad12dd42761e refactor: Use std::visit in ApplyArgFallback (MarcoFalke)

Pull request description:

Commit 6a1a66c180cba5f2d4189e89327de23505c7f4dd attempted to properly render RPC results of the type `ANY`.

However, the commit is incomplete.

Fix it, by properly rendering all `ANY` types.

Moreover, a few trivial refactors after https://github.com/bitcoin/bitcoin/pull/34683 are included here.

ACKs for top commit:
sedited:
ACK fac4b06e997e197d6dca4c41bdec99c0ba84cfca
willcl-ark:
ACK fac4b06e997e197d6dca4c41bdec99c0ba84cfca

Tree-SHA512: b77f1956e4feb9afb93d38245491eec190c4538aec7ac57c327fb2efd86c7da6ee8a1406f81fc18fac06bae77a7d38845a537ca0b8f4ae2d94c38eefd8e88dc1

91/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
Why it was queued
signing or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Informational 19/100

This is a small cleanup and documentation fix for Bitcoin Core's RPC help system. It removes a comment that incorrectly said a certain output type was 'for testing only' and makes the help text properly display those outputs. There is no direct security vulnerability here; the change is about making generated API documentation accurate and consistent.

Lower-priorityMerge bitcoin/bitcoin#35895: refactor: Enable clang-tidy rule to reject anon namespace in headerby merge-script · c4fbd3c7 · Aug 5, 2026 · 3 filesMessage 93 · StrongInformational 15Details
Commit message · merge-script

Merge bitcoin/bitcoin#35895: refactor: Enable clang-tidy rule to reject anon namespace in header

fa93132d6da508597205513725ba4663d3a24954 refactor: Enable misc-definitions-in-headers (MarcoFalke)
fa5ca877b60339c858b5045f855ae0256e63b69d refactor: Enable clang-tidy rule to reject anon namespace in header (MarcoFalke)
fafe5042bd1b8c53faf3c0dfe40958f605666d67 refactor: Use C++20 std::identity over IntIdentity (MarcoFalke)

Pull request description:

This avoids issues like https://github.com/bitcoin/bitcoin/pull/35737 from passing CI in the first place.

Also, the rule can help to avoid ODR issues, according to https://clang.llvm.org/extra/clang-tidy/checks/fuchsia/header-anon-namespaces.html

This follows https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#sf21-dont-use-an-unnamed-anonymous-namespace-in-a-header

ACKs for top commit:
sedited:
ACK fa93132d6da508597205513725ba4663d3a24954

Tree-SHA512: c1a9d573aed9f295a9fb1931e96e37a9c39e2339392af79d0a3441ebd29282812c2614eab13a01e0d508802f66b73e8f2387ffcbb7dd28676b4fa43f81f9a680

93/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
Why it was queued
merge-commit duplicate discount
AI analysis · Informational 15/100

This is a code cleanup change that turns on a static-analysis rule to prevent a specific C++ coding pattern (anonymous namespaces in header files) and updates two headers to comply. It does not change how Bitcoin Core behaves at runtime and does not fix an active security bug.