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 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 …
This commit only adds a new automated test to Bitcoin Core. It does not change any production wallet, mempool, or node code. The test verifies that when a user tries to bump the fee of a transaction whose unconfirmed inputs depend on too m…
Adds regression test for previously fixed crash path (bad optional_access in CheckFeeRate)No production code changes; no new attack surface introducedTest exercises DoS-limit error handling in fee bumping
**Problem:** PSBTv2 permits outputs to be added before inputs. An authenticated `descriptorprocesspsbt` request can abort the node while updating metadata for one of those outputs because `UpdatePSBTOutput()` traverses the output script with a signature creator for input index 0. ECDSA signing or a miniscript timelock check can then access the missing input.
**Fix:** Make `UpdatePSBTOutput()` traverse output scripts with a temporary one-input transaction while continuing to take the output from the PSBT's unsigned transaction. `MutableTransactionSignatureCreator` continues to require a valid input index. Output metadata traversal still records scripts and key origins, allowing outputs to be updated before inputs are added.
ACKs for top commit: jeanpablojp: tACK c0792889673da175661f29138a318614b33636cd achow101: ACK c0792889673da175661f29138a318614b33636cd w0xlt: ACK c0792889673da175661f29138a318614b33636cd polespinasa: ACK c0792889673da175661f29138a318614b33636cd
✓ 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
signing boundarysigning or wallet pathmerge-commit duplicate discount
AI analysis · Moderate 60/100
This commit fixes a crash bug in Bitcoin Core's PSBT (Partially Signed Bitcoin Transaction) handling. When a user created a PSBT that had outputs but no inputs yet—a valid situation in the newer PSBTv2 format—and then asked the node to update output metadata using the `descriptorprocesspsbt` RPC, the node could crash. The crash happened because the code tried to use input index 0 of a transaction that had no inputs. The fix creates a temporary one-input transaction just for safely walking through the output script, while still taking the actual output data from the PSBT itself. It is a denial-of-service class bug, not a theft-of-funds bug, and requires an authenticated RPC caller to trigger.
Merge bitcoin/bitcoin#35972: fuzz: Fix assertion in `txorphan`
01dde6b20578616af7620a2180ee6b5db0ca4793 fuzz: Fix assertion in txorphan (marcofleon)
Pull request description:
`EraseTx()` calls `LimitOrphans()`, which may evict announcements from a peer that didn't announce the erased transaction, causing that peer's usage to decrease. Relax the assertion in the `EraseTx()` branch that claimed usage of a non-announcer peer should be unchanged. Also, add assertions for the other cases.
ACKs for top commit: dergoegge: utACK 01dde6b20578616af7620a2180ee6b5db0ca4793 instagibbs: ACK 01dde6b20578616af7620a2180ee6b5db0ca4793
✓ 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 controlfuzzing or regression evidencemerge-commit duplicate discount
AI analysis · Informational 15/100
This change fixes a test-only assertion in a fuzzing harness for Bitcoin Core's orphan transaction handling. It does not alter production network code, consensus rules, or wallet behavior. The only effect is that an internal correctness check in a randomized test program now matches the actual behavior of the orphanage when transactions are removed. There is no security impact on real Bitcoin nodes or users.
Security candidateMerge bitcoin/bitcoin#35735: Add state to HTTPRequestby merge-script · 4800cb7a · Aug 17, 2026 · 4 filesMessage 100 · StrongLow 47Details
Commit message · merge-script
Merge bitcoin/bitcoin#35735: Add state to HTTPRequest
9954aa77280ecd67816e784815c6478a973f6635 http: don't parse any new requests from a client if m_req_busy = true (Matthew Zipkin) c7db3ae1f907a10748e608cd69899c7586bfc210 test: cover HTTPRequest state machine (Matthew Zipkin) 90676e24ad1aa44346aed586f19ba1c68c477394 Add state to HTTPRequest to avoid duplicate work over I/O cycles (Matthew Zipkin) 507e528e845034583dd21b884e6debb1ff5307e3 http: reuse HTTPHeaders to parse chunked trailer (Matthew Zipkin) 902d8908c94dbe837d712a408d63dcbac634d4c5 http: only read one HTTPRequest at a time per client (Matthew Zipkin)
Pull request description:
This PR reduces the memory consumption of the HTTP Server when reading data from connected clients, and improves performance especially when requests are large (i.e. requiring multiple TCP packets).
In https://github.com/bitcoin/bitcoin/pull/35182 the server copies as much data as it can from the socket into application memory, and then tries to parse as many complete HTTP requests as possible from that data. If a request is discovered to be incomplete, the in-progress request is abandoned. The server tries again on the next I/O cycle to read the same data from the buffer, duplicating work as many times as it takes before the client finishes sending the request (or times out).
This PR implements two improvements to this: 1. Only parse one request at a time from the receive buffer. The server processes requests from each client in series anyway. 2. Add state to `HTTPRequest` so it can be filled with data from the receive buffer over multiple I/O loop iterations without losing progress.
If a client sends large or multiple requests, that data will sit in the kernel's socket buffer instead of the application memory. Eventually the socket buffer will fill up and TCP backpressure will kick in, dropping the TCP window to 0 and blocking the client from sending any more.
A state machine for `HTTPRemoteClient` was [discussed previously](https://github.com/bitcoin/bitcoin/pull/35182#pullrequestreview-4322490068) to control resource consumption. Another nice benefit of this model (for a follow-up PR) will be to insert the RPC authentication check after reading 8kB-limited headers but before the 32MB-limited request body.
ACKs for top commit: winterrdog: re-ACK 9954aa77280ecd67816e784815c6478a973f6635 janb84: re ACK 9954aa77280ecd67816e784815c6478a973f6635 frankomosh: ACK 9954aa77280ecd67816e784815c6478a973f6635. fjahr: ACK 9954aa77280ecd67816e784815c6478a973f6635
✓ 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
access controlmerge-commit duplicate discount
AI analysis · Low 47/100
This change is a defensive hardening and performance fix for Bitcoin Core's built-in HTTP server. It rewrites how incoming HTTP requests are read so that the server no longer copies an entire large request into memory before processing it. Instead, it reads one request at a time and remembers partial progress across network reads. This reduces memory use and applies size limits more consistently, including to HTTP chunk trailers. The commit is not described by the project as a security fix, but it closes resource-consumption paths that could be abused by a malicious or misbehaving client.
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
✓ 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
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
✓ 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.
✓ 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.
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.
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.
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:
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.
✓ 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.
`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
✓ 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.
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
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
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.
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
✓ 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.
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
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.
Security candidaterefactor: Make all `const static` class members `constexpr`by rustaceanrob · 05c35c40 · Jul 24, 2026 · 24 filesMessage 100 · StrongInformational 15Details
Commit message · rustaceanrob
refactor: Make all `const static` class members `constexpr`
If a `static class` member is not inlined or `constexpr`, the linker will fail when attempting to ODR-use the constant (passing as `const T&`). These can be fixed by finding all member variables that are `const` qualified and inlining them with `constexpr`. There is a clang-tidy pull request that would lint these callsites: https://github.com/llvm/llvm-project/pull/162741
A script was used to modify these sites, however it cannot run as a scripted-diff because it uses clang-query and a build folder.
The script only queries for integer and enumeration types, as other data members would have to be marked `constexpr` or `inline` from what I understand: https://en.cppreference.com/cpp/language/static#Constant_static_members
Removing the ZMQ forward declaration was a clang-tidy lint.
The script used to find these sites, LLM assisted: ``` set -uxo pipefail
cd "$(git rev-parse --show-toplevel)"
BUILD=${BUILD:-build} if [ ! -f "${BUILD}/compile_commands.json" ]; then echo "error: ${BUILD}/compile_commands.json not found. Run cmake -B ${BUILD} first." >&2 exit 1 fi if ! command -v clang-query >/dev/null; then echo "error: clang-query not on PATH. Install clang-tools." >&2 exit 1 fi if ! git diff --quiet || ! git diff --cached --quiet; then echo "error: working tree has uncommitted changes. Commit or stash first." >&2 exit 1 fi
declare -A LINES while IFS=: read -r file line; do LINES[$file]+="${line} " done <<<"$FILTERED"
for file in "${!LINES[@]}"; do args=() for line in ${LINES[$file]}; do args+=(-e "${line}s/static const /static constexpr /") done sed -i "${args[@]}" "$file" done
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
Why it was queued
cryptography-sensitive pathsigning or wallet path
AI analysis · Informational 15/100
This commit is a code cleanup that changes many internal class constants from 'static const' to 'static constexpr'. In modern C++, constexpr constants are automatically inlined and avoid certain linker errors when used in specific ways. There is no functional change to Bitcoin's behavior, no bug fix, and no security-relevant change.
Security candidatescripted-diff: Use long form of shell options in Guix scriptsby Hennadii Stepanov · 2cb3bfa8 · Jul 23, 2026 · 6 filesMessage 83 · StrongInformational 15Details
Commit message · Hennadii Stepanov
scripted-diff: Use long form of shell options in Guix scripts
This improves readability and consistency across all Guix scripts.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing or wallet pathboot or update path
AI analysis · Informational 15/100
This commit is a purely cosmetic change in Bitcoin Core's Guix build scripts. It replaces the short shell command 'set -e' with its long-form equivalent 'set -o errexit'. Both forms do exactly the same thing: they make the script exit immediately if any command fails. There is no security issue and no functional change.
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing or wallet pathboot or update path
AI analysis · Informational 15/100
This commit only adds or updates copyright and license header comments at the top of several helper scripts used for Bitcoin Core's Guix build process. It does not change any executable code, logic, or behavior. There is no security risk.
✓ 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
fuzzing or regression evidenceconstant-time or timing behaviorcryptography-sensitive path
AI analysis · Low 28/100
This commit updates the secp256k1 cryptographic library inside Bitcoin Core to a newer version. The main change is adding support for a new optional feature called 'Silent Payments' (BIP352), which is a privacy-enhancing way to receive Bitcoin payments. The update also includes several smaller fixes and documentation updates, such as correcting a technical limit in a field-element comparison function, adding a safety check that x-only public keys must have even Y coordinates, and terminating a nonce-generation loop at a fixed maximum iteration count. There is no direct evidence in the commit message or diff that this is an emergency security patch for an active vulnerability; it reads as a routine feature and maintenance subtree update.
The C.UTF-8 locale is set by default in `guix shell`, and there is no reason to avoid it nowadays. This change also silences superfluous warnings from Qt tools, making build logs cleaner and other issues easier to spot.
Locales in the `guix-*` launch scripts have been updated as well for consistency with the rest of the codebase.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
signing or wallet pathboot or update path
AI analysis · Informational 15/100
This commit is a routine cleanup that changes the locale setting in Bitcoin Core's Guix build scripts from the old ASCII-only 'C' locale to the modern 'C.UTF-8' locale. It is not a security fix and does not change any behavior that could be exploited. The stated purpose is to reduce harmless warning messages from Qt tools during builds.
Security candidatep2p: Assume v2transport for addresses from seedsby Martin Zumsande · cf0f2aea · Jul 21, 2026 · 2 filesMessage 68 · AdequateInformational 19Details
Commit message · Martin Zumsande
p2p: Assume v2transport for addresses from seeds
By now, the vast majority of nodes in the network supports BIP324. Even if the optimistic guess would turn out to be wrong for a given node, we would just reconnect with v1. This is better than making v1 connections with peers when both nodes support v2.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
secret or key materialparser or protocol path
AI analysis · Informational 19/100
This change makes Bitcoin Core assume that hard-coded and DNS seed nodes support the newer BIP324 encrypted transport (v2) when first connecting. If the guess is wrong, the software falls back to the older v1 protocol automatically. It is a network-hardening/performance tweak, not a fix for an exploitable vulnerability.
Move the SipHash round, compression, and finalization operations shared by `CSipHasher` and `PresaltedSipHasher` into inline `SipHashState` methods. This centralizes state mutation, preserves the existing byte-path code generation, and keeps the security-sensitive follow-up focused on its changed block compression, round counts, and finalizer.
Co-authored-by: Pieter Wuille <pieter@wuille.net>
85/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100
This is a code cleanup (refactor) that moves the internal SipHash mixing steps into shared helper methods. It does not change how Bitcoin hashes data, how many rounds are run, or any user-visible behavior. There is no security bug being fixed here.
Add `SipHasher13UJ`, a block-oriented implementation accepting arbitrarily mixed 64-bit normal blocks and 256-bit jumbo blocks. For hash-table use, cryptographic hash outputs must make up all but a small bounded number of retained jumbo blocks.
The generic interface serves as the executable specification for the fixed-width overloads added next.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
cryptography-sensitive path
AI analysis · Informational 21/100
This commit adds a new, weaker variant of the SipHash algorithm inside Bitcoin Core's cryptography module. It is explicitly designed for low-security uses such as internal hash tables, not for protecting funds or network messages. The code itself appears to be a clean, intentional addition with extensive comments explaining the trade-offs. There is no indication in the commit that this fixes a vulnerability or introduces an exploitable bug.
Benchmark 32-byte hashes and inputs consisting of a 32-byte hash plus a 32-bit index with SipHash-2-4 and SipHash-1-3-UJ. The UJ benchmark zero-extends the index into one 64-bit normal block. Keep all four measurements together after shared correctness coverage and before changing `CCoinsMap`'s hasher.
Co-authored-by: Pieter Wuille <pieter@wuille.net>
78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100
This commit only adds new performance benchmark tests for a hash function called SipHash. It does not change any production code that handles Bitcoin transactions, networking, or wallet data. There is no security issue here.
Add const `SipHasher13UJ::Hash` overloads for one `uint256` jumbo block, optionally followed by one 64-bit normal block. Reuse the generic hasher's initialized state and define these short paths in the header because the new hasher benefits from inlining.
Co-authored-by: Lőrinc <pap.lorinc@gmail.com>
80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100
This commit adds two new shortcut methods for computing a specific SipHash variant on fixed-size inputs. It is a pure performance/ergonomics addition: the new methods copy the hasher's internal state before operating, so they do not alter the original object. There is no indication of a security bug or fix.
Lock SipHash-2-4 behavior into shared vectors before refactoring its round and finalization code. Store inputs as ordered hex byte blocks so `CSipHasher` and the independent Python implementation hash the same byte sequence, with applicable `PresaltedSipHasher` overloads checked against the same vectors. Add the 64 official SipHash-2-4 vectors alongside block-partition and empty-block cases for the generic path. Move randomized generic/fixed comparisons to the integer fuzzer.
SipHash-1-3-UJ coverage can add expected outputs for compatible 8- and 32-byte block sequences. The Python test reads a build-tree copy so functional-test staging behaves consistently when files are symlinked or copied.
Co-authored-by: Pieter Wuille <pieter@wuille.net>
90/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidencecryptography-sensitive path
AI analysis · Informational 15/100
This commit only adds new test data and test code for the SipHash hashing function used in Bitcoin Core. It does not change any production code that handles transactions, networking, or wallets. The goal is to make sure the existing SipHash implementation behaves correctly and stays correct during future cleanups.
✓ 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
update trustsigning or wallet path
AI analysis · Informational 15/100
This commit adds a new regression test to Bitcoin Core. It checks that when a wallet created on a newer version is loaded on an older version and then brought back to the newer version, the wallet still remembers alternative 'witness variants' of a transaction. It is purely a test file change and does not modify any production wallet or consensus code.
fuzzing or regression evidencecryptography-sensitive pathsigning or wallet path
AI analysis · Informational 15/100
This commit is purely a code-style cleanup. It adds a space between the macro name LIMITED_WHILE and its opening parenthesis across many fuzz test files, plus a few tiny formatting fixes like removing a redundant semicolon and fixing indentation. No program behavior changes, no security fixes, and no production code is touched.
