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:** The mempool memory estimate omits the txid set used to retry the initial broadcast of locally submitted transactions, so `getmempoolinfo` and `-maxmempool` undercount retained memory.
**Fix:** Count this set when calculating mempool memory usage.
✓ 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
merge-commit duplicate discount
Lower-priorityMerge bitcoin/bitcoin#35177: test: use MiniWallet for getblockstats test data generationby Ava Chow · a632d4f6 · Sep 23, 2026 · 2 filesMessage 91 · StrongTriage 0Details
Commit message · Ava Chow
Merge bitcoin/bitcoin#35177: test: use MiniWallet for getblockstats test data generation
b7cbd804284bb70f40c5beebf8d1d3ff614ae406 test: use MiniWallet for getblockstats test data generation (AgustinRivera)
Pull request description:
Fixes #31838. Follow-up to #33184.
This updates `rpc_getblockstats.py --gen-test-data` to generate its fixture data using `MiniWallet` instead of wallet RPCs.
The normal test path still loads predefined block/stat data from `rpc_getblockstats.json`, so the test continues to compare `getblockstats` results against fixed expected data rather than against freshly computed RPC output.
This keeps the generator independent of wallet behavior while preserving the existing regression-test structure.
Tested on a wallet-disabled Linux build: - `python3 /tmp/bitcoin-build/test/functional/rpc_getblockstats.py` - `python3 /tmp/bitcoin-build/test/functional/rpc_getblockstats.py --gen-test-data --test-data /tmp/rpc_getblockstats.generated.json` - `python3 /tmp/bitcoin-build/test/functional/rpc_getblockstats.py --test-data /tmp/rpc_getblockstats.generated.json`
ACKs for top commit: achow101: ACK b7cbd804284bb70f40c5beebf8d1d3ff614ae406 theStack: ACK b7cbd804284bb70f40c5beebf8d1d3ff614ae406 sedited: ACK b7cbd804284bb70f40c5beebf8d1d3ff614ae406
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
e3ee0ebd89e9955da94c8d806cfa1793baba9860 tests: add BIP352 test vectors as unit tests (josibake) f133d1373af6f58488f73fe3dc795d37c4796dd9 common: add bip352.{h,cpp} secp256k1 module (josibake) 44997c391afc1f3ae75d2331606e1261fd365801 Add "sp" HRP (josibake) 356c91f6ae51bd9e48db0920110ac9303f54f714 crypto: add KeyPair::GetSecpKeypair (josibake)
Pull request description:
This PR is part of integrating silent payments into Bitcoin Core. It is the second iteration of https://github.com/bitcoin/bitcoin/pull/28122, now based on https://github.com/bitcoin-core/secp256k1/pull/1765.
This project is tracked in https://github.com/bitcoin/bitcoin/issues/28536.
BIP352 This PR focuses strictly on the BIP logic and attempts to separate it from the wallet and transaction implementation details. This is accomplished by working directly with public and private keys, instead of needing a wallet backend and transactions for testing. Labels for the receiver are optional and thus deferred for a later PR.
Test vectors from the BIP are included as unit tests.
ACKs for top commit: rustaceanrob: reACK e3ee0ebd89e9955da94c8d806cfa1793baba9860 theStack: re-ACK e3ee0ebd89e9955da94c8d806cfa1793baba9860 achow101: ACK e3ee0ebd89e9955da94c8d806cfa1793baba9860
✓ 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
secret or key materialfuzzing or regression evidencemerge-commit duplicate discount
AI analysis · Informational 12/100
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 change introduces new code for encoding/decoding silent payment addresses, deriving output public keys, and scanning transactions for outputs belonging to the recipient. It is a feature addition, not a fix for a known security bug. There is no evidence in the commit or supplied references that this introduces a vulnerability or that any security incident occurred.
Merge bitcoin/bitcoin#35440: wallet: check descriptor cache xpub length before decoding
db7ec4fb976284581ba2adc77218af8711375d91 refactor: (de)serialize CExtKey/CExtPubKey through streams (Alhuda Khan) cb69853fc160d8a02c21510b8251b05913665672 wallet: check descriptor cache xpub length before decoding (alhudz)
Pull request description:
The descriptor cache records (`WALLETDESCRIPTORCACHE`/`WALLETDESCRIPTORLHCACHE`) deserialise their value into a vector whose length comes from the record itself, but `CExtPubKey::Decode` then reads a fixed `BIP32_EXTKEY_SIZE` bytes. A record encoding a shorter xpub makes `Decode` read past the vector (caught as a container-overflow under ASan).
The first commit rejects records whose serialised xpub isn't exactly `BIP32_EXTKEY_SIZE`, the same way the other malformed records in this loader return `DBErrors::CORRUPT`, with a unit test covering both cache types.
The second commit (per https://github.com/bitcoin/bitcoin/pull/35440#issuecomment-5050992564) replaces `CExtKey`/`CExtPubKey` `Encode`/`Decode` and `EncodeWithVersion`/`DecodeWithVersion`, the only (de)serialisation in the codebase that wrote into a caller-provided buffer, with `Serialize`/`Unserialize`, and routes the base58, PSBT and wallet cache code through them. The serialised bytes are unchanged, so base58 and PSBT encodings and the on-disk cache records are the same as before. The wallet loader now checks the record's CompactSize prefix and reads the xpub straight from the record stream.
ACKs for top commit: molnard: tACK db7ec4fb976284581ba2adc77218af8711375d91 achow101: ACK db7ec4fb976284581ba2adc77218af8711375d91 winterrdog: tACK db7ec4fb976284581ba2adc77218af8711375d91
✓ 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 safetycryptography-sensitive pathsigning or wallet pathmerge-commit duplicate discount
AI analysis · Low 45/100
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 before decoding it, and also replaces the old fixed-size buffer encoding with safer stream-based serialization used throughout the rest of the code. It is primarily a hardening fix against corrupt wallet data rather than a remote attack vector.
Adds an optional integer `coverage_check` argument to `deterministic-fuzz-coverage`. This makes it easier to isolate per-input nondeterminism from cross-input state leakage. Good for debugging.
ACKs for top commit: maflcko: review ACK 5945cb83ddcf5df841d1bcb3c5fea641e9e24cde 🌯 Crypt-iQ: crACK 5945cb83ddcf5df841d1bcb3c5fea641e9e24cde
✓ 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 evidencemerge-commit duplicate discount
Merge bitcoin/bitcoin#35893: test: cover submitpackage other-wtxid for same-txid-diff-witness
9054f7cde43a264300bb0567215bda5f55803ae5 test: cover submitpackage other-wtxid for same-txid-diff-witness (mercie-ux)
Pull request description:
The specific behaviour tied to the `// TODO: allow witness replacement in packages.` had no functional test anywhere, just the unit test coverage, showing the underlying mempool logic and not the RPC's actual JSON output. This test submits a same-txid-different-witness transaction via `submitpackage` while its counterpart is already in the mempool, and asserts `submitpackage` correctly reports `other-wtxid` pointing at the transaction already in the mempool, its existing, documented behavior, not something this change introduces. Verified the test can actually fail by temporarily asserting the wrong wtxid and confirmed it fails as expected.
ACKs for top commit: jeanpablojp: reACK 9054f7cde43a264300bb0567215bda5f55803ae5 sedited: ACK 9054f7cde43a264300bb0567215bda5f55803ae5 instagibbs: ACK 9054f7cde43a264300bb0567215bda5f55803ae5
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Merge bitcoin/bitcoin#36309: private broadcast: clarify claims, mark as experimental
f41372998377ab8310476f0c03294e69cc3222e8 private broadcast: mark feature as experimental (Greg Sanders) 2630d8e6c9d60579372c019e4b2cc7e73163a5d8 doc: scope claims about private broadcast feature (Greg Sanders)
Pull request description:
1. Some of the claims were too strong, so I reframed these in terms of risk reduction, hopefully making user expectations more aligned with what's done 2. As a newer feature, it probably should have been marked experimental already, as the interface is likely to change in the future as it matures
7c311f5c6c3ea5a0d0cc4da35177e6977cda87d1 doc: Add release notes for listrawtransactions (pablomartin4btc) b377786df14e4098cc2af2fa3a108b3371df9471 test: Add functional test for listrawtransactions (pablomartin4btc) 605c4fd3aee0cea04aef583e7ceeca2dd9a17718 wallet, rpc: Add listrawtransactions RPC (pablomartin4btc) ba6c179ba07cafb3f7e8a0baf9c9a73992b36695 wallet, rpc: allow omitting parent_descs from TransactionDescriptionString (pablomartin4btc) dc3e2bc6df6814f6b9b5ce1d5b24933e3f10ca8a wallet, rpc: extract PushTxAmountAndFee/PushTxDecoded helpers (pablomartin4btc)
Pull request description:
Add a new `listrawtransactions` RPC that returns wallet transactions without logical interpretation. Unlike `listtransactions`, which only lists transactions with an economic category (sends to external addresses, receives from outside), this RPC returns every transaction the wallet knows about — including consolidations and self-transfers that would otherwise be invisible.
Each transaction appears exactly once with its net wallet balance change (`amount`) and, when the wallet funded the transaction, the fee paid (`fee`). Pagination is supported via `count` and `skip` parameters, matching the interface of `listtransactions`.
Next possible follow-ups: - A filter parameter (`"all"` / `"received"` / `"sent"` / `"self"`) once per-tx semantics are agreed on - Some fields inherited from `TransactionDescriptionString()` carry references to `category` (e.g. `replaced_by_txid`, `parent_descs`) which don't apply here — could be cleaned up in a separate pass
Closes #34632.
Previous attempt: #35009 (by alfonsoromanz), closed in favour of a separate RPC as suggested by achow101.
ACKs for top commit: Bicaru20: reACK 7c311f5c6c achow101: ACK 7c311f5c6c3ea5a0d0cc4da35177e6977cda87d1 polespinasa: ACK 7c311f5c6c3ea5a0d0cc4da35177e6977cda87d1
✓ 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
access controlsigning or wallet pathmerge-commit duplicate discount
AI analysis · Informational 20/100
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 listtransactions RPC hides. The change is mostly a refactor of existing code into shared helpers plus a new RPC endpoint. There is no direct evidence in the commit of a security vulnerability, bug fix, or exploit.
Lower-priorityMerge bitcoin/bitcoin#27052: test: rpc: add last block announcement time to getpeerinfo resultby Ryan Ofsky · 71c30b60 · Sep 22, 2026 · 8 filesMessage 91 · StrongTriage 0Details
Commit message · Ryan Ofsky
Merge bitcoin/bitcoin#27052: test: rpc: add last block announcement time to getpeerinfo result
13ce46ba1a79c99882cc1ac768db1df1f25de098 doc: add release note for 27052 (Larry Ruane) 5d5397d841085d024643927d952aa19bf36a8236 test: add functional test for block announcement time tracking (Larry Ruane) 7d3d04e925c70c0bb1df25a01feace9a2e3f009f rpc: add last_block_announcement to the getpeerinfo output (Larry Ruane) 26a25162a48af567d819a3c59478ae924e4d21ce net: add m_last_block_announcement to CNodeStateStats (Larry Ruane) bb8bca630a8ad772a15433d7a57cee4868d7d7cb change m_last_block_announcement type from int64_t to NodeClock::time_point (Larry Ruane)
Pull request description:
This PR adds `last_block_announcement` to the per-peer `getpeerinfo` RPC result. This is the most recent time that this peer was the first to notify our node of a new block (one that we didn't already know about), or zero if this peer has never been the first to notify us of a new block. This timestamp already exists internally and is used for stale-tip eviction logic; this PR exposes it at the RPC layer.
This PR started out as a suggestion for additional test coverage, see https://github.com/bitcoin/bitcoin/pull/26172#issuecomment-1259678260. It turned out that the easiest way to test (already-merged) #26172 is to add this field to `getpeerinfo` and have a functional test verify its value. But it may also be useful to have this result in its own right, similar to that RPC's existing `last_block` field -- it indicates something about the quality of our peers. It allows one to predict which peer will be evicted when the stale tip logic activates. (I'm not sure if that would be useful, but it may be.)
The functional test added here fails without #26172, which is the main goal.
This PR does not test the actual stale-tip eviction logic; that's difficult to do with a functional test. But it does test the correctness of the timestamp that the eviction logic depends on. #23352 is an attempt to test the eviction logic using a unit test, it's not ready to be merged yet. I think having both kinds of tests would be beneficial.
ACKs for top commit: rkrux: lgtm ACK 13ce46ba1a79c99882cc1ac768db1df1f25de098 naiyoma: ACK 13ce46ba1a79c99882cc1ac768db1df1f25de098 ryanofsky: Code review ACK 13ce46ba1a79c99882cc1ac768db1df1f25de098
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Merge bitcoin/bitcoin#36155: doc: remove json quoting from gettxoutsetinfo and getblockstats cli examples
57a79c69627de7854d5aec7b6b121e4a987ceb52 doc: remove json quoting from gettxoutsetinfo and getblockstats cli examples (csjones)
Pull request description:
This is a followup change based on https://github.com/bitcoin/bitcoin/pull/33230#issuecomment-3216227775 because https://github.com/bitcoin/bitcoin/pull/33230 enabled handling cli arguments with either json or a string but the examples (i.e. `bitcoin-cli help gettxoutsetinfo` and `bitcoin-cli help getblockstats`) left the quotes. I considered adding a new example but felt that change might seem confusing.
ACKs for top commit: nervana21: ACK 57a79c69627de7854d5aec7b6b121e4a987ceb52 sedited: ACK 57a79c69627de7854d5aec7b6b121e4a987ceb52
This PR removes `m_getaddr_sent`, as it no longer behaves as originally intended. Initially, this flag was meant to track when a getaddr message was sent to a peer.
Now that the initial self-announcements are sent separately from getaddr responses, the self-announcement sets `m_getaddr_sent `to `false` even though we are still waiting for the getaddr response (1000 addresses). When the getaddr response does arrive, we rely on the size of the addr message, not the flag, to decide whether it should be relayed. This makes the flag redundant.
This is the current behavior:
- The initial self-announcement is not relayed but it flips m_getaddr_sent to be false - We use addr.size() to avoid relaying (1000) getaddr response.(assuming the other two flags are false) - The first addr message is relayed because the flag is false(this was not the case before https://github.com/bitcoin/bitcoin/pull/34146).
Removing this flag ensures that:
- The initial self-announcement is relayed. - The getaddr response is still not relayed, using the existing size-based check.
I had initially considered an alternative approach https://github.com/naiyoma/bitcoin/pull/14, where the self-announcement would not affect this flag and would therefore retain the initial behaviour, but i decided to reattempt its removal, as this was previously attempted, see https://github.com/bitcoin/bitcoin/pull/19794. Given the changes since then, I believe revisiting it is now more appropriate.
ACKs for top commit: w0xlt: ACK c8ee319fffa1b7674fad3a797cd6d5110435a74c danielabrozzoni: tACK c8ee319fffa1b7674fad3a797cd6d5110435a74c mzumsande: Code Review ACK c8ee319fffa1b7674fad3a797cd6d5110435a74c sedited: utACK c8ee319fffa1b7674fad3a797cd6d5110435a74c
✓ 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
merge-commit duplicate discount
Security candidateMerge bitcoin/bitcoin#35752: wallet: make encryption state updates atomicby Ava Chow · 7ee3d622 · Sep 22, 2026 · 18 filesMessage 91 · StrongModerate 68Details
Commit message · Ava Chow
Merge bitcoin/bitcoin#35752: wallet: make encryption state updates atomic
**Problem:** Wallet encryption and passphrase changes can leave database records and live key state out of sync when a database operation fails. Encryption can report success without persisting the master key, and a passphrase change can activate the new passphrase only in memory. Descriptor key write failures can publish keys that were not persisted, while erase failures can leave plaintext keys on disk. A failed encryption transaction commit aborts the node, and a re-encryption failure during a passphrase change can leave a previously locked wallet unlocked. Boolean results also force callers to duplicate error messages or report database and encryption failures as incorrect passphrases.
**Fix:** Publish wallet encryption state only after the database transaction commits, and publish newly inserted descriptor keys only after their database writes succeed. For passphrase changes, restore the original lock state after validating the old passphrase and replace the live master key only after persisting its re-encrypted value. These changes preserve the affected keys on failure and allow retries. Return structured errors from wallet unlock and passphrase changes so callers can share messages and report the specific failure. Fresh descriptor setup after the encryption transaction remains unchanged.
ACKs for top commit: achow101: ACK 6d2414542b86ff7d6eae0f4c873e47bc4e57a57c w0xlt: reACK 6d2414542b86ff7d6eae0f4c873e47bc4e57a57c
✓ 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 controlsigning or wallet pathauthentication pathmerge-commit duplicate discount
AI analysis · Moderate 68/100
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 was not actually saved to disk, or could leave unencrypted private keys behind. The patch makes these operations atomic: in-memory state is only updated after the database transaction commits, and failures now return clear, structured error messages instead of crashing the program or giving misleading 'wrong passphrase' errors.
a34861d280b3db81175b6692ba00ccc62edff52e test: unify how to avoid the creation of the default wallet in nodes (rkrux) 3458837a0b76fb7f5d4c2f5d9ebb9bd7818794be test: use ExtendedPrivateKey in wallet_importdescriptors.py (rkrux)
Pull request description:
Looks like a case was missed in PR #35543 that introduced the utility xprv and xpub classes.
Also, unify how to avoid the creation of the default wallet in nodes.
ACKs for top commit: davidgumberg: reACK https://github.com/bitcoin/bitcoin/pull/35619/commits/a34861d280b3db81175b6692ba00ccc62edff52e nebula-21: ACK a34861d280b3db81175b6692ba00ccc62edff52e sedited: ACK a34861d280b3db81175b6692ba00ccc62edff52e
✓ 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
signing or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Informational 15/100
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 is no change to the actual Bitcoin Core software that users run, so it cannot affect live wallets, transactions, or network security.
Merge bitcoin/bitcoin#36310: rpc: clarify that `getaddrmaninfo` counts unique addresses
0d34b6e9287f523adf1c85a05ada2ba21f0d820c rpc: clarify that getaddrmaninfo counts unique addresses (0xb10c)
Pull request description:
While using the `getaddrmaninfo` RPC for monitoring the sizes of my address managers, we noticed that it returns the count of unique addresses in the tables. While the addresses in the `tried` table are always unique, the `new` table might contain an address multiple times if we received it from sources in different network groups. I incorrectly assumed the returned values to be the number of address manager slots filled. To make this clearer for the next person, I'm clarifying this in the documentation.
The number of filled addrman slots can be derived from the output of the hidden `getrawaddrman` RPC.
ACKs for top commit: fjahr: ACK 0d34b6e9287f523adf1c85a05ada2ba21f0d820c stratospher: ACK 0d34b6e. danielabrozzoni: ACK 0d34b6e9287f523adf1c85a05ada2ba21f0d820c
Merge bitcoin/bitcoin#36261: test: cover PSBT unknown field merging
21e4ea8134d8ca95416e065490d99f82be66bd67 test: cover PSBT unknown field merging (w0xlt)
Pull request description:
Continuing the work from #35310 gere in agreement with w0xlt
This PR adds functional coverage for combinepsbt preserving unknown PSBT fields across global, input, and output maps, as suggested [here](https://github.com/bitcoin/bitcoin/pull/34893#issuecomment-4390043746).
The test covers both PSBTv0 and PSBTv2 by creating valid base PSBTs with `createpsbt`, injecting unknown key-value pairs into two copies, combining them, and asserting that all unknown fields are retained in the decoded result.
ACKs for top commit: polespinasa: ACK 21e4ea8134d8ca95416e065490d99f82be66bd67 nebula-21: ACK 21e4ea8134d8ca95416e065490d99f82be66bd67 winterrdog: tACK 21e4ea8134d8ca95416e065490d99f82be66bd67 w0xlt: ACK 21e4ea8134d8ca95416e065490d99f82be66bd67
✓ 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 boundarysigning or wallet pathmerge-commit duplicate discount
AI analysis · Informational 15/100
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 to the actual Bitcoin Core software behavior—only test code was added.
Lower-priorityMerge bitcoin/bitcoin#35887: ipc: use std::optional for checkSpawned(), add tests and rename arg -ipcfd to -ipcchildby Ryan Ofsky · f839ee1a · Sep 21, 2026 · 6 filesMessage 91 · StrongTriage 0Details
Commit message · Ryan Ofsky
Merge bitcoin/bitcoin#35887: ipc: use std::optional for checkSpawned(), add tests and rename arg -ipcfd to -ipcchild
05e7d573184079720e11d933d24b9c9228477a14 ipc, test: add checkSpawned() unit tests (ViniciusCestarii) 8bca7555f8328851bff0bf50d3bbdaa57aaac4b1 ipc, refactor: rename arg -ipcfd to -ipcchild (ViniciusCestarii) bd3a38f10ab7ef44a0f8e8626edf022831aa7e74 ipc, refactor: return std::optional<mp::SocketId> from checkSpawned() (ViniciusCestarii)
Pull request description:
Implement proposed follow-ups on dicussion https://github.com/bitcoin/bitcoin/pull/35084#discussion_r3664894660:
- Add unit test for checkSpawned(). - Make checkSpawned() return std::optional<mp::SocketId>. - Rename -ipcfd to -ipcchild.
ACKs for top commit: jeanpablojp: ACK 05e7d573184079720e11d933d24b9c9228477a14 enirox001: utACK https://github.com/bitcoin/bitcoin/pull/35887/changes/05e7d573184079720e11d933d24b9c9228477a14 ryanofsky: Code review ACK 05e7d573184079720e11d933d24b9c9228477a14. Thanks for the followup!
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Merge bitcoin/bitcoin#31888: contrib: Support re-writing linearize-data dumps
e9dc16194b47921ea6c5453e71c5c97b9232ba8c correct the linearize-data script (minor) (midnight)
Pull request description:
For tools using the linearization scripts to continuously create a data dump it is undesirable to truncate the dumped file every time it is written. Doing so makes it harder to be directly consumed by an external tool. To fix this, change the file open mode to not truncate the entire file. After this change dumps are byte-for-byte overwritten. Some trailing data at the end of the file might be left over from a previous run in case of a reorg. To guard against this, clip off any remaining data at the end of the file once the dump is completed.
(small patch being passed around which I did not write but thought would be helpful to the community)
ACKs for top commit: maflcko: lgtm ACK e9dc16194b47921ea6c5453e71c5c97b9232ba8c sedited: ACK e9dc16194b47921ea6c5453e71c5c97b9232ba8c
Merge bitcoin/bitcoin#36283: kernel: expose transaction version
83434f7683e45afc1ebbb7690a6ae288b2602b03 kernel: expose transaction version (nervana21)
Pull request description:
This PR is a follow-up to #36194 and #36207. It completes the existing set of transaction accessors allowing clients to read the transaction version without slicing serialized bytes.
Tests cover a range of versions.
ACKs for top commit: stickies-v: ACK 83434f7683e45afc1ebbb7690a6ae288b2602b03 yuvicc: lgtm! ACK 83434f7683e45afc1ebbb7690a6ae288b2602b03 sedited: ACK 83434f7683e45afc1ebbb7690a6ae288b2602b03
✓ 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
merge-commit duplicate discount
Lower-priorityMerge bitcoin/bitcoin#36206: build: drop use of `OBJC_OLD_DISPATCH_PROTOTYPES`by merge-script · bb529657 · Sep 19, 2026 · 1 fileMessage 81 · StrongTriage 0Details
Commit message · merge-script
Merge bitcoin/bitcoin#36206: build: drop use of `OBJC_OLD_DISPATCH_PROTOTYPES`
59f7f3d07d9556fa2e9df2f39d8b9057ca87fdc2 build: drop use of OBJC_OLD_DISPATCH_PROTOTYPES (fanquake)
Pull request description:
Now that we target macOS >= `14.0` and use macOS SDK `14.0`, and no-longer use `objc_msgSend`, this can be removed. Was added in #16720.
ACKs for top commit: willcl-ark: ACK 59f7f3d07d9556fa2e9df2f39d8b9057ca87fdc2
BOOST_AUTO_TEST_CASE(http_headers_tests) { + auto foo = HTTPHeaders{}.FindAll("needle"); // Emits warning + (void)foo; + auto bar{HTTPHeaders{}.FindAll("needle")}; // No warning with Clang 22.1.8 :/ + (void)bar; + + HTTPHeaders test; + auto baz = test.FindAll("needle"); + test.Write("needle", "mutation"); // No warning with Clang 22.1.8 :/ + { // Writing response headers HTTPHeaders headers{}; ```
</details>
Clang 24 has experimental invalidation detection so maybe that could be used in the far future: https://clang.llvm.org/docs/LifetimeSafety.html#use-after-invalidation-experimental
### Alternative solution A)
Return by copy everywhere. Might introduce more heap activity, especially in the case of `HTTPRemoteClient::GetRequest()`.
### Alternative solution B)
Refactor the methods to minimize copying while still making things more memory-safe. Replacing `HTTPHeaders::FindAll()` with an `Iterate()`-function taking a lambda which gets to process each header. Gets rid of the heap activity of building a `vector` but introduces copying of `first`.
<details><summary>Diff of httpserver.cpp/h</summary>
void HTTPHeaders::Write(std::string&& key, std::string&& value) @@ -504,18 +500,21 @@ bool HTTPRequest::LoadBody(LineReader& reader) // We read all the chunks but never got the last chunk, wait for client to send more return false; } else { + std::optional<std::string> first; + m_headers.Iterate([&first] (const std::string& key, const std::string& value) { + if (!CaseInsensitiveEqual(key, "Content-Length")) return; + if (!first.has_value()) { + first = value; + } else if (first != value) { + // Duplicate Content-Length headers are allowed only if they all have the same value + // https://www.rfc-editor.org/rfc/rfc7230#section-3.3.3 + throw std::runtime_error("Differing Content-Length values"); + } + }); // No Content-length or Transfer-Encoding header means no body, see libevent evhttp_get_body() - auto content_length_values{m_headers.FindAll("Content-Length")}; - if (content_length_values.empty()) return true; - - // Duplicate Content-Length headers are allowed only if they all have the same value - // https://www.rfc-editor.org/rfc/rfc7230#section-3.3.3 - const auto& first_content_length_value{content_length_values[0]}; - for (size_t i = 1; i < content_length_values.size(); ++i) { - if (content_length_values[i] != first_content_length_value) throw std::runtime_error("Differing Content-Length values"); - } + if (!first.has_value()) return true;
- const auto content_length{ToIntegral<uint64_t>(first_content_length_value)}; + const auto content_length{ToIntegral<uint64_t>(first.value())}; if (!content_length) throw std::runtime_error("Cannot parse Content-Length value");
if (*content_length > MAX_BODY_SIZE) throw ContentTooLargeError("Max body size exceeded"); --- a/src/httpserver.h +++ b/src/httpserver.h @@ -97,10 +97,9 @@ public: */ std::optional<std::string> FindFirst(std::string_view key) const; /** - * @param[in] key The field-name of the header to search for - * @returns Views into all values matching the provided key (valid while this object is alive) + * @param[in] fn Receives each header as they are iterated through. */ - std::vector<std::string_view> FindAll(std::string_view key) const LIFETIMEBOUND; + void Iterate(std::function<void(const std::string& key, const std::string& value)> fn) const; void Write(std::string&& key, std::string&& value); /** * @param[in] key The field-name of the header to search for and delete ```
</details>
### Rationale
The methods are not called in many places so risk of misuse is low, and we avoid any risk of performance degradation (such as the one found in https://github.com/bitcoin/bitcoin/pull/35182#discussion_r3266022600). Returning copies without adding mutexes or other thread safety measures does not considerably increase thread-safety.
ACKs for top commit: maflcko: lgtm ACK 0b46fc9c5935068e7068a27fa39fa11f32af7a3f l0rinc: code review ACK 0b46fc9c5935068e7068a27fa39fa11f32af7a3f
✓ 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 reverts commit 00a5f9b7375ec8dca944e200bd9bef6a29949409 as requested in https://github.com/bitcoin/bitcoin/pull/36161#issuecomment-5716292461 . As noted there the script still has users, so should not be removed.
ACKs for top commit: kevkevinpal: ACK [4f624bb](https://github.com/bitcoin/bitcoin/pull/36288/commits/4f624bb82ddf5c65c3a1c6210decd7d90ab634ae) marcofleon: ACK 4f624bb82ddf5c65c3a1c6210decd7d90ab634ae
Instead of re-computing the canonical descriptor string for every call to `HasWalletDescriptor`. `WalletDescriptor` will now compute it once upon construction and cache the hash of that string. The comparison uses a new `WalletDescriptor::Equals` function which compares the canonical string hashes. The hash is used to avoid holding possibly a large amount of memory for a string that is rarely used. This should fix the performance regression described in https://github.com/bitcoin/bitcoin/pull/35445#issuecomment-5633483553
Also addresses several review comments related to documentation and code readability: - https://github.com/bitcoin/bitcoin/pull/35445#discussion_r3924705885 - https://github.com/bitcoin/bitcoin/pull/35445#discussion_r3924785232 - https://github.com/bitcoin/bitcoin/pull/35445#discussion_r3925352894 - https://github.com/bitcoin/bitcoin/pull/35445#discussion_r3925462409 - https://github.com/bitcoin/bitcoin/pull/35445#discussion_r3937800942 - https://github.com/bitcoin/bitcoin/pull/35445#discussion_r3961028442
ACKs for top commit: Sjors: ACK 61edcf92532502e91c2e17b8c2a23b45f5773936 polespinasa: ACK 61edcf92532502e91c2e17b8c2a23b45f5773936
✓ 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
signing or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Informational 18/100
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 tidies up serialization code, removes a default constructor, and adds v31.1 to backwards-compatibility tests. There is no indication this fixes an exploitable security bug.
