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
Merge bitcoin/bitcoin#34681: wallet: move rescan logic into ChainScanner and wallet/scan
e67f75cf7d3e5a8f161d1525695c8653d225a01f wallet/scan: extract progress tracking helpers from `ChainScanner::Scan` (Novo) 062aa3ce56d72c03569743aa4142bcec2400bf8f wallet/scan: extract QueueNextBlock (Novo) 3655beb8f1531f780fffcbf2f1018d893b87e98e wallet/scan: extract block scanning logic to ScanBlock (Novo) 4535dc0c7885ad678074699627b363f382f29906 wallet/scan: extract block filter matching to ShouldFetchBlock (Novo) 72a37031d325e9f50bc95ef7496fc495b755962e wallet/scan: move WalletRescanReserver to scan files (Novo) 0274e80130af2cc58847b5d8f3628fa97a6f4b79 wallet/scan: move RescanFromTime to ChainScanner as ScanFromTime (Novo) db9185a44464b241dec7a20fdedd7142bc728b1e wallet: introduce ChainScanner as a CWallet member (Novo) 525163c2413ed595a6b9adbc682cc182339c0600 wallet/tests: pin rescan behavior (Novo)
Pull request description:
Part of https://github.com/bitcoin/bitcoin/pull/34400
This PR refactors the wallet rescan logic for improved readability and maintainability, and prepares the rescan logic for the changes in https://github.com/bitcoin/bitcoin/pull/34400.
CWallet previously owned all rescan-related concerns: atomic state variables, the WalletRescanReserver RAII type, RescanFromTime, and the entire block-scanning loop (ScanForWalletTransactions) as a single large member function.
This PR separates those concerns into a dedicated ChainScanner class, introduced in wallet/scan.h and wallet/scan.cpp:
- Scan state (fAbortRescan, fScanningWallet, progress, start time, passphrase flag) moves into ChainScanner atomics, exposed through Scanner(). - WalletRescanReserver - RescanFromTime becomes ChainScanner::ScanFromTime, keeping all scan entry points in one place. - ScanForWalletTransactions is replaced by ChainScanner::Scan and decomposed into focused helpers: ShouldFetchBlock, ScanBlock, ReadNextBlock, UpdateProgress, UpdateTipIfChanged, and ProcessBlock.
CWallet retains only a ChainScanner member and a Scanner() accessor. Callers that previously reached into CWallet for scan state now go through Scanner().
One slight behaviour change is introduced in this PR and is documented in the associated commit message. We previously attempted to read the block to scan before checking that it is active; now we check that it is active before the read attempt. It has no significant effect, but the change is documented.
This PR should be reviewed with the `--color-moved=dimmed-zebra` git option to aid review.
ACKs for top commit: achow101: ACK e67f75cf7d3e5a8f161d1525695c8653d225a01f polespinasa: re-ACK e67f75cf7d3e5a8f161d1525695c8653d225a01f pablomartin4btc: ACK e67f75cf7d3e5a8f161d1525695c8653d225a01f rkrux: lgtm ACK e67f75cf7d3e5a8f161d1525695c8653d225a01f
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
access controlsigning or wallet pathmerge-commit duplicate discount
AI analysis · Informational 19/100
This is a code cleanup change in Bitcoin Core's wallet. It moves the wallet's blockchain rescan logic out of the main CWallet class into a new dedicated ChainScanner class, without changing what the rescan does. The only intentional behavior change is the order of two internal checks: the code now verifies a block is still on the active chain before trying to read it, rather than after. The change is documented and tested, and appears to reduce risk rather than introduce it.
1bb5820b4411dfbc0ade5fada39d1a4af46dfa78 wallet: Add addhdkey interface (pseudoramdom) 82867073d6c3f3d160a7036ff3d7caa71c71651a wallet: Use WalletError for AddHDKey failures (pseudoramdom) f8769fc0b12459eedc1bd8e37001b7fccd12b33f wallet: Move addhdkey logic into CWallet (pseudoramdom) e1a2b25d6c3b1ed6d693d328d1aa5efaceb69c55 test: expand addhdkey coverage for locked wallet and bad key (Sjors Provoost)
Pull request description:
This PR adds a wallet interface for `addhdkey`.
The motivation is same as #34861 - while we have `addhdkey` RPC, Bitcoin Core GUI does not use the RPC interface. Having a dedicated wallet interface is helpful for GUI when performing multisig setup. When used in tandem with a similar interface for `derivehdkey` (#32784), the GUI can produce a shareable xpub during multisig setup.
Key changes: - Move the wallet logic from the `addhdkey` RPC into `CWallet::AddHDKey()`. - Update `addhdkey` RPC to call `CWallet::AddHDKey()` while keeping RPC-specific argument parsing - Introduce `WalletError`, a generic wallet-layer error type carrying a machine-readable `WalletErrorCode` and a translated user-facing message. - Update `addhdkey` RPC to use the above wallet helper. The RPC also exposes the master fingerprint in hex as `fingerprint` field. - Add `interfaces::Wallet::addHDKey()`, which generates and adds a new HD key and returns the master xpub. - Add unit test coverage for `interfaces::Wallet::addHDKey()`.
ACKs for top commit: davidgumberg: crreACK 1bb5820 achow101: ACK 1bb5820b4411dfbc0ade5fada39d1a4af46dfa78 polespinasa: ACK 1bb5820b4411dfbc0ade5fada39d1a4af46dfa78 w0xlt: ACK 1bb5820b4411dfbc0ade5fada39d1a4af46dfa78
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Informational 19/100
This commit refactors how Bitcoin Core wallets add new HD (hierarchical deterministic) keys. It moves the existing addhdkey logic from the RPC layer into a reusable CWallet method and exposes it through the wallet interface used by the GUI. The change is primarily a code-organization improvement to support future GUI multisig setup. It does not appear to introduce a security vulnerability; rather, it adds clearer error handling and tests for locked wallets and invalid keys.
Macros from the `bitcoin-build-info.h` header [may not be used](https://github.com/bitcoin/bitcoin/pull/36246#discussion_r4004364105) in `src/clientversion.cpp` depending on the `CLIENT_VERSION_IS_RELEASE` macro value.
Therefore, enforce IWYU to always keep the header.
ACKs for top commit: fanquake: ACK 1aa500b6b7d8a4dc1ff374f4a033799194bc5470
2c6047df8746a1d5333d17ad999dd32c40aba90e test: Bumping a transaction prevents bumping malleations (Ava Chow) a44f9ad35058f0aa45a1cada9460f89f650ab261 test: Test rbf metadata sync of malleated tx (Ava Chow) 752fd437c7cf79f8987c556a43990c23f9a48756 wallet: persist synced metadata and do not sync on load (furszy) 31eedfc6fc8b4dbf75b9aa2b66255732c19f478b wallet: simplify wtx metadata sync (furszy) 6c16d76f790c169a6cb032b60594228c9f7af878 wallet: sync tx replacement metadata to malleated txs (furszy) 34533d5d22b635eb7529a6e457a4a62069e27909 wallet: Clarify IsEquivalentTo is actually checking malleation (Ava Chow) b973a355c4ebd94cfa8cef61b68ac6da92fad787 Replace CTransaction::operator== with Equals that has options (Ava Chow) 2efaa6763bd210b367f4e67f67093156ef83da94 wallet: simplify and restrict SyncMetaData to malleated txs (furszy) fc718ade4fce8003a9460e7f79a4b2a21a4dc702 test: Test that metadata is synced to malleated transactions (Ava Chow)
Pull request description:
`SyncMetaData` is intended to handle the case of malleated transactions by copying the metadata from a presumed original transaction to all of the malleations of that transaction. However, it did not do this correctly, leading to both a crash that can be reached during `bumpfee`, and failing to actually copy the metadata to some malleated transactions.
The crash was reachable by having both the original transaction and a malleation of it in the wallet, then calling `bumpfee` on the original, and then calling `bumpfee` on the malleation. Calling `bumpfee` on the malleation would result in an assertion failure in `MarkReplaced`, hitting `Assert(!wtx.m_replaced_by_txid);`. This is reached since adding the RBF to the wallet causes a metadata sync between the original and the malleation, which copies `m_replaced_by_txid`. `MarkReplaced` is called soon afterwards, resulting in the crash. This is fixed by syncing the metadata after `MarkReplaced` sets `replaced_by_txid` during the RBF of the original transaction so that `bumpfee` refuses to bump the malleation in the first place as it will check `m_replaced_by_txid` before bumping.
The other issue is that if a RBF transaction is malleated, `SyncMetaData` was not copying the metadata from the original RBF transaction to the malleation.
These are fixed by changing `SyncMetaData` to find all of the malleations of a transaction rather than all of the conflicts and simplifying how it is called. Additionally, `CWalletTx::IsEquivalentTo` is used by `SyncMetaData` to determine whether a transaction is a malleation, and this PR pulls in https://github.com/bitcoin/bitcoin/pull/32723#issuecomment-3028112892 to make it explicitly clear which fields it is actually checking to determine the equivalence. Lastly, `SyncMetaData` is renamed to `SyncMalleatedTxMetadata` and `IsEquivalntTo` renamed to `IsMalleation` to clarify that these functions are for handling malleated txs.
The last 2 commits of this PR adds tests for these cases, and the first commit a test for basic `SyncMalleatedTxMetadata` functionality that should not change here.
ACKs for top commit: furszy: utACK 2c6047df8746a1d5333d17ad999dd32c40aba90e sedited: utACK 2c6047df8746a1d5333d17ad999dd32c40aba90e
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
access controlsigning or wallet pathmerge-commit duplicate discount
AI analysis · Moderate 60/100
This update fixes a bug in Bitcoin Core's wallet that could crash the program when a user tried to speed up (bump) a transaction that had a slightly altered copy (a 'malleated' version) in the wallet. It also ensures that notes, replacement links, and other metadata are correctly copied between the original transaction and its malleated copies. The crash was a denial-of-service-style failure for the wallet process, not a way to steal coins, and it required the user to already have both the original and malleated transactions in their wallet.
1cbbf64ea81085109bd9cc594a0e1cf1cf943596 ci, iwyu: generate embedded ASMap header explicitly (Kanan) 1afa0cd70a09258b0470d690a7720b050f3ba54f cmake: add raw data header generation target (Kanan)
Pull request description:
Fixes the remaining `ip_asn.dat.h` errors reported in #35361.
The IWYU job currently reads compile commands for files such as `src/init.cpp` before the embedded ASMap header has been generated, which results in `fatal error: 'node/data/ip_asn.dat.h' file not found` messages in the CI logs.
This adds a dedicated raw-data header generation target and makes the IWYU job build `bitcoin_node_raw_data_headers` before running the checks. This keeps the change limited to build/CI behavior and avoids building the full `bitcoin_node` target just to generate the header.
ACKs for top commit: hebasto: ACK 1cbbf64ea81085109bd9cc594a0e1cf1cf943596.
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.
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.
Fixes #32486, supersedes #33592 (this is a condensed version)
Additionally this PR modifies `03_test_script.sh` to avoid modifying `GOAL` in place. That was causing the `codesign --verify` step to get skipped entirely.
ACKs for top commit: fanquake: ACK da7d7dbc7c0040d5e91fe21e19fdc1cb3b8ea7b2 - I think we should try and cleanup `macdeployqtplus` somewhat, but that can happen in future. willcl-ark: Light ACK da7d7dbc7c0040d5e91fe21e19fdc1cb3b8ea7b2
✓ 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 boundarymerge-commit duplicate discount
AI analysis · Low 35/100
This change fixes how Bitcoin Core's macOS app bundle is digitally signed during automated builds. It replaces an outdated 'deep' signing method with explicit signing of each framework, plugin, and the main app bundle. It also fixes a CI script bug that was accidentally skipping the signature verification step entirely, and makes that verification stricter. The practical security effect is that macOS is more likely to detect tampered or improperly signed release binaries, and the build pipeline now actually performs that check.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
seed or entropy pathsigning or wallet pathmerge-commit duplicate discount
AI analysis · Informational 22/100
This is a routine Bitcoin Core release-maintenance commit. It refreshes the list of network seed nodes, updates the built-in checkpoints that tell the software how much blockchain history to trust by default, adds newer 'assumeutxo' snapshots for faster initial setup, and adjusts header-sync tuning parameters. None of these changes fix a known bug or vulnerability; they are standard pre-release housekeeping to keep the client in sync with the live network.
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.
The GUI and non-GUI Guix profiles produce different depends build IDs. However, depends deletes the existing per-package cache directory when storing a new build. Sharing a cache root therefore causes each profile to evict the other's packages, forcing rebuilds on subsequent runs.
This PR keeps these packages in separate `GUIX/BUILD` and `GUIX/GUI` directories under the cache root. This also keeps them separate from ordinary developer builds when BASE_CACHE is being used there.
#35929 replaces `GUIX_ENVIRONMENT` in package ID generation with a hash of selected Guix inputs. Its current implementation covers the manifests, patches, pinned Guix revision and additional flags, but that list needs to stay aligned with how we construct the environment and may therefore be brittle to future changes.
In this version I prefer keeping the resolved environment in the cache key and simply keeping the caches separate.
#### Tradeoffs vs #35929
This PR means building and storing some dependencies twice, which I consider a reasonable cost for simpler cache tracking/invalidation. This is likely going to be the case for Linux anyway i.e after a change like #36193 or #25573.
ACKs for top commit: achow101: ACK 1fe87c25054760dc53636d7e0cec8556c6c51e34 hebasto: ACK 1fe87c25054760dc53636d7e0cec8556c6c51e34, tested on Ubuntu 26.04 by doing several consecutive Guix builds interleaved with branch switches and observing the cache behavior. sedited: ACK 1fe87c25054760dc53636d7e0cec8556c6c51e34
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
merge-commit duplicate discount
Lower-priorityMerge bitcoin/bitcoin#36150: indexes: set prune lock to genesis before first blockby merge-script · a6b33097 · Sep 11, 2026 · 2 filesMessage 91 · StrongTriage 0Details
Commit message · merge-script
Merge bitcoin/bitcoin#36150: indexes: set prune lock to genesis before first block
9b2299514028f5055d4314e402776cbb45c5f538 indexes: set prune lock to genesis before first block (Andrew Toth) 0ae3b40c274a37a870f91a27ed6b2e70dda4ea29 test: characterize startup with newly added prune and index (Andrew Toth)
Pull request description:
When setting both a new index and prune size and restarting an unpruned node, the node will prune the block store first and then the index will fail to start syncing.
Fix this by setting the prune lock to 0 if the index does not yet have a best block.
ACKs for top commit: sedited: Re-ACK 9b2299514028f5055d4314e402776cbb45c5f538 fjahr: Code review ACK 9b2299514028f5055d4314e402776cbb45c5f538
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
merge-commit duplicate discount
Lower-priorityMerge bitcoin/bitcoin#36215: asmap: Make version match externally computed hashesby merge-script · fc6923ce · Sep 10, 2026 · 3 filesMessage 81 · StrongTriage 0Details
Commit message · merge-script
Merge bitcoin/bitcoin#36215: asmap: Make version match externally computed hashes
7ee94bf4b02376af8b2cfc78ea954ca340fab8c5 asmap: Make outputted ASMap version match externally computed hashes (Hodlinator)
Pull request description:
#### Problem
Running CLI utilities such as `sha256sum` on the encoded asmap blob, and then grepping for the outputted hash in the `bitcoind` debug.log was unsuccessful.
#### Solution
* Change the version computation from double to single SHA256 *Note: This invalidates serialized AddrMan data which forces re-bucketing.* * Avoid reversing byte order when logging the version
Inspired by https://github.com/bitcoin/bitcoin/pull/36201#issuecomment-5605080265 + https://github.com/bitcoin/bitcoin/pull/36201#pullrequestreview-5158109401
ACKs for top commit: fjahr: tACK 7ee94bf4b02376af8b2cfc78ea954ca340fab8c5 jurraca: ACK https://github.com/bitcoin/bitcoin/pull/36215/commits/7ee94bf4b02376af8b2cfc78ea954ca340fab8c5 sedited: ACK 7ee94bf4b02376af8b2cfc78ea954ca340fab8c5
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.
Merge bitcoin/bitcoin#36174: http: throttle send buffer when client stops draining
28b69e298884ed3f0b03023d9ad1cf37d15bcec6 http: stop processing requests from a client when send buffer is full (Matthew Zipkin)
Pull request description:
This is a follow-up to #36123 and applies a second throttle mechanism to the send-side. If a misbehaving client refuses to read data from the socket, the server will now stop processing requests instead of packing more and more responses to `m_send_buffer` without bound.
After we parse a complete request from a client, **before** we dispatch it to a worker, we quickly lock and check the size of `m_send_buffer`. If there's already 32MiB of data there (reusing `MAX_BODY_SIZE` here, open for bikeshedding...) we do not dispatch the request to a worker, leaving it in place as `m_req`.
This was found and disclosed responsibly by the Red Team 🟥.
ACKs for top commit: hodlinator: ACK 28b69e298884ed3f0b03023d9ad1cf37d15bcec6 janb84: re ACK 28b69e298884ed3f0b03023d9ad1cf37d15bcec6 sedited: ACK 28b69e298884ed3f0b03023d9ad1cf37d15bcec6
Merge bitcoin/bitcoin#36195: test: `get_previous_releases.py` use `PREVIOUS_RELEASES_DIR`
ecdf9db906b4d09e780371fd6e7fe420ecdc87f9 test: get_previous_releases.py use `PREVIOUS_RELEASES_DIR` (David Gumberg)
Pull request description:
`test_framework.py` already uses `PREVIOUS_RELEASES_DIR` to set a default directory to find previous releases, so should `get_previous_releases.py` when fetching them.
This is more convenient for local development when using multiple worktrees where having `$PREVIOUS_RELEASES_DIR` set is useful.
Also allows some CI code to get deleted.
_LLM Usage Disclosure: Qwen3.8-0.5B generated the next 800,000 pages of my epistolary novel while I made this PR._
ACKs for top commit: hodlinator: ACK ecdf9db906b4d09e780371fd6e7fe420ecdc87f9 willcl-ark: ACK ecdf9db906b4d09e780371fd6e7fe420ecdc87f9
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Notice that the refspec in `doc/productivity.md` maps to `upstream-pull/NUMBER`, but the doc mentions `upstream-pull/NUMBER/head` right below it. Dropping the trailing `/head` so the `git show` / `git chekcout` examples actually match up. Tested both locally in a scratch repo and they work fine now.
ACKs for top commit: sedited: ACK b3a9b84b37c0c30f4411ad1e09d8f89e9aaa7434
✓ 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#36201: Update embedded asmap to 1788801420
3c91db262b74f001a30bc5834daf322eadc19c46 net: Update embedded asmap to 1788801420 (Fabian Jahr)
Pull request description:
Depends on #36199 and https://github.com/bitcoin-core/asmap-data/pull/70 getting merged and receiving enough attestations. The run just happened so I hope we'll get these ACKs before the end of the week.
ACKs for top commit: hodlinator: ACK 3c91db262b74f001a30bc5834daf322eadc19c46
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
update trustmerge-commit duplicate discount
AI analysis · Informational 15/100
This commit simply swaps in a newer version of an external routing data file (the 'asmap') that Bitcoin Core embeds to help peers connect across different internet networks. The change is a routine data refresh with no code modifications, no bug fixes, and no security-related behavior changes visible in the commit.
