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
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.
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.
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#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.
AI review queuedMerge bitcoin/bitcoin#36230: wallet: Improve `HasWalletDescriptor` performance and other canonical descriptor string followupsby merge-script · 4a583f38 · Sep 19, 2026 · 9 filesMessage 100 · StrongInformational 18Details
Commit message · merge-script
Merge bitcoin/bitcoin#36230: wallet: Improve `HasWalletDescriptor` performance and other canonical descriptor string followups
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.
`getopenrpcinfo` emits two defaults that do not satisfy their schemas.
This changes `getdeploymentinfo.blockhash` to a default hint, since its fallback describes the current chain tip, and makes `send.options.include_watching` default to boolean `false`.
ACKs for top commit: nervana21: ACK b7f740c594ba1482344a7906b799fb62c533464f sedited: ACK b7f740c594ba1482344a7906b799fb62c533464f
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Informational 21/100
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 the string "false" to the actual value false. It does not change how Bitcoin Core processes transactions, validates blocks, or handles money. The only risk is that tools reading the OpenRPC metadata could previously receive invalid schema examples; this patch makes those examples valid.
Correct six argument metadata entries that produce misleading or invalid OpenRPC defaults.
The getdeploymentinfo blockhash fallback and four sighashtype fallbacks describe how omitted arguments are resolved. They are not literal values accepted by the RPCs, so mark them as DefaultHint values.
The send include_watching option is boolean, but its string default makes the generated schema internally inconsistent. Use a boolean value, matching the analogous sendall option.
Runtime behavior is unchanged.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 20/100
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 unchanged, so there is no direct security risk to users.
Merge bitcoin/bitcoin#36286: crypto: Fix MuHash3072 division by itself
b388f9bd0d2bcc259d488638d479ba09a30ba040 crypto: Fix MuHash3072 division by itself (Fabian Jahr)
Pull request description:
`MuHash3072::operator/=` multiplies the numerator by the divisor's denominator and then the denominator by the divisor's numerator. But as it is currently implemented the divisor could be the MuHash object itself. When that is the case, the second step reads the numerator that the first step already updated, so `x /= x` actually leaves `1/D` instead of the empty set. This only goes unnoticed when the denominator is 1, which is the case in our existing fuzz target and benchmark. No code in the node/index divides MuHash objects by themselves, so runnings nodes are not affected.
Fixes the code by not using the potentially changed nominator, adds a test that reproduces the issue and updates the fuzz test to not always use denominator 1.
ACKs for top commit: furszy: utACK b388f9bd0d2bcc259d488638d479ba09a30ba040 sedited: ACK b388f9bd0d2bcc259d488638d479ba09a30ba040 sipa: utACK b388f9bd0d2bcc259d488638d479ba09a30ba040
✓ 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 evidencecryptography-sensitive pathmerge-commit duplicate discount
AI analysis · Informational 24/100
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 modifying it, so the second multiplication step uses the original value rather than the already-changed one. The bug only affects self-division, and the project maintainers state that no live node or index code actually performs this operation, so running Bitcoin nodes are not affected. Tests and fuzzing targets were updated to catch this case in the future.
AI review queuedMerge bitcoin/bitcoin#36285: refactor: Use static const over inline const to work around ld64 bugby merge-script · ad97933a · Sep 17, 2026 · 2 filesMessage 93 · StrongInformational 18Details
Commit message · merge-script
Merge bitcoin/bitcoin#36285: refactor: Use static const over inline const to work around ld64 bug
fa8fefb29b6ce00c27638bc1c6f8ab5d58d48cb0 refactor: Use static const over inline const to work around ld64 bug (MarcoFalke)
Pull request description:
This partially reverts fa74f58a262096f25d5a3a4ec4951f4ce2a31792 to avoid initialization dependencies, which ld64 fails to handle properly.
Works around https://github.com/bitcoin/bitcoin/issues/36281 for now.
Obviously this will increase the bin size again (70kB for me), but this shouldn't matter much.
ACKs for top commit: janb84: ACK fa8fefb29b6ce00c27638bc1c6f8ab5d58d48cb0 sedited: ACK fa8fefb29b6ce00c27638bc1c6f8ab5d58d48cb0
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Informational 18/100
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, but it does not fix any vulnerability that could be exploited by an attacker.
2c249dbdf5c9d8c7dd71ac90ea29a8b52ec4b2ba wallet: Add an importDescriptors() interface for the wallet (Pol Espinasa) 3be5f401370ee18dc263149c8a23a33cba9baef5 wallet: add CheckDescriptorRangeBounds (Pol Espinasa) a9cd985d0a54877ef3ba9b844f725a2d3065f1bb wallet: Move ImportDescriptor and ProcessDescriptorsImport to imports.cpp (Pol Espinasa) c9650d8f0e2f664b4f4362a42e8dfc7efc82af18 wallet: rename ProcessDescriptorImport to ImportDescriptor and add ProcessDescriptorsImport (Pol Espinasa) a40ee4ec26590c4e485f5bb0155d90b4438ee590 wallet: rpc: refactor: ProcessDescriptorImport returns ImportDescriptorResult (Pol Espinasa) 48d3d717fb6e3f61acbaf867404e51a1cac77e78 wallet, util: Add HandleWalletErrorCode (Pol Espinasa) 04c73a91d2cc4165b90dc43b8932b128b8e1923f wallet: Add ImportError struct and new WalletError codes (Pol Espinasa) 975215618505e2d62c17cb63ce94ca2a72e79ffc wallet: rpc: refactor: Extract UniValue processing from ProcessDescriptorImport (Pol Espinasa) f1f61af357275f277c169e895d39699f918ef7aa wallet: Add ImportDescriptorRequest structs (Pol Espinasa) 7375124f4c9a7d998bf6e0f1eed3975f0ea761e3 wallet: refactor: make is_ranged no longer an optional (Pol Espinasa) 90485103c67d2454efa10743b1a2e6d844f74c58 wallet: lower the minimum timestamp to 0 (Pol Espinasa) 380d3ae0deab72c2652b3290bfe00195cca4f8e9 wallet: rpc: Use std::optional in GetImportTimestamp (Pol Espinasa)
Pull request description:
This PR adds an interface for importing descriptors.
The motivation behind this is that currently, importing descriptors is only possible via RPC. Bitcoin Core GUI doesn't use the RPC interface so it cannot offer descriptor import functionality, which is needed to support more complex wallet setups such as multisig.
This PR also adds a refactor by moving the `importdescriptors` logic from the RPC layer into `CWallet::ImportDescriptor`, making it reusable by both the RPC and this new interface.
The main changes are:
- Introduces `CWallet::ImportDescriptor()` containing the core import logic, previously embedded in the RPC `ProcessDescriptorImport` function. - Introduces `wallet::ImportDescriptorResult`, a new result struct that carries success status, error message, warnings, and a `FailureReason` enum. The RPC layer uses `FailureReason` to map results back to the appropriate JSON-RPC error codes, keeping RPC concerns out of `CWallet`. - Updates `ProcessDescriptorImport` in `rpc/backup.cpp` to delegate to `CWallet::ImportDescriptor`. - Adds `interfaces::Wallet::importDescriptors()` as a new interface method, allowing the GUI to import descriptors without going through RPC.
I have a GUI menu here: https://github.com/polespinasa/bitcoin/pull/7 so it can be tested. I will open a PR against the main GUI repo, once this gets merged.
ACKs for top commit: achow101: re-ACK 2c249dbdf5c9d8c7dd71ac90ea29a8b52ec4b2ba w0xlt: reACK 2c249dbdf5c9d8c7dd71ac90ea29a8b52ec4b2ba arejula27: reACK 2c249dbdf5c9d8c7dd71ac90ea29a8b52ec4b2ba
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Informational 23/100
This commit 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 minimum allowed timestamp is changed from 1 to 0. There is no direct evidence in the commit of a security vulnerability; it appears to be a normal feature/refactor change. The small behavior change around timestamps is a stricter validation, not a weakening.
AI review queuedMerge bitcoin/bitcoin#36260: torcontrol: Use reconnect backoff after dropped connectionsby merge-script · fb68c270 · Sep 16, 2026 · 2 filesMessage 100 · StrongLow 30Details
Commit message · merge-script
Merge bitcoin/bitcoin#36260: torcontrol: Use reconnect backoff after dropped connections
4556ef62675400a4702d73c0a3e1dd4c7061a077 torcontrol: Apply reconnect backoff after dropped connections (Fabian Jahr)
Pull request description:
Since #34158 the reconnect backoff was only applied when connecting to the Tor control port failed. When an established connection was dropped, for example by Tor closing it after a failed `AUTHENTICATE` because of a wrong password, the control thread reconnected immediately in a loop without any wait. This was resulting in us trying to make tons of connections to torcontrol and producing tons of log entries in very short time. The fix restores the pre-#34158 behavior where every reconnect waits for the backoff timeout by going through `disconnected_cb`, which now also does the waiting. Also adds a functional test to cover that the waiting behavior is actually applied.
ACKs for top commit: willcl-ark: reACK 4556ef62675400a4702d73c0a3e1dd4c7061a077 winterrdog: tACK 4556ef62675400a4702d73c0a3e1dd4c7061a077 sedited: ACK 4556ef62675400a4702d73c0a3e1dd4c7061a077
✓ 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
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 wait, Bitcoin Core would rapidly reconnect in a tight loop, creating a flood of connection attempts and log messages. The fix restores the intended pause between reconnect attempts. It is primarily a denial-of-service/operational-stability issue for the local node, not a remote code execution or theft vulnerability.
Merge bitcoin/bitcoin#36256: guix: Update osslsigncode to 2.14
59a465ce37829b2305319b378e8e85c9e653f29a guix: Validate codesigned windows binaries (Ava Chow) 66eeac216ad5b5b8d42a727aa730d7fc603f55fe guix: Use osslsigncode 2.14 (Ava Chow)
Pull request description:
#34550 mistakenly removed the package `nss-certs`. This results in an error during codesigining: `Use the "-CAfile" option to add one or more trusted CA certificates to verify the signature.`
However, introducing the package is not enough to make codesigning work. #34550 switched us to using osslsigncode 2.13 from upstream, but osslsigncode versions 2.6 through 2.13 all require network access as they validate CRLs. While the `verify` command has the ability to skip CRL validation, `attach-signature` does not.
osslsigncode 2.14 resolves both issues for us by removing signature validation, instead it only checks that the hash in the signature matches the hash of the binary. But we still want to do a belt-and-suspenders signature validation, and we can achieve this by calling `verify` afterwards with CRL validation disabled to avoid the network access issue, along with including the `nss-certs` package.
Lastly, guix upstream already has 2.14, so we could get it by bumping the time-machine commit. But it seems like bumping that is problematic for other packages, see #36233 and #35855. Instead, this PR copies in the package definition from upstream.
ACKs for top commit: Sjors: re-utACK 59a465ce37829b2305319b378e8e85c9e653f29a hebasto: re-ACK 59a465ce37829b2305319b378e8e85c9e653f29a, tested the signed installer on Windows:
✓ 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 boundarydefensive validationsigning or wallet pathmerge-commit duplicate discount
AI analysis · Informational 18/100
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 version required internet access. The patch adds the missing certificates package, upgrades the signing tool to version 2.14, and changes the verification step so it no longer needs network access. This is a build-infrastructure reliability fix, not a vulnerability in the Bitcoin software users run.
Security candidateMerge bitcoin/bitcoin#34566: feature: Use different datadirs for different signetsby merge-script · d32a515f · Sep 16, 2026 · 12 filesMessage 96 · StrongInformational 19Details
Commit message · merge-script
Merge bitcoin/bitcoin#34566: feature: Use different datadirs for different signets
feeb00af8cf361ba9d2f7de0334abf875b3103d9 cli: Add -signetchallenge info on RPC auth error (ekzyis) c47ea370dc9f7a878e8269884b25204b8e6a3ec6 doc: Update documentation for signet datadir (ekzyis) 6f8c43f9efc601b26ae221e53bb3c354ea64b618 test: Add signet datadir tests (ekzyis) 9b37d42b23be096cc4cfb457f1022e443102b650 Use different datadirs for different signets (ekzyis) 6bdcae3f768b9e8da958ecbf46fa88b42df338f5 refactor: Import signet constant and helper from kernel/signet.h (ekzyis)
Pull request description:
closes #27494
This adds support for syncing multiple signets.
Each custom signet is stored in a different datadir, using the network magic (message start) as the suffix.
The default signet is always stored without a suffix for backward compatibility, even if the default challenge is provided explicitly via `-signetchallenge`.
This builds upon #29838.
For those already familiar with #29838, here are the differences between #29838 and this that are visible to the user:
* The suffix does not use the first 4 bytes of hash160(challenge), but rather the network magic (message start) as mentioned in [#29838 (comment)](https://github.com/bitcoin/bitcoin/pull/29838#discussion_r1557976175) and [#34566 (comment)](https://github.com/bitcoin/bitcoin/pull/34566#issuecomment-4207665792). * If the default challenge is provided to `-signetchallenge`, [#29838](https://github.com/bitcoin/bitcoin/pull/29838) added a suffix to the datadir, whereas this PR does not. This includes backward compatibility when the default signet is used explicitly, not only implicitly, even though [the default signet consensus parameters aren't used in the explicit case](https://github.com/bitcoin/bitcoin/pull/29838#issuecomment-2742830552).[^1] A test was added for this case.
[^1]: could be something for a follow-up PR, or maybe it's intentional to not mix explicit with implicit options?
Unlike #29838, this PR does not update tests that didn't break (`rpc_bind.py`, `interface_bitcoin_cli.py`). I have found other tests where `datadir_path` is used in combination with `self.chain` (regexp: `datadir_path.*chain`). I considered it inconsistent to update some tests but not all of them. I've decided to not update all of them to keep the scope of this PR low until feedback. I can go through all tests in a follow-up PR to make sure they don't break when they are ever used with (custom) signet, however unlikely that might be.
I have done some manual testing like this:
<details> <summary>manual testing</summary>
1. 'signet' directory is used, IBD:
``` $ bitcoind -signet ```
2. 'signet' directory is used, no IBD without `-addnode` (see [#29838 (comment)](https://github.com/bitcoin/bitcoin/pull/29838#issuecomment-2742830552)) or existing peers.dat:
✓ 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
consensus or confidential-proof validationsigning or wallet pathmerge-commit duplicate discount
AI analysis · Informational 19/100
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 authentication failure might be due to using the wrong custom signet. There is no direct security vulnerability being fixed; it is a usability and data-isolation feature.
Merge bitcoin/bitcoin#36251: rest: add `generated` and `height` to spenttxouts JSON
1566a4767afd3865ee466d1aa2ce8237cb5c27c1 rest: add generated and height to spenttxouts JSON (0xb10c)
Pull request description:
This adds the `generated` and `height` fields to the JSON REST endpoint `/rest/spenttxouts/BLOCKHASH.json` to match the prevout output of the getblock RPC with verbosity 3. The information for these fields is already available, but just was not exposed.
The binary and hex formats aren't changed (here) to not break backwards compatibility with consumers of these endpoints. See the discussion in https://github.com/bitcoin/bitcoin/pull/32540#issuecomment-5665279713
ACKs for top commit: nervana21: tACK 1566a4767afd3865ee466d1aa2ce8237cb5c27c1 willcl-ark: ACK 1566a4767afd3865ee466d1aa2ce8237cb5c27c1 sedited: ACK 1566a4767afd3865ee466d1aa2ce8237cb5c27c1
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
access controlmerge-commit duplicate discount
AI analysis · Informational 19/100
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 output match an existing RPC output. There is no indication it fixes a security bug or introduces a vulnerability.
Manual peers added via `-addnode`, `-connect`, or the `addnode` RPC represent explicit operator intent to keep those connections around.
During IBD, a manual peer can currently be disconnected if it triggers block-stalling logic. This can be surprising in `-connect` or `-addnode`-based setups, where the operator may prefer (and probably expect) to keep the peer connected even if it is not a useful block download peer at that moment.
This PR changes only the block-stalling path. Instead of disconnecting a stalling manual peer, it releases that peer's in-flight block requests so other peers can request them and IBD can continue.
After releasing the requests, the manual peer is temporarily skipped for block downloads. This avoids immediately assigning scarce IBD block download slots back to the peer that just stalled, while still allowing the peer to become eligible again after the cooldown.
This intentionally does not change block download timeout or headers sync timeout behavior.
ACKs for top commit: sedited: Re-ACK 5551d39b202bf0386fb40589817cd92f8afdaf59
✓ 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 boundarymerge-commit duplicate discount
AI analysis · Low 33/100
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 disconnect it. Now it releases the pending block requests to other peers so IBD can continue, pauses asking that peer for blocks for two minutes, and keeps the connection open. This matches operator intent that manual peers should stay connected, but it is a behavior change, not a fix for an exploitable vulnerability.
Merge bitcoin/bitcoin#36186: test: return False for a too-short ECDSA signature
00d0c5107b92c8972ab106c680579e06fd4fb100 test: return False for a too-short ECDSA signature (Ferdinando Ametrano)
Pull request description:
`verify_ecdsa` reads `sig[1]` before it checks `len(sig) < 4`, so a 0- or 1-byte signature raises `IndexError` instead of returning `False`, which the comment promises for any DER encoding error.
Move the length check ahead of the byte access, and add a regression test.
ACKs for top commit: optout21: reACK 00d0c5107b92c8972ab106c680579e06fd4fb100 sedited: ACK 00d0c5107b92c8972ab106c680579e06fd4fb100
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
signing boundaryfuzzing or regression evidencemerge-commit duplicate discount
AI analysis · Informational 20/100
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 check earlier so the function behaves as documented. It does not affect live Bitcoin network code, wallet signing, or transaction validation.
AI review queuedMerge bitcoin/bitcoin#36083: test: cover getrawtransaction on a stale block via txindexby merge-script · dd3c62c5 · Sep 14, 2026 · 1 fileMessage 100 · StrongInformational 15Details
Commit message · merge-script
Merge bitcoin/bitcoin#36083: test: cover getrawtransaction on a stale block via txindex
793e22eed586306d41e05811f749da6cbe29f3de test: cover getrawtransaction on a stale block via txindex (Íñigo Aréjula Aísa) a84fbf9dfd2cc173499fdc6b2267246cf9403292 test: name the getrawtransaction test nodes (Íñigo Aréjula Aísa)
Pull request description:
<!-- *** Please remove the following help text before submitting: ***
Pull requests may be closed immediately if they: - do not have a rationale and clear improvement - do not adhere to doc/AI_POLICY.md
GUI-related pull requests should be opened against https://github.com/bitcoin-core/gui first. See CONTRIBUTING.md -->
<!-- Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly:
* Any test improvements or new tests that improve coverage are always welcome. * All other changes should have accompanying unit tests (see `src/test/`) or functional tests (see `test/`). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change. * Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed. * Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible. * Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they *significantly* improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the [developer notes](/doc/developer-notes.md), stylistic code changes are usually rejected. -->
<!-- Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. --> This checks the `txindex` as the only possible source for a transaction in a stale block. **The response of `getrawtransaction `is checked to report that block as stale: confirmations 0, no time, no blocktime**.
It uses one transaction that cannot come back to the mempool once the block is disconnected: the block's coinbase which is asserted to be out of the mempool.
I didn't find an existing test that reaches the index this way.
ACKs for top commit: l0rinc: ACK 793e22eed586306d41e05811f749da6cbe29f3de sedited: ACK 793e22eed586306d41e05811f749da6cbe29f3de
✓ 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 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 in the active chain (confirmations 0, no time/blocktime). There is no change to production code, no bug fix, and no security patch.
Add functional test coverage for the error path in `CheckFeeRate()` when `calculateCombinedBumpFee()` returns `nullopt` because unconfirmed inputs span more than 500 mempool transactions (`CTxMemPool::GatherClusters` DoS limit).
The crash on this path was fixed in #34870; this PR adds the missing test requested in #34902.
The test builds eight independent 64-transaction clusters (512 total, above the 500 limit), keeps a wallet-owned RBF transaction that spends one output from each cluster out of the mempool, and asserts that `bumpfee` with an explicit `fee_rate` returns the expected wallet error instead of proceeding with an empty optional.
Closes #34902.
## Testing - [ ] `./build/test/functional/wallet_bumpfee.py` - [ ] Temporarily removed the early return in `CheckFeeRate()` and confirmed the test fails with `bad optional_access` instead of the expected error message
ACKs for top commit: rapennas: Tested ACK 47632ab2a3 furszy: ACK 47632ab2a3876825576b3f07e6f80e799e6ed58f sedited: ACK 47632ab2a3876825576b3f07e6f80e799e6ed58f
✓ 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
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 many other unconfirmed transactions (more than 500), the wallet returns a clear error message instead of crashing. The underlying crash was already fixed in an earlier pull request; this change simply adds the missing test coverage.
This commit adds a new 'bestblockhash' field to the getmininginfo RPC response in Bitcoin Core. It is a feature enhancement, not a security fix. The change lets mining software read the current chain tip hash and the next block's difficulty bits in a single API call, avoiding a harmless race where the chain tip might change between two separate calls. There is no vulnerability being patched.
Merge bitcoin/bitcoin#34681: wallet: move rescan logic into ChainScanner and wallet/scan
e67f75cf7d3e5a8f161d1525695c8653d225a01f wallet/scan: extract progress tracking helpers from `ChainScanner::Scan` (Novo) 062aa3ce56d72c03569743aa4142bcec2400bf8f wallet/scan: extract QueueNextBlock (Novo) 3655beb8f1531f780fffcbf2f1018d893b87e98e wallet/scan: extract block scanning logic to ScanBlock (Novo) 4535dc0c7885ad678074699627b363f382f29906 wallet/scan: extract block filter matching to ShouldFetchBlock (Novo) 72a37031d325e9f50bc95ef7496fc495b755962e wallet/scan: move WalletRescanReserver to scan files (Novo) 0274e80130af2cc58847b5d8f3628fa97a6f4b79 wallet/scan: move RescanFromTime to ChainScanner as ScanFromTime (Novo) db9185a44464b241dec7a20fdedd7142bc728b1e wallet: introduce ChainScanner as a CWallet member (Novo) 525163c2413ed595a6b9adbc682cc182339c0600 wallet/tests: pin rescan behavior (Novo)
Pull request description:
Part of https://github.com/bitcoin/bitcoin/pull/34400
This PR refactors the wallet rescan logic for improved readability and maintainability, and prepares the rescan logic for the changes in https://github.com/bitcoin/bitcoin/pull/34400.
CWallet previously owned all rescan-related concerns: atomic state variables, the WalletRescanReserver RAII type, RescanFromTime, and the entire block-scanning loop (ScanForWalletTransactions) as a single large member function.
This PR separates those concerns into a dedicated ChainScanner class, introduced in wallet/scan.h and wallet/scan.cpp:
- Scan state (fAbortRescan, fScanningWallet, progress, start time, passphrase flag) moves into ChainScanner atomics, exposed through Scanner(). - WalletRescanReserver - RescanFromTime becomes ChainScanner::ScanFromTime, keeping all scan entry points in one place. - ScanForWalletTransactions is replaced by ChainScanner::Scan and decomposed into focused helpers: ShouldFetchBlock, ScanBlock, ReadNextBlock, UpdateProgress, UpdateTipIfChanged, and ProcessBlock.
CWallet retains only a ChainScanner member and a Scanner() accessor. Callers that previously reached into CWallet for scan state now go through Scanner().
One slight behaviour change is introduced in this PR and is documented in the associated commit message. We previously attempted to read the block to scan before checking that it is active; now we check that it is active before the read attempt. It has no significant effect, but the change is documented.
This PR should be reviewed with the `--color-moved=dimmed-zebra` git option to aid review.
ACKs for top commit: achow101: ACK e67f75cf7d3e5a8f161d1525695c8653d225a01f polespinasa: re-ACK e67f75cf7d3e5a8f161d1525695c8653d225a01f pablomartin4btc: ACK e67f75cf7d3e5a8f161d1525695c8653d225a01f rkrux: lgtm ACK e67f75cf7d3e5a8f161d1525695c8653d225a01f
✓ 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 pathmerge-commit duplicate discount
AI analysis · Informational 19/100
This is a code cleanup change in Bitcoin Core's wallet. It moves the wallet's blockchain rescan logic out of the main CWallet class into a new dedicated ChainScanner class, without changing what the rescan does. The only intentional behavior change is the order of two internal checks: the code now verifies a block is still on the active chain before trying to read it, rather than after. The change is documented and tested, and appears to reduce risk rather than introduce it.
1bb5820b4411dfbc0ade5fada39d1a4af46dfa78 wallet: Add addhdkey interface (pseudoramdom) 82867073d6c3f3d160a7036ff3d7caa71c71651a wallet: Use WalletError for AddHDKey failures (pseudoramdom) f8769fc0b12459eedc1bd8e37001b7fccd12b33f wallet: Move addhdkey logic into CWallet (pseudoramdom) e1a2b25d6c3b1ed6d693d328d1aa5efaceb69c55 test: expand addhdkey coverage for locked wallet and bad key (Sjors Provoost)
Pull request description:
This PR adds a wallet interface for `addhdkey`.
The motivation is same as #34861 - while we have `addhdkey` RPC, Bitcoin Core GUI does not use the RPC interface. Having a dedicated wallet interface is helpful for GUI when performing multisig setup. When used in tandem with a similar interface for `derivehdkey` (#32784), the GUI can produce a shareable xpub during multisig setup.
Key changes: - Move the wallet logic from the `addhdkey` RPC into `CWallet::AddHDKey()`. - Update `addhdkey` RPC to call `CWallet::AddHDKey()` while keeping RPC-specific argument parsing - Introduce `WalletError`, a generic wallet-layer error type carrying a machine-readable `WalletErrorCode` and a translated user-facing message. - Update `addhdkey` RPC to use the above wallet helper. The RPC also exposes the master fingerprint in hex as `fingerprint` field. - Add `interfaces::Wallet::addHDKey()`, which generates and adds a new HD key and returns the master xpub. - Add unit test coverage for `interfaces::Wallet::addHDKey()`.
ACKs for top commit: davidgumberg: crreACK 1bb5820 achow101: ACK 1bb5820b4411dfbc0ade5fada39d1a4af46dfa78 polespinasa: ACK 1bb5820b4411dfbc0ade5fada39d1a4af46dfa78 w0xlt: ACK 1bb5820b4411dfbc0ade5fada39d1a4af46dfa78
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Informational 19/100
This commit refactors how Bitcoin Core wallets add new HD (hierarchical deterministic) keys. It moves the existing addhdkey logic from the RPC layer into a reusable CWallet method and exposes it through the wallet interface used by the GUI. The change is primarily a code-organization improvement to support future GUI multisig setup. It does not appear to introduce a security vulnerability; rather, it adds clearer error handling and tests for locked wallets and invalid keys.
2c6047df8746a1d5333d17ad999dd32c40aba90e test: Bumping a transaction prevents bumping malleations (Ava Chow) a44f9ad35058f0aa45a1cada9460f89f650ab261 test: Test rbf metadata sync of malleated tx (Ava Chow) 752fd437c7cf79f8987c556a43990c23f9a48756 wallet: persist synced metadata and do not sync on load (furszy) 31eedfc6fc8b4dbf75b9aa2b66255732c19f478b wallet: simplify wtx metadata sync (furszy) 6c16d76f790c169a6cb032b60594228c9f7af878 wallet: sync tx replacement metadata to malleated txs (furszy) 34533d5d22b635eb7529a6e457a4a62069e27909 wallet: Clarify IsEquivalentTo is actually checking malleation (Ava Chow) b973a355c4ebd94cfa8cef61b68ac6da92fad787 Replace CTransaction::operator== with Equals that has options (Ava Chow) 2efaa6763bd210b367f4e67f67093156ef83da94 wallet: simplify and restrict SyncMetaData to malleated txs (furszy) fc718ade4fce8003a9460e7f79a4b2a21a4dc702 test: Test that metadata is synced to malleated transactions (Ava Chow)
Pull request description:
`SyncMetaData` is intended to handle the case of malleated transactions by copying the metadata from a presumed original transaction to all of the malleations of that transaction. However, it did not do this correctly, leading to both a crash that can be reached during `bumpfee`, and failing to actually copy the metadata to some malleated transactions.
The crash was reachable by having both the original transaction and a malleation of it in the wallet, then calling `bumpfee` on the original, and then calling `bumpfee` on the malleation. Calling `bumpfee` on the malleation would result in an assertion failure in `MarkReplaced`, hitting `Assert(!wtx.m_replaced_by_txid);`. This is reached since adding the RBF to the wallet causes a metadata sync between the original and the malleation, which copies `m_replaced_by_txid`. `MarkReplaced` is called soon afterwards, resulting in the crash. This is fixed by syncing the metadata after `MarkReplaced` sets `replaced_by_txid` during the RBF of the original transaction so that `bumpfee` refuses to bump the malleation in the first place as it will check `m_replaced_by_txid` before bumping.
The other issue is that if a RBF transaction is malleated, `SyncMetaData` was not copying the metadata from the original RBF transaction to the malleation.
These are fixed by changing `SyncMetaData` to find all of the malleations of a transaction rather than all of the conflicts and simplifying how it is called. Additionally, `CWalletTx::IsEquivalentTo` is used by `SyncMetaData` to determine whether a transaction is a malleation, and this PR pulls in https://github.com/bitcoin/bitcoin/pull/32723#issuecomment-3028112892 to make it explicitly clear which fields it is actually checking to determine the equivalence. Lastly, `SyncMetaData` is renamed to `SyncMalleatedTxMetadata` and `IsEquivalntTo` renamed to `IsMalleation` to clarify that these functions are for handling malleated txs.
The last 2 commits of this PR adds tests for these cases, and the first commit a test for basic `SyncMalleatedTxMetadata` functionality that should not change here.
ACKs for top commit: furszy: utACK 2c6047df8746a1d5333d17ad999dd32c40aba90e sedited: utACK 2c6047df8746a1d5333d17ad999dd32c40aba90e
✓ 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 · Moderate 60/100
This update fixes a bug in Bitcoin Core's wallet that could crash the program when a user tried to speed up (bump) a transaction that had a slightly altered copy (a 'malleated' version) in the wallet. It also ensures that notes, replacement links, and other metadata are correctly copied between the original transaction and its malleated copies. The crash was a denial-of-service-style failure for the wallet process, not a way to steal coins, and it required the user to already have both the original and malleated transactions in their wallet.
1548d15de61886e0b8e67801146e9c168d9d4a66 walletdb: Rename WriteTx to WriteFullTx (Ava Chow) 9a0628d9320d2275d922d70d1a87573091840293 wallet: Write tx to database during CWalletTx::Update (Ava Chow) 1c557a380288df661e13e88f5d9c7c27b9bbbefb wallet: Add WriteTxMetadata to write just the tx record (Ava Chow)
Pull request description:
`wtxvariant` records should never change, so it is unnecessary for us to be rewriting all `wtxvariants` in a `CWalletTx` every time the `CWalletTx`'s state changes. Likewise, every time there is a new variant, `CWalletTx` states may not change so do not need to always be unconditionally written.
This PR adds a `WalletBatch::WriteTxMetadata` to write just the `tx` record (the former behavior of `WriteTx`) and renames `WriteTx` to `WriteFullTx` to indicate that it will write all relevant records for a `CWalletTx`. Most uses of `WriteTx` become `WriteTxMetadata`, except in migration and watch only export.
`AddToWallet` is changed to use `WriteFullTx` only for new transactions, and to do so immediately after the transaction is inserted to the wallet. `CWalletTx::Update` takes the `WalletBatch` now and will write the correct records according to what is actually being updated.
ACKs for top commit: polespinasa: re-ACK 1548d15de61886e0b8e67801146e9c168d9d4a66 pablomartin4btc: ACK 1548d15de61886e0b8e67801146e9c168d9d4a66 rkrux: lgtm ACK 1548d15de61886e0b8e67801146e9c168d9d4a66
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Informational 19/100
This is a Bitcoin Core wallet code cleanup, not a security fix. It changes how transaction records are written to the wallet database so that the program only rewrites the parts that actually changed, rather than rewriting everything each time. This reduces unnecessary disk writes and may lower the chance of database corruption during crashes, but it does not close a known vulnerability that an attacker could exploit.
