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
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.
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.
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.
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.
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.
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.
AI review queuedMerge bitcoin/bitcoin#36226: doc: Move release notes to wiki ahead of branch-offby merge-script · 4d463de8 · Sep 11, 2026 · 44 filesMessage 81 · StrongInformational 15Details
Commit message · merge-script
Merge bitcoin/bitcoin#36226: doc: Move release notes to wiki ahead of branch-off
5df082721cdb013bb2308e00593282085e7d1198 doc: Move release notes to wiki ahead of branch-off (sedited)
Pull request description:
Draft release notes are ready for editing over here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/v32.0-Release-Notes-Draft
ACKs for top commit: fanquake: ACK 5df082721cdb013bb2308e00593282085e7d1198 hebasto: ACK 5df082721cdb013bb2308e00593282085e7d1198.
This commit is purely administrative housekeeping: it deletes 44 draft release-note files from the Bitcoin Core source tree because the notes have been moved to a project wiki ahead of a release branch-off. No program code, configuration defaults, or security behavior is changed. The deleted files only described features and fixes that already exist in earlier merged code.
AI review queueddoc: Move release notes to wiki ahead of branch-offby sedited · 5df08272 · Sep 11, 2026 · 44 filesMessage 50 · ThinInformational 15Details
Commit message · sedited
doc: Move release notes to wiki ahead of branch-off
50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
This commit only deletes release-note documentation files (421 lines removed across 44 files) as part of moving them to the project wiki ahead of a release branch-off. No program code, build scripts, tests, or configuration logic were changed. It cannot introduce, fix, or enable any security vulnerability by itself.
This PR follows our [Release Process](https://github.com/bitcoin/bitcoin/blob/fc4f35fdce4d65696be6bf34003dbcac1f2f64bf/doc/release-process.md) and concludes the translation-related work for this release cycle.
It is one of the steps required _before_ branch-off, as scheduled in https://github.com/bitcoin/bitcoin/issues/33607.
Previous similar PR: https://github.com/bitcoin/bitcoin/pull/34718.
**A note for reviewers:** The actual translations on Transifex are a moving target. As a result, your diff after running [`bitcoin-maintainer-tools/update-translations.py`](https://github.com/bitcoin-core/bitcoin-maintainer-tools/blob/main/update-translations.py) may differ.
ACKs for top commit: sedited: ACK 2c2667eaa9021cf98f6dc2e3e01eb0ee9c8e9288
This commit is a routine update of translated user-interface text for the Bitcoin Core Qt (graphical) wallet in preparation for the 32.0 release. It adds, removes, and reorders translated strings in many language files, and registers one new language (Latin, 'la') in the resource list. There are no code logic changes, no executable changes, and no security fixes or security-relevant behavior changes.
AI review queuedMerge bitcoin/bitcoin#36218: build: avoid `pipe2` on Darwin (for now)by merge-script · 51b540c5 · Sep 10, 2026 · 1 fileMessage 91 · StrongLow 33Details
Commit message · merge-script
Merge bitcoin/bitcoin#36218: build: avoid `pipe2` on Darwin (for now)
9c7748315d3124d1abe6a4606743cd9274beee66 build: avoid pipe2 on Darwin (for now) (fanquake)
Pull request description:
macOS 27 will support `pipe2` at runtime, and Xcode 27 (and Command Line Tools) support it at compile time. This means a macOS < 27 system will detect support for `pipe2`, but then binaries will crash at runtime, as pipe2 is not available.
Just avoid `pipe2` on macOS for now, and continue using `pipe`. Note that the compilation also produces availability warnings: ```bash [415/1121] Building CXX object src/util/CMakeFiles/bitcoin_util.dir/tokenpipe.cpp.o ../src/util/tokenpipe.cpp:89:9: warning: 'pipe2' is only available on macOS 27.0 or newer [-Wunguarded-availability-new] 89 | if (pipe2(fds, O_CLOEXEC) != 0) { | ^~~~~ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/unistd.h:219:9: note: 'pipe2' has been marked as being introduced in macOS 27.0 here, but the deployment target is macOS 26.0.0 219 | int pipe2(int [2], int); | ^ ../src/util/tokenpipe.cpp:89:9: note: enclose 'pipe2' in a __builtin_available check to silence this warning 89 | if (pipe2(fds, O_CLOEXEC) != 0) { | ^~~~~ 90 | return std::nullopt; 91 | } ``` and this will need to be backported. When macOS 27 is released, we could change approach, but wanted to PR something straightforward (and backportable) for `32.x`.
ACKs for top commit: hebasto: ACK 9c7748315d3124d1abe6a4606743cd9274beee66, tested on macOS Tahoe 26.6.2 with CLT 27.0: willcl-ark: ACK 9c7748315d3124d1abe6a4606743cd9274beee66
✓ 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 is a build-system fix for Bitcoin Core on macOS. Apple's upcoming developer tools report that a function called `pipe2` is available, but older macOS versions do not actually provide it at runtime, which would cause Bitcoin Core to crash when run on those systems. The change simply skips the `pipe2` feature check on macOS so the project falls back to the older, widely supported `pipe` function. It is a reliability/stability fix, not a security vulnerability patch.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit only fixes mistakes and outdated descriptions in the automatically generated help text for Bitcoin Core's remote procedure call (RPC) commands. It does not change what the software actually does, how it processes commands, or how it handles data. The changes make the documentation match the real behavior, so there is no security risk.
AI review queuedwallet: persist synced metadata and do not sync on loadby furszy · 752fd437 · Sep 9, 2026 · 2 filesMessage 77 · AdequateLow 35Details
Commit message · furszy
wallet: persist synced metadata and do not sync on load
Because we update variants during insertion, we no longer need to sync them during load.
77/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Explains rationale or failure mode
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 35/100
This Bitcoin Core wallet change makes two related adjustments to how metadata is kept in sync across 'malleated' transaction variants (different versions of related transactions stored in the wallet). First, when metadata is synchronized between variants during normal operation, the change is now immediately written to the wallet database. Second, the wallet no longer performs that synchronization step while loading transactions from disk, because the data should already be persisted. The patch is small and appears to be a correctness/durability improvement rather than a fix for an active exploit, but it prevents a potential inconsistency where in-memory metadata could differ from what is stored on disk.
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 14/100
This is a small code cleanup in Bitcoin Core's wallet. It replaces a hand-written list of field-by-field copies with a single statement that copies the same set of fields all at once. The behavior is unchanged; no security issue is introduced or fixed.
wallet: sync tx replacement metadata to malleated txs
50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 40/100
This Bitcoin Core wallet patch fixes a bookkeeping bug: when a user replaces (bumps) a transaction, the wallet now also marks any malleated versions of the original transaction as replaced. Without this, the wallet could let a user try to bump a transaction that was already replaced, which would waste fees and create confusion, but it does not appear to allow theft or remote code execution.
AI review queuedwallet: simplify and restrict SyncMetaData to malleated txsby furszy · 2efaa676 · Sep 9, 2026 · 3 filesMessage 73 · AdequateLow 35Details
Commit message · furszy
wallet: simplify and restrict SyncMetaData to malleated txs
Clarifies that SyncMetaData is supposed to copy metadata for malleated transactions only. Furthermore, ensure that copied metadata does actually make it to malleated transactions, rather than copying from a conflict that is not a malleation.
Code should now be friendlier to read/maintain and faster as well.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 35/100
This Bitcoin Core wallet commit refactors how the wallet copies user metadata (labels, comments, etc.) between transactions that are 'malleated variants' of each other—transactions that spend the same inputs but have different signatures/transaction IDs. Previously, metadata could be copied from any transaction sharing an input, even if it wasn't a true malleated variant. The new code restricts copying to genuine malleated variants only. The commit also fixes a benchmark test that was using unrealistic dummy inputs. The change is described as a cleanup and correctness improvement, not a security fix, but it does close a window where wallet metadata could be incorrectly propagated between unrelated transactions.
AI review queuedMerge bitcoin/bitcoin#36116: iwyu: Fix warnings in `src/rpc` and treat them as errorsby merge-script · 7e75b3b9 · Sep 9, 2026 · 29 filesMessage 81 · StrongInformational 15Details
Commit message · merge-script
Merge bitcoin/bitcoin#36116: iwyu: Fix warnings in `src/rpc` and treat them as errors
7d54a88b44530e5a37f8881b1ea73c2edd8ef541 iwyu: Fix warnings in `src/rpc` and treat them as errors (Hennadii Stepanov) 462ff18d79bd69a4b204e8bd28ce4903eb296060 iwyu, refactor: Fix includes in some source files (Hennadii Stepanov)
Pull request description:
This PR continues the ongoing effort to enforce IWYU warnings.
See [Developer Notes](https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#using-iwyu).
ACKs for top commit: stickies-v: re-ACK 7d54a88b44530e5a37f8881b1ea73c2edd8ef541
✓ 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 pathparser or protocol pathmerge-commit duplicate discountsecond-pass: unusually broad changesecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit is a routine code cleanup that adjusts which C++ header files are included in the RPC (remote procedure call) parts of Bitcoin Core. It also tells the project's automated 'include what you use' checker to treat mistakes in those files as errors going forward. There is no change to program logic, no bug fix, and no security-relevant behavior.
AI review queuedMerge bitcoin/bitcoin#35445: wallet, descriptor: Revert `StringType::COMPAT` for Miniscript expressions and drop the concept of a Descriptor ID that can be validatedby merge-script · fb26bc9c · Sep 9, 2026 · 18 filesMessage 100 · StrongModerate 57Details
Commit message · merge-script
Merge bitcoin/bitcoin#35445: wallet, descriptor: Revert `StringType::COMPAT` for Miniscript expressions and drop the concept of a Descriptor ID that can be validated
ec2adf3c51ca7322307be3d052bc0e9fa4332dd2 test: Check miniscript descriptor h and apostrophe equivalence (w0xlt) a2d001b57c5f7adc6649e96fc2254d729f4ba750 test: Enforce descriptor reimport is an update (Ava Chow) e2b2f1c5c6f720381b8cc182e750aadd703e4b4f descriptor: Rename DescriptorID to CompatDescriptorHash (Ava Chow) 6ad31c062c70101fe6463fe516de7edc651881be test: Add 31.0 to wallet backwards compatibility test (Ava Chow) 2a6c53371be770f7e945316481b231dcbed01dd9 wallet, spkm: Treat Descriptor ID as an opaque SPKM ID (Ava Chow) 62e826fa76172210572356eef9fa3cd3309baf56 wallet: Update WalletDescriptor from another one instead of overwriting (Ava Chow) 1113f7590ed095ec09a1d483f8c1ee5d54f0b0df wallet, export: Include descriptor cache when exporting descriptors (Ava Chow) 9fc7b2618b6abb0d79e794f34f16bebf74bbbe6a spkm: Remove DescriptorSPKM constructor that doesn't take a descriptor (Ava Chow) 770ff64bd7fd52e2c3d2634dc55046c5137cbe86 test: Add v30.2 and Miniscript to wallet backwards compatibility test (Ava Chow) 35d6a60dbf5a3424804430041f5f4091efb82b6c descriptor: Add ToCanonicalString (Ava Chow) 1d87af26ce1402d6fbc1db855434c36d0f7bd0c2 descriptors: Remove default StringType from PubkeyProvider::ToString() (Ava Chow) 1c7f9aaf758f6c8580a889fa6af675e6b365dbbf miniscript: Don't use StringType::COMPAT (Ava Chow)
Pull request description:
Since keys in Miniscript expressions were not correctly handling `StringType::COMPAT` when generating the Descriptor ID, in order to keep compatibility with previous versions, we need to continue to handle that enum incorrectly when computing the ID.
Given that this it the second time that we have had this issue, this PR also drops the concept of Descriptor ID being something that we can validate. Instead, the ID read in from the database is treated as an opaque blob that is used only to tie together the records related to a particular SPKM. It is instead treated as a ScriptPubKeyMan ID and users of it must be retrieving the ID from somewhere rather than computing it from a descriptor. The check of comparing the read ID to the computed ID is removed so that all previously created wallets can be read.
To clarify that the ID is not actually an ID, the function `DescriptorID` is renamed to `CompatDescriptorHash` and it is still used to generate the SPKM ID that is written to the database.
The ID was additionally being used to determine whether a descriptor is equal to another descriptor. This was used only by `importdescriptors` and `createwalletdescriptor`. These uses have been changed to do a string comparison rather than computing a hash and comparing the hashes. This removes the need to rely on `CompatDescriptorHash`.
The only caveat is that previously the hash was being used to do a map lookup in `m_spk_managers`, but this is now changed to use `std::find_if`. The lookup complexity changes from logarithmic to linear, which may be really bad for wallets with a lot of descriptors, e.g. migrated formerly non-HD wallets. I think in general though, the tradeoff is okay, and neither of these functions purport to be performant, especially as `importdescriptors` may also do a rescan which can take a long time. However, if that is a concern, an additional map of `CompatDescriptorHash` to DescriptorSPKM can be added.
Lastly, the wallet backwards compatibility test is updated to have 30.2 and 31.0 nodes, and a wallet with miniscript expressions. This exercises both creating wallets in previous versions and making sure they load in master, and making new wallets on master and checking whether they load, depending on the version.
Fixes #35432
ACKs for top commit: pseudoramdom: ACK ec2adf3c51ca7322307be3d052bc0e9fa4332dd2 davidgumberg: crACK https://github.com/bitcoin/bitcoin/commit/ec2adf3c51ca7322307be3d052bc0e9fa4332dd2 w0xlt: ACK ec2adf3c51ca7322307be3d052bc0e9fa4332dd2
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
defensive validationsigning or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Moderate 57/100
This Bitcoin Core update fixes a wallet bug where certain newer-style descriptors (called Miniscript) could not be loaded after being created in older versions. The root cause was an internal ID that was computed differently for Miniscript than for other descriptors. Rather than keep trying to make the ID match perfectly, the developers changed the wallet to treat the stored ID as an opaque label and compare descriptors by their text instead. This prevents 'wallet corrupted' errors and allows older wallets to load safely. It is a backward-compatibility and robustness fix, not a remote-exploitable vulnerability.
AI review queuedMerge bitcoin/bitcoin#36176: wallet: avoid a crash when creating a wallet with -nosettingsby Ava Chow · 013b0b2d · Sep 7, 2026 · 3 filesMessage 100 · StrongLow 44Details
Commit message · Ava Chow
Merge bitcoin/bitcoin#36176: wallet: avoid a crash when creating a wallet with -nosettings
I hit a crash while creating a new wallet in Bitcoin-Qt 31.1 on an Apple silicon Mac with `nosettings=1`. After looking through the crash report and code, I traced it to saving the wallet's load-on-startup setting: the settings writer throws when dynamic settings are disabled.
Wallet RPCs report errors with `-nosettings` after changing wallet state. In Qt, the same settings write causes an uncaught exception.
Return a persistence failure when dynamic settings are disabled so wallet operations finish with their existing startup-setting warning. This avoids an uncaught exception in Qt and RPC errors after the wallet state has already changed. Keep in-memory and no-op updates unchanged.
The first commit adds functional coverage for the current behavior. The second adds the fix, updates the assertions to expect success with warnings, and documents that failed settings writes keep the in-memory changes.
### Manual Reproduction
Run on the parent commit and the fixed commit, using a fresh temporary regtest data directory each time:
Choose `File` > `Create Wallet...`, enter `repro`, leave the defaults unchanged, and click `Create`.
Before the fix, the application terminates with:
```text libc++abi: terminating due to uncaught exception of type std::logic_error: Attempt to write settings file when dynamic settings are disabled. ```
After the fix, the wallet is created and the application displays:
```text Wallet load on startup setting could not be updated, so wallet may not be loaded next node startup. ```
ACKs for top commit: l0rinc: tested ACK a34fc8b11a420c1ed9877a5dd73aab57aba17cd0 kevkevinpal: tACK a34fc8b11a420c1ed9877a5dd73aab57aba17cd0 achow101: ACK a34fc8b11a420c1ed9877a5dd73aab57aba17cd0 jeanpablojp: tACK a34fc8b11a420c1ed9877a5dd73aab57aba17cd0
✓ 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 fixes a crash in Bitcoin Core's graphical wallet (Bitcoin-Qt) when creating a wallet while the user has disabled dynamic settings with -nosettings. Previously, the program would terminate with an uncaught exception because it tried to write to settings.json even though that file was disabled. After the fix, the wallet is created successfully and only shows a warning that the startup preference could not be saved. The same issue also caused RPC commands to return errors after the wallet state had already changed. The fix makes the settings write return a failure instead of throwing, so wallet operations complete normally and warn the user.
`DescriptorScriptPubKeyMan::AddDescriptorKey`, a private wrapper that lost its caller in #28333.
`COutput::ToString`, no callers. It was used by `COutput::print()`, which went away with the other `print()` methods in wallet.
The two `CHDChain` keypool index members, whose last uses went away with `LegacySPKM` in #28710.
`WalletDatabase::m_refcount`. Only BDB ever maintained it, and BDB went away in #28710.
The `warnings` parameter of `CreateFromDump`, never written, along with the loop that printed it in wallet-tool. The `push_back` went away with the `-format` option in #31250.
The two BDB-only members of `DatabaseOptions`, `use_shared_memory` and `max_log_mb`. Their last readers went away with BDB in #28710, along with the `-privdb` and `-dblogsize` options that set them.
ACKs for top commit: pablomartin4btc: ACK 9f0543d69a1357371017c8289d9addc457b6f132 vicjuma: ACK 9f0543d69a1357371017c8289d9addc457b6f132
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit is a routine cleanup that removes six pieces of unused wallet code from Bitcoin Core. Nothing is added or changed in behavior; only dead code is deleted. There is no security issue here.
