Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.
Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
This commit adds the first implementation of BIP352 (Silent Payments) to Bitcoin Core. Silent Payments are a new type of privacy-preserving Bitcoin address that lets someone receive payments without publicly revealing a fixed address. The …
New cryptographic feature implementation (BIP352 Silent Payments)Extensive use of secp256k1 silentpayments moduleInput public key extraction from P2PKH, P2WPKH, P2SH-P2WPKH, and P2TR inputs
This update fixes a wallet database loading bug where a damaged or tampered Bitcoin wallet file could cause the program to read past the end of a stored extended public key (xpub). The patch makes the loader check the stored xpub length be…
Out-of-bounds read in wallet descriptor cache deserializationASan container-overflow triggered by malformed on-disk recordMissing length validation between record size prefix and fixed-size decoder
This commit adds a new wallet RPC called listrawtransactions to Bitcoin Core. It is a feature addition that lets users list every transaction their wallet knows about, including internal transfers and consolidations that the existing listt…
No security-relevant bug fix or vulnerability patch is present in the diff.New RPC exposes additional wallet transaction metadata, but only to callers already authorized for wallet RPCs.Code is a refactor of existing gettransaction logic into shared helpers; no new cryptographic, network, or consensus code.
This Bitcoin Core update fixes several wallet bugs where a failed database write could leave a wallet in an inconsistent state. For example, encrypting a wallet or changing its passphrase could appear to succeed in memory while the change …
Atomicity fix for encryption state and descriptor key persistenceFailure to persist master key during encryption previously reported success in memoryPassphrase change could activate new passphrase only in memory
This commit only changes Bitcoin Core's internal functional test code. It replaces hard-coded test keys and addresses with ones generated from a new test helper class, and unifies how tests tell nodes not to create a default wallet. There …
This commit only adds a new automated test to Bitcoin Core. It checks that when two partially-signed Bitcoin transactions (PSBTs) are combined, any custom 'unknown' data fields attached to them are preserved correctly. There is no change t…
This is a Bitcoin Core wallet maintenance patch. It speeds up a wallet function that checks whether a descriptor already exists by caching a hash of the descriptor's canonical text, instead of rebuilding that text every time. It also tidie…
No security-relevant signal in commit message or diffChange is described as performance improvement and code cleanupBackwards-compatibility test notes a known miniscript wallet loading incompatibility between v31.0/v31.1 and other versions, but this is a documented compatibility quirk, not a vulnerability
This is a documentation-only fix for Bitcoin Core's machine-readable RPC help data. It changes several default values from literal strings to 'hint' labels (because the real default depends on context) and corrects one boolean default from…
OpenRPC schema/default mismatch correctionRPC help metadata type correction (string 'false' to boolean false)No executable code path changes
This commit fixes documentation metadata for six Bitcoin Core RPC arguments. It changes how default values are described so that automatically generated API docs and schemas are accurate. The actual behavior of the software when running is…
No runtime code changesOnly RPC help/schema metadata modifiedVendor explicitly states runtime behavior is unchanged
This commit fixes a bug in Bitcoin Core's MuHash3072 cryptographic code where dividing a MuHash object by itself (x /= x) produced the wrong mathematical result. The fix is straightforward: the code now saves the divisor's numerator before…
Cryptographic correctness bug in MuHash3072 division operatorSelf-aliasing in operator/= produces incorrect 1/D result instead of empty setNo production code path identified that triggers self-division
This is a build-compatibility fix, not a security patch. It changes how some constant data is stored internally so that Apple's macOS linker (ld64) can build Bitcoin Core correctly. The change avoids a linker bug that caused build failures…
No security-relevant code logic changedChange is a linker bug workaround, not a vulnerability fixConstants remain read-only; no new attack surface introduced
This commit refactors Bitcoin Core's wallet descriptor import feature so the same logic can be used by both the RPC command and a new GUI-facing interface. It also tightens one input rule: negative timestamps are now rejected, and the mini…
Refactor of security-sensitive wallet import code into shared CWallet pathNew input validation: negative timestamps rejected for importdescriptorsCentralization of descriptor range bound checks in CheckDescriptorRangeBounds
This change fixes a bug in how Bitcoin Core reconnects to the Tor control port. A previous update accidentally removed the wait time between reconnect attempts when an already-established Tor control connection was dropped. Without the wai…
Uncontrolled retry loop causing resource exhaustion and log floodingLocal-only Tor control port interaction; no remote attacker path by defaultRegression introduced by prior refactor (#34158) and restored here
This change updates the Windows code-signing tool used in Bitcoin Core's reproducible build process. It fixes a build-time failure where signature verification could not complete because a certificate package was missing and the old tool v…
Tooling update in release signing pipelineRestores CA certificate store for signature verificationDisables CRL/CDP network lookups during verification
This change lets Bitcoin Core store different custom signet blockchains in separate data folders, using a unique suffix derived from each signet's network identifier. It also adds a friendlier error hint in bitcoin-cli when an RPC authenti…
Data isolation between distinct custom signets reduces risk of cross-network state corruption or accidental mainnet/testnet confusionNo memory-safety, cryptographic, or consensus changes observedNo privilege escalation, remote code execution, or denial-of-service vectors introduced in the diff
This change adds two extra pieces of information—whether a spent output came from a coinbase transaction and the block height at which it was created—to a Bitcoin Core REST API endpoint. It is a feature/parity improvement to make the REST …
This change makes Bitcoin Core treat manually-added peers (from -addnode, -connect, or the addnode RPC) more gently during Initial Block Download (IBD). Previously, if such a peer was slow or stalled at sending blocks, the node would disco…
Behavior change in peer disconnection logic during IBDManual peers exempted from block-stalling disconnectionNew per-peer cooldown state m_block_download_paused_until introduced
This is a small fix in Bitcoin Core's own test helper code. A helper function used only in tests could crash with an IndexError when given an extremely short fake signature, instead of cleanly returning False. The change moves a length che…
Out-of-order bounds check leading to IndexError in test helperRegression test added for malformed short DER signaturesTest-only code path, no production validation logic changed
This commit only adds a new functional test to Bitcoin Core. It checks that the getrawtransaction RPC can retrieve a stale block's coinbase transaction via the optional txindex, and that the response correctly shows the block is no longer …
This commit only adds a new automated test to Bitcoin Core. It does not change any production wallet, mempool, or node code. The test verifies that when a user tries to bump the fee of a transaction whose unconfirmed inputs depend on too m…
Adds regression test for previously fixed crash path (bad optional_access in CheckFeeRate)No production code changes; no new attack surface introducedTest exercises DoS-limit error handling in fee bumping
e3ee0ebd89e9955da94c8d806cfa1793baba9860 tests: add BIP352 test vectors as unit tests (josibake) f133d1373af6f58488f73fe3dc795d37c4796dd9 common: add bip352.{h,cpp} secp256k1 module (josibake) 44997c391afc1f3ae75d2331606e1261fd365801 Add "sp" HRP (josibake) 356c91f6ae51bd9e48db0920110ac9303f54f714 crypto: add KeyPair::GetSecpKeypair (josibake)
Pull request description:
This PR is part of integrating silent payments into Bitcoin Core. It is the second iteration of https://github.com/bitcoin/bitcoin/pull/28122, now based on https://github.com/bitcoin-core/secp256k1/pull/1765.
This project is tracked in https://github.com/bitcoin/bitcoin/issues/28536.
BIP352 This PR focuses strictly on the BIP logic and attempts to separate it from the wallet and transaction implementation details. This is accomplished by working directly with public and private keys, instead of needing a wallet backend and transactions for testing. Labels for the receiver are optional and thus deferred for a later PR.
Test vectors from the BIP are included as unit tests.
ACKs for top commit: rustaceanrob: reACK e3ee0ebd89e9955da94c8d806cfa1793baba9860 theStack: re-ACK e3ee0ebd89e9955da94c8d806cfa1793baba9860 achow101: ACK e3ee0ebd89e9955da94c8d806cfa1793baba9860
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
secret or key materialfuzzing or regression evidencemerge-commit duplicate discount
AI analysis · Informational 12/100
This commit adds the first implementation of BIP352 (Silent Payments) to Bitcoin Core. Silent Payments are a new type of privacy-preserving Bitcoin address that lets someone receive payments without publicly revealing a fixed address. The change introduces new code for encoding/decoding silent payment addresses, deriving output public keys, and scanning transactions for outputs belonging to the recipient. It is a feature addition, not a fix for a known security bug. There is no evidence in the commit or supplied references that this introduces a vulnerability or that any security incident occurred.
Merge bitcoin/bitcoin#35440: wallet: check descriptor cache xpub length before decoding
db7ec4fb976284581ba2adc77218af8711375d91 refactor: (de)serialize CExtKey/CExtPubKey through streams (Alhuda Khan) cb69853fc160d8a02c21510b8251b05913665672 wallet: check descriptor cache xpub length before decoding (alhudz)
Pull request description:
The descriptor cache records (`WALLETDESCRIPTORCACHE`/`WALLETDESCRIPTORLHCACHE`) deserialise their value into a vector whose length comes from the record itself, but `CExtPubKey::Decode` then reads a fixed `BIP32_EXTKEY_SIZE` bytes. A record encoding a shorter xpub makes `Decode` read past the vector (caught as a container-overflow under ASan).
The first commit rejects records whose serialised xpub isn't exactly `BIP32_EXTKEY_SIZE`, the same way the other malformed records in this loader return `DBErrors::CORRUPT`, with a unit test covering both cache types.
The second commit (per https://github.com/bitcoin/bitcoin/pull/35440#issuecomment-5050992564) replaces `CExtKey`/`CExtPubKey` `Encode`/`Decode` and `EncodeWithVersion`/`DecodeWithVersion`, the only (de)serialisation in the codebase that wrote into a caller-provided buffer, with `Serialize`/`Unserialize`, and routes the base58, PSBT and wallet cache code through them. The serialised bytes are unchanged, so base58 and PSBT encodings and the on-disk cache records are the same as before. The wallet loader now checks the record's CompactSize prefix and reads the xpub straight from the record stream.
ACKs for top commit: molnard: tACK db7ec4fb976284581ba2adc77218af8711375d91 achow101: ACK db7ec4fb976284581ba2adc77218af8711375d91 winterrdog: tACK db7ec4fb976284581ba2adc77218af8711375d91
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
secret or key materialsigning boundarymemory safetycryptography-sensitive pathsigning or wallet pathmerge-commit duplicate discount
AI analysis · Low 45/100
This update fixes a wallet database loading bug where a damaged or tampered Bitcoin wallet file could cause the program to read past the end of a stored extended public key (xpub). The patch makes the loader check the stored xpub length before decoding it, and also replaces the old fixed-size buffer encoding with safer stream-based serialization used throughout the rest of the code. It is primarily a hardening fix against corrupt wallet data rather than a remote attack vector.
7c311f5c6c3ea5a0d0cc4da35177e6977cda87d1 doc: Add release notes for listrawtransactions (pablomartin4btc) b377786df14e4098cc2af2fa3a108b3371df9471 test: Add functional test for listrawtransactions (pablomartin4btc) 605c4fd3aee0cea04aef583e7ceeca2dd9a17718 wallet, rpc: Add listrawtransactions RPC (pablomartin4btc) ba6c179ba07cafb3f7e8a0baf9c9a73992b36695 wallet, rpc: allow omitting parent_descs from TransactionDescriptionString (pablomartin4btc) dc3e2bc6df6814f6b9b5ce1d5b24933e3f10ca8a wallet, rpc: extract PushTxAmountAndFee/PushTxDecoded helpers (pablomartin4btc)
Pull request description:
Add a new `listrawtransactions` RPC that returns wallet transactions without logical interpretation. Unlike `listtransactions`, which only lists transactions with an economic category (sends to external addresses, receives from outside), this RPC returns every transaction the wallet knows about — including consolidations and self-transfers that would otherwise be invisible.
Each transaction appears exactly once with its net wallet balance change (`amount`) and, when the wallet funded the transaction, the fee paid (`fee`). Pagination is supported via `count` and `skip` parameters, matching the interface of `listtransactions`.
Next possible follow-ups: - A filter parameter (`"all"` / `"received"` / `"sent"` / `"self"`) once per-tx semantics are agreed on - Some fields inherited from `TransactionDescriptionString()` carry references to `category` (e.g. `replaced_by_txid`, `parent_descs`) which don't apply here — could be cleaned up in a separate pass
Closes #34632.
Previous attempt: #35009 (by alfonsoromanz), closed in favour of a separate RPC as suggested by achow101.
ACKs for top commit: Bicaru20: reACK 7c311f5c6c achow101: ACK 7c311f5c6c3ea5a0d0cc4da35177e6977cda87d1 polespinasa: ACK 7c311f5c6c3ea5a0d0cc4da35177e6977cda87d1
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
access controlsigning or wallet pathmerge-commit duplicate discount
AI analysis · Informational 20/100
This commit adds a new wallet RPC called listrawtransactions to Bitcoin Core. It is a feature addition that lets users list every transaction their wallet knows about, including internal transfers and consolidations that the existing listtransactions RPC hides. The change is mostly a refactor of existing code into shared helpers plus a new RPC endpoint. There is no direct evidence in the commit of a security vulnerability, bug fix, or exploit.
Security candidateMerge bitcoin/bitcoin#35752: wallet: make encryption state updates atomicby Ava Chow · 7ee3d622 · Sep 22, 2026 · 18 filesMessage 91 · StrongModerate 68Details
Commit message · Ava Chow
Merge bitcoin/bitcoin#35752: wallet: make encryption state updates atomic
**Problem:** Wallet encryption and passphrase changes can leave database records and live key state out of sync when a database operation fails. Encryption can report success without persisting the master key, and a passphrase change can activate the new passphrase only in memory. Descriptor key write failures can publish keys that were not persisted, while erase failures can leave plaintext keys on disk. A failed encryption transaction commit aborts the node, and a re-encryption failure during a passphrase change can leave a previously locked wallet unlocked. Boolean results also force callers to duplicate error messages or report database and encryption failures as incorrect passphrases.
**Fix:** Publish wallet encryption state only after the database transaction commits, and publish newly inserted descriptor keys only after their database writes succeed. For passphrase changes, restore the original lock state after validating the old passphrase and replace the live master key only after persisting its re-encrypted value. These changes preserve the affected keys on failure and allow retries. Return structured errors from wallet unlock and passphrase changes so callers can share messages and report the specific failure. Fresh descriptor setup after the encryption transaction remains unchanged.
ACKs for top commit: achow101: ACK 6d2414542b86ff7d6eae0f4c873e47bc4e57a57c w0xlt: reACK 6d2414542b86ff7d6eae0f4c873e47bc4e57a57c
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
access controlsigning or wallet pathauthentication pathmerge-commit duplicate discount
AI analysis · Moderate 68/100
This Bitcoin Core update fixes several wallet bugs where a failed database write could leave a wallet in an inconsistent state. For example, encrypting a wallet or changing its passphrase could appear to succeed in memory while the change was not actually saved to disk, or could leave unencrypted private keys behind. The patch makes these operations atomic: in-memory state is only updated after the database transaction commits, and failures now return clear, structured error messages instead of crashing the program or giving misleading 'wrong passphrase' errors.
Merge bitcoin/bitcoin#36261: test: cover PSBT unknown field merging
21e4ea8134d8ca95416e065490d99f82be66bd67 test: cover PSBT unknown field merging (w0xlt)
Pull request description:
Continuing the work from #35310 gere in agreement with w0xlt
This PR adds functional coverage for combinepsbt preserving unknown PSBT fields across global, input, and output maps, as suggested [here](https://github.com/bitcoin/bitcoin/pull/34893#issuecomment-4390043746).
The test covers both PSBTv0 and PSBTv2 by creating valid base PSBTs with `createpsbt`, injecting unknown key-value pairs into two copies, combining them, and asserting that all unknown fields are retained in the decoded result.
ACKs for top commit: polespinasa: ACK 21e4ea8134d8ca95416e065490d99f82be66bd67 nebula-21: ACK 21e4ea8134d8ca95416e065490d99f82be66bd67 winterrdog: tACK 21e4ea8134d8ca95416e065490d99f82be66bd67 w0xlt: ACK 21e4ea8134d8ca95416e065490d99f82be66bd67
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundarysigning or wallet pathmerge-commit duplicate discount
AI analysis · Informational 15/100
This commit only adds a new automated test to Bitcoin Core. It checks that when two partially-signed Bitcoin transactions (PSBTs) are combined, any custom 'unknown' data fields attached to them are preserved correctly. There is no change to the actual Bitcoin Core software behavior—only test code was added.
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#36256: guix: Update osslsigncode to 2.14
59a465ce37829b2305319b378e8e85c9e653f29a guix: Validate codesigned windows binaries (Ava Chow) 66eeac216ad5b5b8d42a727aa730d7fc603f55fe guix: Use osslsigncode 2.14 (Ava Chow)
Pull request description:
#34550 mistakenly removed the package `nss-certs`. This results in an error during codesigining: `Use the "-CAfile" option to add one or more trusted CA certificates to verify the signature.`
However, introducing the package is not enough to make codesigning work. #34550 switched us to using osslsigncode 2.13 from upstream, but osslsigncode versions 2.6 through 2.13 all require network access as they validate CRLs. While the `verify` command has the ability to skip CRL validation, `attach-signature` does not.
osslsigncode 2.14 resolves both issues for us by removing signature validation, instead it only checks that the hash in the signature matches the hash of the binary. But we still want to do a belt-and-suspenders signature validation, and we can achieve this by calling `verify` afterwards with CRL validation disabled to avoid the network access issue, along with including the `nss-certs` package.
Lastly, guix upstream already has 2.14, so we could get it by bumping the time-machine commit. But it seems like bumping that is problematic for other packages, see #36233 and #35855. Instead, this PR copies in the package definition from upstream.
ACKs for top commit: Sjors: re-utACK 59a465ce37829b2305319b378e8e85c9e653f29a hebasto: re-ACK 59a465ce37829b2305319b378e8e85c9e653f29a, tested the signed installer on Windows:
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarydefensive validationsigning or wallet pathmerge-commit duplicate discount
AI analysis · Informational 18/100
This change updates the Windows code-signing tool used in Bitcoin Core's reproducible build process. It fixes a build-time failure where signature verification could not complete because a certificate package was missing and the old tool version required internet access. The patch adds the missing certificates package, upgrades the signing tool to version 2.14, and changes the verification step so it no longer needs network access. This is a build-infrastructure reliability fix, not a vulnerability in the Bitcoin software users run.
Security candidateMerge bitcoin/bitcoin#34566: feature: Use different datadirs for different signetsby merge-script · d32a515f · Sep 16, 2026 · 12 filesMessage 96 · StrongInformational 19Details
Commit message · merge-script
Merge bitcoin/bitcoin#34566: feature: Use different datadirs for different signets
feeb00af8cf361ba9d2f7de0334abf875b3103d9 cli: Add -signetchallenge info on RPC auth error (ekzyis) c47ea370dc9f7a878e8269884b25204b8e6a3ec6 doc: Update documentation for signet datadir (ekzyis) 6f8c43f9efc601b26ae221e53bb3c354ea64b618 test: Add signet datadir tests (ekzyis) 9b37d42b23be096cc4cfb457f1022e443102b650 Use different datadirs for different signets (ekzyis) 6bdcae3f768b9e8da958ecbf46fa88b42df338f5 refactor: Import signet constant and helper from kernel/signet.h (ekzyis)
Pull request description:
closes #27494
This adds support for syncing multiple signets.
Each custom signet is stored in a different datadir, using the network magic (message start) as the suffix.
The default signet is always stored without a suffix for backward compatibility, even if the default challenge is provided explicitly via `-signetchallenge`.
This builds upon #29838.
For those already familiar with #29838, here are the differences between #29838 and this that are visible to the user:
* The suffix does not use the first 4 bytes of hash160(challenge), but rather the network magic (message start) as mentioned in [#29838 (comment)](https://github.com/bitcoin/bitcoin/pull/29838#discussion_r1557976175) and [#34566 (comment)](https://github.com/bitcoin/bitcoin/pull/34566#issuecomment-4207665792). * If the default challenge is provided to `-signetchallenge`, [#29838](https://github.com/bitcoin/bitcoin/pull/29838) added a suffix to the datadir, whereas this PR does not. This includes backward compatibility when the default signet is used explicitly, not only implicitly, even though [the default signet consensus parameters aren't used in the explicit case](https://github.com/bitcoin/bitcoin/pull/29838#issuecomment-2742830552).[^1] A test was added for this case.
[^1]: could be something for a follow-up PR, or maybe it's intentional to not mix explicit with implicit options?
Unlike #29838, this PR does not update tests that didn't break (`rpc_bind.py`, `interface_bitcoin_cli.py`). I have found other tests where `datadir_path` is used in combination with `self.chain` (regexp: `datadir_path.*chain`). I considered it inconsistent to update some tests but not all of them. I've decided to not update all of them to keep the scope of this PR low until feedback. I can go through all tests in a follow-up PR to make sure they don't break when they are ever used with (custom) signet, however unlikely that might be.
I have done some manual testing like this:
<details> <summary>manual testing</summary>
1. 'signet' directory is used, IBD:
``` $ bitcoind -signet ```
2. 'signet' directory is used, no IBD without `-addnode` (see [#29838 (comment)](https://github.com/bitcoin/bitcoin/pull/29838#issuecomment-2742830552)) or existing peers.dat:
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
consensus or confidential-proof validationsigning or wallet pathmerge-commit duplicate discount
AI analysis · Informational 19/100
This change lets Bitcoin Core store different custom signet blockchains in separate data folders, using a unique suffix derived from each signet's network identifier. It also adds a friendlier error hint in bitcoin-cli when an RPC authentication failure might be due to using the wrong custom signet. There is no direct security vulnerability being fixed; it is a usability and data-isolation feature.
Merge bitcoin/bitcoin#36251: rest: add `generated` and `height` to spenttxouts JSON
1566a4767afd3865ee466d1aa2ce8237cb5c27c1 rest: add generated and height to spenttxouts JSON (0xb10c)
Pull request description:
This adds the `generated` and `height` fields to the JSON REST endpoint `/rest/spenttxouts/BLOCKHASH.json` to match the prevout output of the getblock RPC with verbosity 3. The information for these fields is already available, but just was not exposed.
The binary and hex formats aren't changed (here) to not break backwards compatibility with consumers of these endpoints. See the discussion in https://github.com/bitcoin/bitcoin/pull/32540#issuecomment-5665279713
ACKs for top commit: nervana21: tACK 1566a4767afd3865ee466d1aa2ce8237cb5c27c1 willcl-ark: ACK 1566a4767afd3865ee466d1aa2ce8237cb5c27c1 sedited: ACK 1566a4767afd3865ee466d1aa2ce8237cb5c27c1
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
access controlmerge-commit duplicate discount
AI analysis · Informational 19/100
This change adds two extra pieces of information—whether a spent output came from a coinbase transaction and the block height at which it was created—to a Bitcoin Core REST API endpoint. It is a feature/parity improvement to make the REST output match an existing RPC output. There is no indication it fixes a security bug or introduces a vulnerability.
Manual peers added via `-addnode`, `-connect`, or the `addnode` RPC represent explicit operator intent to keep those connections around.
During IBD, a manual peer can currently be disconnected if it triggers block-stalling logic. This can be surprising in `-connect` or `-addnode`-based setups, where the operator may prefer (and probably expect) to keep the peer connected even if it is not a useful block download peer at that moment.
This PR changes only the block-stalling path. Instead of disconnecting a stalling manual peer, it releases that peer's in-flight block requests so other peers can request them and IBD can continue.
After releasing the requests, the manual peer is temporarily skipped for block downloads. This avoids immediately assigning scarce IBD block download slots back to the peer that just stalled, while still allowing the peer to become eligible again after the cooldown.
This intentionally does not change block download timeout or headers sync timeout behavior.
ACKs for top commit: sedited: Re-ACK 5551d39b202bf0386fb40589817cd92f8afdaf59
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundarymerge-commit duplicate discount
AI analysis · Low 33/100
This change makes Bitcoin Core treat manually-added peers (from -addnode, -connect, or the addnode RPC) more gently during Initial Block Download (IBD). Previously, if such a peer was slow or stalled at sending blocks, the node would disconnect it. Now it releases the pending block requests to other peers so IBD can continue, pauses asking that peer for blocks for two minutes, and keeps the connection open. This matches operator intent that manual peers should stay connected, but it is a behavior change, not a fix for an exploitable vulnerability.
Merge bitcoin/bitcoin#36186: test: return False for a too-short ECDSA signature
00d0c5107b92c8972ab106c680579e06fd4fb100 test: return False for a too-short ECDSA signature (Ferdinando Ametrano)
Pull request description:
`verify_ecdsa` reads `sig[1]` before it checks `len(sig) < 4`, so a 0- or 1-byte signature raises `IndexError` instead of returning `False`, which the comment promises for any DER encoding error.
Move the length check ahead of the byte access, and add a regression test.
ACKs for top commit: optout21: reACK 00d0c5107b92c8972ab106c680579e06fd4fb100 sedited: ACK 00d0c5107b92c8972ab106c680579e06fd4fb100
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
signing boundaryfuzzing or regression evidencemerge-commit duplicate discount
AI analysis · Informational 20/100
This is a small fix in Bitcoin Core's own test helper code. A helper function used only in tests could crash with an IndexError when given an extremely short fake signature, instead of cleanly returning False. The change moves a length check earlier so the function behaves as documented. It does not affect live Bitcoin network code, wallet signing, or transaction validation.
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.
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.
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.
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.
Merge bitcoin/bitcoin#36203: Update secp256k1 subtree to latest master
da3401e50fc12ad71507e646c5e9ae2aaf524722 Squashed 'src/secp256k1/' changes from 687155df6b..a7f264373e (fanquake)
Pull request description:
Primarily prompted by https://github.com/bitcoin-core/secp256k1/pull/1932, which came up here: https://github.com/bitcoin/bitcoin/pull/35301#discussion_r3946630066. See https://github.com/bitcoin-core/secp256k1/issues/1930.
This commit updates Bitcoin Core's embedded secp256k1 cryptography library to a newer version. The visible changes are mostly internal cleanups: renaming functions, moving public-key parsing/serialization code into a different file, replacing an internal accessor with direct structure access, and adding compile-time checks. The only user-visible behavior change mentioned by the project is a small API convenience fix in the experimental silentpayments module: callers can now pass either NULL or a non-NULL pointer when an array argument is empty. The commit also adds a size overflow guard when allocating a scratch buffer. There is no direct evidence in the commit message or diff of a critical vulnerability being fixed, but any change to low-level cryptographic code warrants careful review and testing before deployment.
Squashed 'src/secp256k1/' changes from 687155df6b..a7f264373e
a7f264373e Merge bitcoin-core/secp256k1#1923: group: VERIFY input/output ge/gej/fe exhaustively 3f6ee3e989 Merge bitcoin-core/secp256k1#1931: tests: cover rejection of invalid plain seckey alongside a valid one 05f9289984 tests: silentpayments: cover rejection of invalid plain seckey alongside a valid one 978d3fa7f9 Merge bitcoin-core/secp256k1#1932: silentpayments: drop "empty key arrays must be NULL" requirement ad3688d1e5 changelog: mention dropped NULL requirement for silentpayments key arrays 89e3a70662 silentpayments: drop "empty key arrays must be NULL" requirement c36269ef95 group/refactor: Use constant expression for readability 031dbae659 group: Export secp256k1_ge_set_ge(j)_zinv properly in group.h 4f3bd158d5 group: Cover all input/output ge/gej/fe with VERIFY calls 0711443e6d group: Add missing FE_VERIFY checks on rzr outputs 1bd7492181 group: Remove redundant SECP256K1_GEJ_VERIFY cddd125f72 group: Split functions into pre/post VERIFY and _impl aa0af2fac4 Merge bitcoin-core/secp256k1#1928: tests: add coverage for exact-size DER signature serialization 500ccb60f7 tests: add coverage for exact-size DER signature serialization a9a61831bd Merge bitcoin-core/secp256k1#1924: tests: add coverage for the DER long form length encoding ddb1dfa770 tests: add coverage for the DER long form length encoding 1c8babcd6c Merge bitcoin-core/secp256k1#1922: field: Check that argument of _fe_set_int() is a constant bae6b89a20 Merge bitcoin-core/secp256k1#1908: refactor: replace `_get_hash_context` with direct `->hash_ctx` access f6d821db03 field: Fix typo in comment 1ce0066e60 field: Check that argument of _fe_set_int() is a constant c8745f6b3a refactor: replace `_get_hash_context` with direct `->hash_ctx` access 3397f3cb28 Merge bitcoin-core/secp256k1#1878: field: correct `_fe_half` docs (output is not normalized, input requires magnitude <= 31) 86c7cbaf5a Merge bitcoin-core/secp256k1#1915: refactor: Move (de)ser helpers from musig and eckey to group bfd40bd0ce refactor: Rename privkey to seckey in eckey helpers d8ee6e6cf6 refactor: Move parsing helpers from musig to group a37d7cc064 Merge bitcoin-core/secp256k1#1916: ecdh/ellswift: simplify seckey loading with `_scalar_set_b32_seckey` 3d69f4ce1c Merge bitcoin-core/secp256k1#1911: refactor: rename `ctx` param to `ecmult_gen_ctx` where applicable c00dc81810 ecdh/ellswift: simplify seckey loading with `_scalar_set_b32_seckey` 81a5a7567d refactor: rename `ctx` param to `ecmult_gen_ctx` where applicable 2577fb1888 refactor: Move pubkey parsing and serialization from eckey to group 439278a649 Merge bitcoin-core/secp256k1#1910: scratch: reject sizes that overflow when added to header 3d4340d173 scratch: reject sizes that overflow when added to header 56e031a148 field: correct `_fe_half` docs (output is not normalized, input requires magnitude <= 31)
This is a routine subtree update of the secp256k1 cryptographic library inside Bitcoin Core. Most changes are internal cleanups: renaming variables, moving helper functions between files, adding compile-time checks, and expanding test coverage. The only user-visible behavior change is in the experimental silentpayments module, where two functions no longer require callers to pass NULL for empty key arrays. A small hardening change also prevents an integer overflow when allocating a scratch workspace. There is no evidence in the commit of an active security vulnerability being patched.
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
cryptography-sensitive path
AI analysis · Low 32/100
This commit updates the secp256k1 cryptographic library inside Bitcoin Core to a newer version. The visible changes are mostly internal cleanups: renaming functions, moving code between files, replacing a helper that returned a hash-context pointer with direct access, and adding compile-time checks for some low-level field operations. The changelog explicitly calls out one user-visible fix in the experimental silent-payments module: callers no longer have to pass NULL for empty key arrays. There is also a small hardening change that rejects scratch-space allocation sizes that would wrap around when added to the header size. No Bitcoin Core release notes or security advisory are included in the supplied materials, and the commit message does not describe this as a security fix.
Security candidateMerge bitcoin/bitcoin#35778: scripted-diff: Use C.UTF-8 locale in all shell scriptsby merge-script · 005ea9f4 · Sep 9, 2026 · 13 filesMessage 91 · StrongInformational 15Details
Commit message · merge-script
Merge bitcoin/bitcoin#35778: scripted-diff: Use C.UTF-8 locale in all shell scripts
46654094beefb6d41cad477fc63e8ddbaa5387a2 lint: Use C.UTF-8 locale only in shell scripts (Hennadii Stepanov) 982ee649381f234507e8286f9ca55239a69c1ad7 lint: Skip `libmultiprocess` subtree in `lint-shell-locale.py` (Hennadii Stepanov) 1194918a5d9c4aad1f7a8b9ab2c29666f89c4052 scripted-diff: Use C.UTF-8 locale in all shell scripts (Hennadii Stepanov)
Pull request description:
This unifies the used locales across the entire codebase.
Additionally, the `test/lint/lint-shell-locale.py` linter has been adjusted accordingly.
Also see https://github.com/bitcoin/bitcoin/pull/35775#issuecomment-5047323736.
ACKs for top commit: fanquake: ACK 46654094beefb6d41cad477fc63e8ddbaa5387a2
✓ 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 commit simply changes every shell script in the project from using the plain 'C' locale to the 'C.UTF-8' locale, and updates the project's linter to enforce the new standard. It is a code-quality and consistency change, not a security fix. There is no indication it addresses any vulnerability or security incident.
Merge bitcoin/bitcoin#36181: ci: Upgrade IWYU to 0.27 compatible with Clang 23
3b944f194fddbcff11f7e5bad4e075a5eac5ed78 iwyu: Switch to generated Clang intrinsics mapping file (Hennadii Stepanov) 1b5ee3be5948a21d72fa671d8ad00d5daa1e9de3 ci: Upgrade IWYU to 0.27 compatible with Clang 23 (Hennadii Stepanov) 6ed7c535adb0eef4d66f33f7bd8a44f9c201805b iwyu: Prefer canonical headers (Hennadii Stepanov)
Pull request description:
The new IWYU [release](https://github.com/include-what-you-use/include-what-you-use/tree/clang_23) includes several improvements and bug fixes, including: - https://github.com/include-what-you-use/include-what-you-use/pull/1991 - https://github.com/include-what-you-use/include-what-you-use/pull/2013 - https://github.com/include-what-you-use/include-what-you-use/pull/2014 - https://github.com/include-what-you-use/include-what-you-use/pull/2058 - https://github.com/include-what-you-use/include-what-you-use/pull/2062 - https://github.com/include-what-you-use/include-what-you-use/pull/2093
This allows us to remove all corresponding workarounds and patches.
Additionally, the compiler intrinsics mapping has switched from a hardcoded file to a dynamically generated one.
ACKs for top commit: fanquake: ACK 3b944f194fddbcff11f7e5bad4e075a5eac5ed78 l0rinc: shallow code review ACK 3b944f194fddbcff11f7e5bad4e075a5eac5ed78
✓ 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 controlcryptography-sensitive pathsigning or wallet pathmerge-commit duplicate discount
AI analysis · Informational 15/100
This is a routine developer tooling update. It upgrades the Include What You Use (IWYU) static-analysis tool used in Bitcoin Core's continuous integration from version 0.22 (for Clang 22) to version 0.27 (for Clang 23), removes now-unnecessary local patches and workarounds, and adjusts many source-file #include directives to match the newer tool's recommendations. There is no change to the Bitcoin protocol, consensus logic, wallet behavior, or runtime security. It only affects how headers are checked during automated CI builds.
Security candidateMerge bitcoin/bitcoin#36076: psbt: preserve sighash type when merging inputsby Ava Chow · 4c9d55a6 · Sep 9, 2026 · 2 filesMessage 91 · StrongModerate 51Details
Commit message · Ava Chow
Merge bitcoin/bitcoin#36076: psbt: preserve sighash type when merging inputs
ea785a31f783e67adc9b4f0c4a8e54acd2794904 psbt: preserve sighash type when merging inputs (Thomas)
Pull request description:
`PSBTInput::Merge` copies every optional input field from the other input when it is absent locally, except `PSBT_IN_SIGHASH_TYPE`. So `combinepsbt` silently drops the sighash type whenever the first PSBT does not carry it, making the result depend on the argument order.
The field is what lets finalizers enforce the sighash type of existing signatures (BIP 174). When it is lost, `FinalizePSBT` falls back to the default type (`SIGHASH_ALL`, or `SIGHASH_DEFAULT` for taproot inputs), rejects signatures made with any other type as a sighash mismatch, and the PSBT can no longer be finalized. Combining a PSBT signed with `ALL|ANYONECANPAY` after a merely updated copy of the same PSBT reproduces this: `finalizepsbt` reports it as incomplete, while the reverse order finalizes and broadcasts fine.
Merge the sighash type like the other optional fields, keeping the one already present, and test both combine orders.
ACKs for top commit: achow101: ACK ea785a31f783e67adc9b4f0c4a8e54acd2794904 winterrdog: Re-ACK ea785a31f783e67adc9b4f0c4a8e54acd2794904 vicjuma: ACK ea785a31f783e67adc9b4f0c4a8e54acd2794904 rkrux: lgtm ACK ea785a31f783e67adc9b4f0c4a8e54acd2794904
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundarysigning or wallet pathmerge-commit duplicate discount
AI analysis · Moderate 51/100
This commit fixes a bug in Bitcoin Core's handling of Partially Signed Bitcoin Transactions (PSBTs). When two PSBTs for the same transaction were combined, the intended signature hash (sighash) type could be silently dropped depending on the order the PSBTs were provided. This could cause a valid, already-signed PSBT to become impossible to finalize, because the finalizer would fall back to a default sighash type and reject the existing signatures. The fix makes the merge behave like other optional fields: keep the local value if present, otherwise copy it from the other PSBT. A new test verifies both argument orders now produce the same, finalizable result.
Security candidateMerge bitcoin/bitcoin#34931: validation: abort on DB unreadable coins instead of treating them as missingby merge-script · 59fd053d · Sep 8, 2026 · 6 filesMessage 100 · StrongModerate 63Details
Commit message · merge-script
Merge bitcoin/bitcoin#34931: validation: abort on DB unreadable coins instead of treating them as missing
75f64e50c67dce423efb31fd0a0ac9e1d3320739 test: exercise node abort on UTXO deserialization failure (furszy) 4652cd0d828a14c64b896d1c4d435231bc4d0c50 txdb: detect UTXO deserialization errors via CDBWrapper::TryRead() (furszy) 5dfbb91b6cc5d1e0e3e49dad1fe9dddc4b06dfba dbwrapper: add TryRead() to distinguish errors from valid outcomes (furszy) f78834fac91698ddbcdc807e422fc1bd733a6454 test: add missing coverage for CDBWrapper::Read() errors (furszy)
Pull request description:
Early note: the majority of this PR consists of test coverage. The changes per se are small.
If a UTXO entry on disk can't be deserialized, the node currently treats it as if the coin wouldn't exist instead of aborting with an error. A non-existing coin has a very specific meaning for consensus: any block that spends it would be permanently rejected as invalid (`BLOCK_FAILED_VALID`), silently forking the node from the rest of the network. This can't currently be triggered in practice (details below), but it's still the wrong behavior.
The root cause is that `CDBWrapper::Read()` returns `false` for both missing entries and deserialization failures, so `CCoinsViewDB::GetCoin()` has no way to tell them apart. `CCoinsViewErrorCatcher` was built to catch database read errors and abort, but it never fires during deserialization errors because `CDBWrapper::Read()` swallows the exception before it can propagate. This [comment](https://github.com/bitcoin/bitcoin/blob/8a8edc8d8824464ac7ece958f099f9dfa4cf9d3d/src/coins.cpp#L398-L411) in `ExecuteBackedWrapper()` spells out the code intent very clearly.
As mentioned initially, this can't happen in practice today. It would require either a bug in the coin serialization path, or a memory corruption before the data reaches LevelDB (at which point we have bigger problems). Random disk-level bit flips are caught earlier by LevelDB's verification (`verify_checksums=true`, enabled by default), which already propagates correctly as `DB_INTERNAL_ERROR`. Regardless, a db read issue should never be silently misinterpreted as a consensus violation.
This PR adds `CDBWrapper::TryRead()`, which returns a `ReadStatus` that lets callers discriminate between all possible outcomes. `CCoinsViewDB::GetCoin()` switches on the result and throws on any error, letting `ExecuteBackedWrapper()` do what it was designed to do. `CDBWrapper::Read()` becomes a thin wrapper over `TryRead()`, preserving backward compatibility for all other callers (so we don't have to change non-consensus code here). `PeekCoin()` is also covered, as it delegates to `CCoinsViewDB::GetCoin()` at the database level.
The idea of the PR is to go slowly over the code changes, first commit locks-in the current `CDBWrapper::Read()` behavior . The second adds `TryRead()` with tests for all four status codes. The third is the `CCoinsViewDB::GetCoin()` fix. The fourth is a functional that ensures the node aborts correctly instead of silently diverging.
Testing Notes: Cherry-picking the functional test commit on master demonstrates the consensus split when the coin entry fails to deserialize.
Extra Note: `CDBIterator::GetValue()` has the same silent-swallow pattern. Not consensus-critical. Should be addressed in a follow-up.
ACKs for top commit: ajtowns: reACK 75f64e50c67dce423efb31fd0a0ac9e1d3320739 sedited: ACK 75f64e50c67dce423efb31fd0a0ac9e1d3320739 mzumsande: Code Review ACK [75f64e5](https://github.com/bitcoin/bitcoin/commit/75f64e50c67dce423efb31fd0a0ac9e1d3320739)
✓ 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
defensive validationconsensus or confidential-proof validationmerge-commit duplicate discount
AI analysis · Moderate 63/100
This change fixes a bug where Bitcoin Core could silently treat a corrupted UTXO database entry as if the coin did not exist. Under the old behavior, if a coin on disk could not be deserialized, the node would act like the coin was spent, potentially marking valid blocks as permanently invalid and forking away from the rest of the network. The fix makes the node clearly abort with an error instead, so the operator knows something is wrong and can recover without permanent consensus divergence. The bug is not currently triggerable in practice by an attacker, but the behavior was wrong and dangerous.
Merge bitcoin/bitcoin#36168: PSBT: Make input/output `Merge()` methods return void
82deb69111f15db60aa364db9b06931918691564 PSBT: Make input/output `Merge()` methods return void (nebula-21)
Pull request description:
PSBT input/output `Merge()` methods always return `true` unconditionally and have no failure paths. As a result, the return value checks in `PartiallySignedTransaction::Merge()` can never fail and are dead code. This makes the `bool` return type and `[[nodiscard]]` misleading.
This PR changes both methods to return `void` and remove the return value checks. If at some point in the future the failure logic is needed, it can be introduced again. For now using `void` makes the current behavior easier to understand.
ACKs for top commit: achow101: ACK 82deb69111f15db60aa364db9b06931918691564 polespinasa: ACK 82deb69111f15db60aa364db9b06931918691564 sedited: ACK 82deb69111f15db60aa364db9b06931918691564
✓ 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 boundarysigning or wallet pathmerge-commit duplicate discount
AI analysis · Informational 15/100
This commit is a straightforward code cleanup in Bitcoin Core's Partially Signed Bitcoin Transaction (PSBT) handling. It changes two internal methods from returning true (always, with no way to fail) to returning nothing at all, and removes now-unnecessary error checks. There is no security bug being fixed and no change in behavior for users.
Security candidateMerge bitcoin/bitcoin#36113: psbt: fix rendering for invalid long sighash type fieldby Ava Chow · 2ed4be47 · Sep 7, 2026 · 4 filesMessage 96 · StrongInformational 24Details
Commit message · Ava Chow
Merge bitcoin/bitcoin#36113: psbt: fix rendering for invalid long sighash type field
1fca81960abcd5331765842776909d4787929cea psbt: fix rendering for invalid long sighash type field (Sjors Provoost)
Pull request description:
The `decodepsbt` incorrectly truncates the (32 bit) sighash type field before looking up its human friendly name. It's not dangerous, as such a signature would be invalid, but potentially confusing.
Fix that and add a test.
I plan to use `SighashToStr` in another pull request to render an error message for invalid sighash type field values, but it seemed worth fixing in a standalone PR.
ACKs for top commit: jeanpablojp: ACK 1fca81960abcd5331765842776909d4787929cea achow101: ACK 1fca81960abcd5331765842776909d4787929cea winterrdog: tACK 1fca81960abcd5331765842776909d4787929cea rkrux: lgtm ACK 1fca81960abcd5331765842776909d4787929cea
✓ 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 boundarysigning or wallet pathmerge-commit duplicate discount
AI analysis · Informational 24/100
This change fixes a display bug in Bitcoin Core's PSBT decoder. When a PSBT contains an invalid 32-bit sighash type value, the old code silently truncated it to one byte and then showed a friendly name for that truncated value, which could mislead a user into thinking an invalid signature type was valid. The fix makes the decoder return an empty string for any value that is not a single valid byte, and adds a test. It is not a security vulnerability that can steal funds or crash nodes.
