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
`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.
Merge bitcoin/bitcoin#36249: net, rpc: Asmap version improvements/follow-ups
0b353a9e872e81b900a543d7fedf668be3afec2c netgroup: Cache asmap version (Fabian Jahr) c1e9d15406fb7b46cff1cf385607a3e47fdd1bfb doc: Describe how to verify the asmap in use (Fabian Jahr) 87ce88c1b53c0a954a53b5a1856ef0d20850f3d5 rpc: Add asmap_version to getnetworkinfo (Fabian Jahr) dd5a8a63b2232279e2ea46e4360434d36f379774 test: Check embedded asmap version log and addrman re-bucketing (Fabian Jahr) 0bc87365cac1ef8586a28d69eca95d8080512454 init: Log asmap version from NetGroupManager (Fabian Jahr) fdfd196908e1fce930ed0554d8a75d4be3cf5cec rpc: Reuse AsmapVersion in exportasmap (Fabian Jahr)
Pull request description:
This is a follow-up to #36215. I noticed the possible improvement in `exportasmap` and went through everything to see where else we could make changes where we can use this as an advantage.
- `rpc: Reuse AsmapVersion in exportasmap`: `exportasmap` hashed the file by hand to show the hash, instead we can use `AsmapVersion()` which is the same value. - `init: Log asmap version from NetGroupManager`: Drop the version variable in init and log the version by getting it from `NetGroupManager` instead - `test: Check embedded asmap version log and addrman re-bucketing`: We didn't cover rebucketing behavior in the functional test yet. Also gets rid of stale comment. - `rpc: Add asmap_version to getnetworkinfo`: Getting access to the asmap version from the logs may be a bit tedious for some users and now it may be even more interesting for them to compare the version to the hash attested to in `asmap-data`. So let them get it via `getnetworkinfo`. - `doc: Describe how to verify the asmap in use`: Just mention the latest changes from above and the opportunity to compare the version to the hash in seen in `asmap-data`.
ACKs for top commit: sedited: Re-ACK 0b353a9e872e81b900a543d7fedf668be3afec2c willcl-ark: ACK 0b353a9e872e81b900a543d7fedf668be3afec2c
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
merge-commit duplicate discount
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.
Lower-priorityMerge bitcoin/bitcoin#33593: guix: Use UCRT runtime for Windows release binariesby merge-script · b8215855 · Sep 16, 2026 · 10 filesMessage 91 · StrongTriage 0Details
Commit message · merge-script
Merge bitcoin/bitcoin#33593: guix: Use UCRT runtime for Windows release binaries
b07810544f15153c9d9136f9adeb9bf7cd86e619 Remove MSVCRT-specific workarounds (Hennadii Stepanov) 7c86a370c8a254adb2c9eefd4c229e542a40d4ce doc: Update Windows build docs to reflect migration from MSVCRT to UCRT (Hennadii Stepanov) f5910d1a3aaac058a0ba52f6a95ebb4a9a861780 ci: Remove Windows + MSVCRT jobs for cross-compiling and native testing (Hennadii Stepanov) 55f86ab1624ab884ccbd8bb7d0863cec8c389946 guix: Use UCRT runtime for Windows release binaries (Hennadii Stepanov)
Pull request description:
This PR: 1. Switches Windows release binaries to UCRT. 2. Update docs. 3. Drops MSVCRT workarounds.
ACKs for top commit: maflcko: review ACK b07810544f15153c9d9136f9adeb9bf7cd86e619 🏦 fanquake: ACK b07810544f15153c9d9136f9adeb9bf7cd86e619 - will followup with some docs / other related changes. This also doesn't add a check for the release builds.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
merge-commit duplicate discount
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.
Lower-priorityMerge bitcoin/bitcoin#36160: refactor: Minor improvements to HTTP unit testsby merge-script · a6871881 · Sep 16, 2026 · 1 fileMessage 91 · StrongTriage 0Details
Commit message · merge-script
Merge bitcoin/bitcoin#36160: refactor: Minor improvements to HTTP unit tests
f04b0c31627adda1d54b7da4507cfe30a63f7e5e refactor(test): Make test method use Uppercase, shorten enum values (Hodlinator) 6eea8e313cce96be15fc0b5bb95c58aa9b77202b refactor(test): Simplify HTTP response check (Hodlinator)
Pull request description:
Improves recently added unit tests. * Simplify HTTP response check in `http_server_socket_tests`, it was incorrectly referring to `unordered_map` * Make `http_request_state_tests` unit test method use Uppercase as per developer-notes.md, shorten `enum` values for readability
ACKs for top commit: winterrdog: tACK f04b0c31627adda1d54b7da4507cfe30a63f7e5e janb84: ACK f04b0c31627adda1d54b7da4507cfe30a63f7e5e pinheadmz: ACK f04b0c31627adda1d54b7da4507cfe30a63f7e5e sedited: ACK f04b0c31627adda1d54b7da4507cfe30a63f7e5e
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
merge-commit duplicate discount
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#36253: fuzz: Use `LIMITED_WHILE` in `connect_block`
e0229ca6851572189ee99dc7093b58b01650d43b fuzz: Use LIMITED_WHILE in connect_block (marcofleon)
Pull request description:
Follow up to https://github.com/bitcoin/bitcoin/pull/35850 addressing https://github.com/bitcoin/bitcoin/pull/35850#discussion_r3872345750.
Replace the consume integral for loops in `connect_block` with `LIMITED_WHILE`. This is the preferred pattern for fuzz tests because it stops when the input runs out instead of repeating the loop body with default values.
ACKs for top commit: nervana21: tACK e0229ca6851572189ee99dc7093b58b01650d43b dergoegge: utACK e0229ca6851572189ee99dc7093b58b01650d43b
✓ 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
fuzzing or regression evidencemerge-commit duplicate discount
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.
While the kernel API provides access to a transactions's txid, it does not expose its wtxid. Clients therefore have to hash the transaction's witness serialization themselves, even though `CTransaction` already calculates and caches this value in `m_witness_hash`.
Expose the wtxid through a C API handle and corresponding C++ view and owning wrappers. Mirror the existing txid operations for copying, destruction, comparison and byte serialization.
Also expose `CTransaction::HasWitness()`, allowing clients to determine whether a transaction contains witness data without having to inspect each input themselves.
Tests cover legacy transactions, where txid and wtxid bytes match, and witness transactions, where they differ.
ACKs for top commit: stickies-v: re-ACK 43bba1ed74f8301fe1ec8e3751cdc93d07b89e82 sedited: ACK 43bba1ed74f8301fe1ec8e3751cdc93d07b89e82
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Looking at the coverage report for master on https://corecheck.dev, a number of error branches in `descriptor.cpp` are never exercised by any test. This PR adds `CheckUnparsable` vectors for each reachable one, plus one positive boundary check:
**musig()** - unterminated expression: `tr(musig(00)` → "Invalid musig() expression" - invalid participant key - trailing garbage after a participant key: `tr(musig(KEY}{))` → "musig(): expected ',', got '}'" (the `}` closes the level opened by the `(` of `musig(` and the `{` re-opens it, so the final `)` stays inside the expression span; thanks to @151henry151 for the counterexample showing this branch is reachable) - invalid derivation path element (the `musig(): `-prefixed wrapping of the keypath error; the underlying `ParseKeyPath` errors were already covered via `pkh()`/`wpkh()`) - participants with multipath derivations of mismatched lengths (`/<0;1>` vs `/<0;1;2>`; the `multi()` and Miniscript variants of this error were covered, the `musig()` one was not)
**Context restrictions** - `multi()` inside `tr()`, `multi_a()` at top level, and `addr()`/`tr()`/`rawtr()`/`raw()` inside `sh()`
**Taptree structure errors** - exceeding the 128 nesting level limit (129 `{`s, built with `std::string(129, '{')`) - missing `'}'` after a right branch, missing `','` after a left branch, trailing garbage after a script expression and after the internal key - a positive check that a taptree of exactly 128 nesting levels parses and expands successfully, so the limit is verified on both sides (suggested by @Herb-ops)
**rawtr()** - invalid key. `00` is used (rather than the truncated-valid-key pattern used elsewhere in this file) because in Taproot contexts a 32-byte string would parse as a valid x-only key.
Since `CheckUnparsable` asserts on the exact error message and each targeted branch produces a distinct one, a passing vector proves the corresponding branch executed.
Note that replaying the qa-assets `descriptor_parse`/`mocked_descriptor_parse` fuzz corpora already reaches these branches, so the value of these vectors is deterministic coverage in the unit tests with the exact error messages pinned.
ACKs for top commit: Herb-ops: ACK 0b3bb071036ac00649901b7a806e3882b61ddfde 151henry151: re-ACK 0b3bb071036ac00649901b7a806e3882b61ddfde ryanofsky: Code review ACK 0b3bb071036ac00649901b7a806e3882b61ddfde. Seems good to add these cases since there are no checks for these error messages. It also seems like it could be good to fix the inconsistent "tr: expected" message this exposed in a followup.
✓ 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
fuzzing or regression evidencemerge-commit duplicate discount
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#35961: depends: Update `boost` package to 1.92.0
94cb6594573876230840f0c8a563896c8700921b depends: Update `boost` package to 1.92.0 (Hennadii Stepanov)
Pull request description:
From the Boost.MultiIndex library [Release Notes](https://www.boost.org/doc/libs/latest/libs/multi_index/doc/release_notes.html#boost_1_92): > Fixed a performance issue with hashed indices when rehashing at very large container sizes.
ACKs for top commit: 151henry151: Tested ACK 94cb6594573876230840f0c8a563896c8700921b fanquake: ACK 94cb6594573876230840f0c8a563896c8700921b
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Merge bitcoin/bitcoin#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.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Lower-priorityMerge bitcoin/bitcoin#35849: init: don't suggest -reindex-chainstate for recovery on a pruned nodeby merge-script · a49fa1f6 · Sep 14, 2026 · 1 fileMessage 81 · StrongTriage 0Details
Commit message · merge-script
Merge bitcoin/bitcoin#35849: init: don't suggest -reindex-chainstate for recovery on a pruned node
adbff4d442864061171c693d6f57b51c9d8180c8 init: don't suggest -reindex-chainstate for recovery on a pruned node (Kyle 🐆)
Pull request description:
When chainstate loading fails, init offers to rebuild the databases and, if declined, suggests restarting with `-reindex` or `-reindex-chainstate`.
On a pruned node `-reindex-chainstate` cannot recover: it rebuilds the chainstate by replaying existing block data, which has been pruned, and the node already rejects it with "Prune mode is incompatible with -reindex-chainstate. Use full -reindex instead." Only a full `-reindex` recovers a pruned node.
Omit `-reindex-chainstate` from the suggestion when pruning is enabled.
ACKs for top commit: alexanderwiederin: ACK adbff4d442864061171c693d6f57b51c9d8180c8 sedited: ACK adbff4d442864061171c693d6f57b51c9d8180c8
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
merge-commit duplicate discount
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.
