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 only adds a new automated test to Bitcoin Core. It checks that when a user asks the wallet to import multiple descriptors at once, the list of results comes back in the same order as the original request, including any error me…
This commit only adds new automated tests for the Bitcoin Core wallet's importdescriptors RPC. It checks that the command correctly rejects requests with a missing or invalid timestamp. No production wallet code is changed, so this cannot …
No changes to consensus, networking, wallet logic, or cryptographyOnly functional test code is modifiedAdded assertions are for expected error handling paths
This is a routine code cleanup commit. It adjusts which C++ header files are included in the `src/common` part of Bitcoin Core so that an automated tool called Include What You Use (IWYU) reports no warnings. It also tells the continuous i…
This commit removes an old backward-compatibility feature in Bitcoin Core's wallet RPC command `fundrawtransaction`. Previously, callers could pass a plain `true` or `false` as the second argument, which was silently ignored. Now, passing …
Removal of a no-op backward-compatibility code path that silently accepted arbitrary boolean valuesStricter RPC input validation: bare booleans now rejected with a JSON type errorNo memory safety, cryptographic, or consensus changes observed
This commit adds a new menu item in the Bitcoin Core desktop wallet that lets users export a 'watch-only' copy of their wallet. A watch-only wallet can see transactions and balances but cannot spend funds. The change only wires up an exist…
No security-relevant signals detected in the diffNew GUI feature exposing existing wallet export functionalityAction is disabled for wallets with private keys disabled
This commit adds a user-facing checkbox in the Bitcoin Core desktop wallet that lets someone choose whether to automatically load a wallet after migrating it from an older format. Previously the wallet was always loaded. The change is a us…
No security-relevant signal: change is a feature/usability additionNo memory safety, cryptographic, consensus, or network changesNo privilege boundary crossed
This commit is a code cleanup that changes many internal class constants from 'static const' to 'static constexpr'. In modern C++, constexpr constants are automatically inlined and avoid certain linker errors when used in specific ways. Th…
This is a fix to a Bitcoin Core fuzz test (an automated testing harness), not to the main wallet code that real users run. The test was inserting fake wallet transactions in a way that skipped updating an internal index called m_txos. Beca…
Test-only change in fuzz harnessFixes internal test-state consistency, not production wallet behaviorNo validation, consensus, or P2P networking changes
This commit is a purely cosmetic change in Bitcoin Core's Guix build scripts. It replaces the short shell command 'set -e' with its long-form equivalent 'set -o errexit'. Both forms do exactly the same thing: they make the script exit imme…
This commit only adds or updates copyright and license header comments at the top of several helper scripts used for Bitcoin Core's Guix build process. It does not change any executable code, logic, or behavior. There is no security risk.
This commit updates the secp256k1 cryptographic library inside Bitcoin Core to a newer version. The main change is adding support for a new optional feature called 'Silent Payments' (BIP352), which is a privacy-enhancing way to receive Bit…
New cryptographic module added (Silent Payments / BIP352)Field-element equality check magnitude bound corrected from 31 to 30X-only public key even-Y invariant enforced in extrakeys module
This commit is a routine cleanup that changes the locale setting in Bitcoin Core's Guix build scripts from the old ASCII-only 'C' locale to the modern 'C.UTF-8' locale. It is not a security fix and does not change any behavior that could b…
This change makes Bitcoin Core assume that hard-coded and DNS seed nodes support the newer BIP324 encrypted transport (v2) when first connecting. If the guess is wrong, the software falls back to the older v1 protocol automatically. It is …
Adds NODE_P2P_V2 to assumed service flags for seed-derived addressesFallback to v1 transport exists if the v2 assumption is wrongNo input validation, memory safety, or cryptographic changes
This commit removes workarounds that skipped three Bitcoin Core Qt test suites on macOS when using the 'minimal' Qt platform plugin. The previous commit fixed the underlying crash cause, so these tests can now run. It is a test-infrastruct…
No security-relevant code change in the diff itselfReferences a prior crash fix, but this commit only removes test skipsNo input handling, cryptography, networking, consensus, or wallet logic modified
This is a code cleanup (refactor) that moves the internal SipHash mixing steps into shared helper methods. It does not change how Bitcoin hashes data, how many rounds are run, or any user-visible behavior. There is no security bug being fi…
This commit adds a new, weaker variant of the SipHash algorithm inside Bitcoin Core's cryptography module. It is explicitly designed for low-security uses such as internal hash tables, not for protecting funds or network messages. The code…
New weaker cryptographic primitive added (SipHash-1-3 vs. standard SipHash-2-4)Explicit unpadded input design removes length-commitment paddingJumbo 256-bit blocks increase attacker control within a single round
This commit only adds new performance benchmark tests for a hash function called SipHash. It does not change any production code that handles Bitcoin transactions, networking, or wallet data. There is no security issue here.
This commit adds two new shortcut methods for computing a specific SipHash variant on fixed-size inputs. It is a pure performance/ergonomics addition: the new methods copy the hasher's internal state before operating, so they do not alter …
This commit only adds new test data and test code for the SipHash hashing function used in Bitcoin Core. It does not change any production code that handles transactions, networking, or wallets. The goal is to make sure the existing SipHas…
This commit adds a new unit test for Bitcoin Core's coin selection algorithm. It checks that when the Branch-and-Bound (BnB) search finds a usable coin selection early but then keeps searching for a better one until it hits the attempt lim…
Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
Security candidateMerge bitcoin/bitcoin#32621: contrib: utxo_to_sqlite.py: add option to store txid/spk as BLOBsby merge-script · 6d625af2 · Feb 8, 2026 · 2904 filesMessage 100 · StrongInformational 15Details
Commit message · merge-script
Merge bitcoin/bitcoin#32621: contrib: utxo_to_sqlite.py: add option to store txid/spk as BLOBs
7378f27b4fb512567b6152f986f67d9263d08d7a test: run utxo-to-sqlite script test with spk/txid format option combinations (Sebastian Falbesoner) b30fca7498c93356fbdb8c2ce881aa8e548bae17 contrib: utxo_to_sqlite.py: add options to store txid/spk as BLOBs (Sebastian Falbesoner)
Pull request description:
This PR is a late follow-up to https://github.com/bitcoin/bitcoin/pull/27432, introducing an option for the utxo-to-sqlite script to store the txid/scriptPubKey columns as bytes (= `BLOB` storage class in sqlite, see e.g. https://www.sqlite.org/datatype3.html in sqlite) rather than hex strings. This was proposed in earlier reviews (https://github.com/bitcoin/bitcoin/pull/27432#issuecomment-1516857024, https://github.com/bitcoin/bitcoin/pull/27432#issuecomment-1653739351) and has the obvious advantage of a significantly smaller size of the resulting database (and with that, faster conversion) and the avoidance of hex-to-bytes conversion for further processing of the data [1]. The rationale on why hex strings were chosen back then (and still stays the default, if only for compatibility reasons) is laid out in https://github.com/bitcoin/bitcoin/pull/27432#issuecomment-1516922824 [2].
The approach taken is introducing new parameters `--spk` and `--txid` which can either have the values "hex", "raw" (for scriptpubkey) and "hex", "raw", "rawle" (for txid). Thanks to ajtowns for providing this suggestion. Happy to take further inputs on naming and thoughts on future extensibility etc.
[1] For a concrete example, I found that having these columns as bytes would be nice while working on a SwiftSync hints generator tool (https://github.com/theStack/swiftsync-hints-gen), which takes the result of the utxo-to-sqlite tool as input. [2] note that in contrast what I wrote back then, I think there is no ambiguity on byte-string-serialization of txids; they are ultimately just hash results and hence, they should be stored as such, and adding a big/little endian knob wouldn't make much sense. The drawback of not being able to immediately show txid-strings (as one would need to do the bytes-reversal step first, which is not possible in sqlite, see e.g. https://github.com/bitcoin/bitcoin/pull/24952#issuecomment-1165499803) still remains though.
ACKs for top commit: ajtowns: ACK 7378f27b4fb512567b6152f986f67d9263d08d7a w0xlt: reACK https://github.com/bitcoin/bitcoin/pull/32621/commits/7378f27b4fb512567b6152f986f67d9263d08d7a sedited: ACK 7378f27b4fb512567b6152f986f67d9263d08d7a
✓ 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
cryptography-sensitive pathseed or entropy pathsigning or wallet pathboot or update pathauthentication pathparser or protocol pathmerge-commit duplicate discount
AI analysis · Informational 15/100
This commit is a normal feature addition to a helper script in the Bitcoin Core repository. It lets users of the contrib/utxo_to_sqlite.py tool choose whether transaction IDs and script public keys are stored as hexadecimal text or as raw binary data in the resulting SQLite database. This is purely an optional convenience/efficiency improvement for an offline analysis tool and does not change Bitcoin Core's node, wallet, consensus, or network behavior.
Simplify the benchmark with the following changes: - Set the deterministic private key using uint256::ONE, put it in a `FlatSigningProvider` instance for easier signing - Use `GetScriptForDestination` for creating the output script - Use `SignTransaction` to sign, instead of doing it manually (also removes the need to caclulate the public key hash manually) - Pass standard script verification flags instead of combining them manually
These steps, in particular the generalized signing, prepare the benchmarking extension for a different script type (P2TR key-path) in the next commit.
88/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
secret or key materialsigning boundarydefensive validation
AI analysis · Informational 15/100
This commit is a code cleanup inside a performance benchmark file. It changes how a test script creates a fake Bitcoin transaction and signature for timing purposes only. There is no change to the live Bitcoin network code, wallet handling, or consensus rules, and nothing in the commit suggests a security fix or vulnerability.
Security candidatelogging: use util/log.h where possibleby stickies-v · 37cc2a2d · Feb 2, 2026 · 33 filesMessage 68 · AdequateInformational 15Details
Commit message · stickies-v
logging: use util/log.h where possible
Preparation for a future commit where kernel's dependency on logging.cpp is removed completely.
Replace usage of logging\.h with util/log\.h where it suffices, and fix wrong includes according to iwyu.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
seed or entropy pathsigning or wallet path
AI analysis · Informational 15/100
This is a routine code cleanup change. It swaps one internal logging header file for another, smaller one across many source files and fixes a few include-order style issues. There is no change to program behavior, no bug fix, and no security-relevant modification.
Security candidateci: use Alpine 3.23by fanquake · d4057131 · Feb 2, 2026 · 1 fileMessage 50 · ThinInformational 15Details
Commit message · fanquake
ci: use Alpine 3.23
50/100 · ThinMessage clarity
✓ Subject identifies a change✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
authentication path
AI analysis · Informational 15/100
This commit simply updates the version of the Alpine Linux container used in Bitcoin Core's automated testing from Alpine 3.22 to Alpine 3.23. It is a routine CI (continuous integration) maintenance change with no visible security relevance in the commit itself.
Security candidateSquashed 'src/secp256k1/' changes from 14e56970cb..57315a6985by fanquake · 9d4c9b00 · Feb 2, 2026 · 14 filesMessage 86 · StrongInformational 15Details
Commit message · fanquake
Squashed 'src/secp256k1/' changes from 14e56970cb..57315a6985
57315a6985 Merge bitcoin-core/secp256k1#1813: Remove trailing spaces and introduce `-Wtrailing-whitespace=any` compiler flag 86cae58d2f build: Add `-Wleading-whitespace=spaces` compiler flag fb229e7602 build: Add `-Wtrailing-whitespace=any` compiler flag 13e3bee504 refactor: Remove trailing whitespace 453949ab2a Merge bitcoin-core/secp256k1#1816: ci: Rotate Docker cache keys cd49c57e44 Merge bitcoin-core/secp256k1#1814: release process: mention the `[Unreleased]` link clearly 2ccff6eb73 ci: Add weekly schedule 2f18567d24 ci: Rotate Docker cache keys every 4 weeks 0ffb1749a5 ci, docker: Fix LLVM repository signature failure 0267b65512 release process: mention the `[Unreleased]` link clearly 1605b02f75 Merge bitcoin-core/secp256k1#1775: Add CMake build directory patterns to `.gitignore` 748c0fdd67 Add CMake build directory patterns to `.gitignore` 7eb86bdb01 autotools: Rename `build-aux` to `autotools-aux`
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarycryptography-sensitive path
AI analysis · Informational 15/100
This commit is a routine subtree update for the secp256k1 cryptographic library used by Bitcoin Core. The changes are purely housekeeping: removing trailing/leading whitespace, adding compiler warnings for whitespace, renaming a build directory, rotating CI Docker cache keys, and updating release documentation. There are no changes to cryptographic algorithms, no bug fixes, and no security patches.
Security candidateci: Treat SHA1 LLVM signing key as warningby will · 3c8f5e48 · Feb 2, 2026 · 1 fileMessage 88 · StrongInformational 21Details
Commit message · will
ci: Treat SHA1 LLVM signing key as warning
The current SHA1 LLVM signing key is considered not secure since 2026-02-01T00:00:00Z which makes this run fail when downloading packages.
Apply the fix from the issue to temporarily to treat this error as a warning, until the upstream key can be updated.
This PR should be reverted once the upstream key is updated.
88/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundary
AI analysis · Informational 21/100
This change is a temporary workaround for a CI build script. It relaxes a security policy so that apt can still accept an older SHA1-based LLVM signing key after a deadline passed. It is not a fix for a vulnerability in Bitcoin Core itself, but it slightly weakens a cryptographic check in the automated test environment until LLVM updates its key.
Security candidatetest: Fix a STRICTENC test in script_testsby billymcbip · 884978f3 · Jan 30, 2026 · 1 fileMessage 95 · StrongInformational 15Details
Commit message · billymcbip
test: Fix a STRICTENC test in script_tests
Fix a test that isn't implemented as intended. The idea is to test execution order by providing a signature that would cause script failure when parsed. An empty signature does not cause script failure in CHECKMULTISIG. Use OP_1 for the second signature instead of OP_0.
95/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 15/100
This is a one-line fix to a Bitcoin Core unit test file. The test was not exercising what its author intended because an empty signature does not trigger the expected script failure in a CHECKMULTISIG operation. The change replaces an empty second signature with a non-empty one so the test actually checks the intended execution-order behavior. It does not change any production code, consensus rules, or network behavior.
Security candidateiwyu: Add temporary mapping to work around upstream bugby Hennadii Stepanov · 91824646 · Jan 30, 2026 · 3 filesMessage 30 · OpaqueInformational 15Details
Commit message · Hennadii Stepanov
iwyu: Add temporary mapping to work around upstream bug
30/100 · OpaqueMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body! Contains work-in-progress language! Opaque security-relevant change
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100
This commit is a minor housekeeping change. It removes two unused '#include <iterator>' lines from source files and adds a temporary mapping for a third-party code-tidying tool (IWYU) to work around a known upstream bug. There is no change to Bitcoin's actual logic, networking, cryptography, or consensus behavior, and no security relevance.
Security candidateSquashed 'src/secp256k1/' changes from d543c0d917..14e56970cbby fanquake · 2fccbea3 · Jan 27, 2026 · 37 filesMessage 100 · StrongLow 29Details
Commit message · fanquake
Squashed 'src/secp256k1/' changes from d543c0d917..14e56970cb
14e56970cb Merge bitcoin-core/secp256k1#1794: ecmult: Use size_t for array indices c7a52400d6 Merge bitcoin-core/secp256k1#1809: release cleanup: bump version after 0.7.1 ae7eb729c0 release cleanup: bump version after 0.7.1 1a53f4961f Merge bitcoin-core/secp256k1#1808: Prepare for 0.7.1 20a209f11c release: prepare for 0.7.1 c4b6a81a60 changelog: update in preparation for the v0.7.1 release ebb35882da Merge bitcoin-core/secp256k1#1796: bench: fail early if user inputs invalid value for SECP256K1_BENCH_ITERS c09215f7af bench: fail early if user inputs invalid value for SECP256K1_BENCH_ITERS 471e3a130d Merge bitcoin-core/secp256k1#1800: sage: verify Eisenstein integer connection for GLV constants 29ac4d8491 sage: verify Eisenstein integer connection for GLV constants 4721e077b4 Merge bitcoin-core/secp256k1#1793: doc/bench: added help text for SECP256K1_BENCH_ITERS env var for bench_ecmult bd5ced1fe1 doc/bench: added help text for SECP256K1_BENCH_ITERS env var for bench_ecmult 47eb70959a ecmult: Use size_t for array indices in _odd_multiplies_table bb1d199de5 ecmult: Use size_t for array indices into tables 2d9137ce9d Merge bitcoin-core/secp256k1#1764: group: Avoid using infinity field directly in other modules f9a944ff2d Merge bitcoin-core/secp256k1#1790: doc: include arg -DSECP256K1_USE_EXTERNAL_DEFAULT_CALLBACKS=ON for cmake 0406cfc4d1 doc: include arg -DUSE_EXTERNAL_DEFAULT_CALLBACKS=1 for cmake 8d445730ec Merge bitcoin-core/secp256k1#1783: Add VERIFY_CHECKs and documentation that flags must be 0 or 1 aa2a39c1a7 Merge bitcoin-core/secp256k1#1778: doc/bench: Added cmake build options to bench error messages 540fec8ae9 Merge bitcoin-core/secp256k1#1788: test: split monolithic ellswift test into independent cases d822b29021 test: split monolithic ellswift test into independent cases ae00c552df Add VERIFY_CHECKs that flags are 0 or 1 5c75183344 Merge bitcoin-core/secp256k1#1784: refactor: remove ret from secp256k1_ec_pubkey_serialize be5e4f02fd Merge bitcoin-core/secp256k1#1779: Add ARG_CHECKs to ensure "array of pointers" elements are non-NULL 3daab83a60 refactor: remove ret from secp256k1_ec_pubkey_serialize 8bcda186d2 test: Add non-NULL checks for "pointer of array" API functions 5a08c1bcdc Add ARG_CHECKs to ensure "array of pointers" elements are non-NULL 3b5b03f301 doc/bench: Added cmake build options to bench error messages e7f7083b53 Merge bitcoin-core/secp256k1#1774: refactor: split up internal pubkey serialization function into compressed/uncompressed variants b6c2a3cd77 Merge bitcoin-core/secp256k1#1761: ecmult_multi: reduce strauss memory usage by 30% f5e815f430 remove secp256k1_eckey_pubkey_serialize function 0d3659c547 use new `_eckey_pubkey_serialize{33,65}` functions in modules (ellswift,musig) adb76f82ea use new `_eckey_pubkey_serialize{33,65}` functions in public API fc7458ca3e introduce `secp256k1_eckey_pubkey_serialize{33,65}` functions c8206b1ce6 Merge bitcoin-core/secp256k1#1771: ci: Use Python virtual environment in "x86_64-macos-native" job f252da7e6e ci: Use Python virtual environment in "x86_64-macos-native" job 115b135fe8 Merge bitcoin-core/secp256k1#1763: bench: Use `ALIGNMENT` macro instead of hardcoded value 2f73e5281d group: Avoid using infinity field directly in other modules 153eea20c2 bench: Use `ALIGNMENT` macro instead of hardcoded value 26166c4f5f ecmult_multi: reduce strauss memory usage by 30% 7a2fff85e8 Merge bitcoin-core/secp256k1#1758: ci: Drop workaround for Valgrind older than 3.20.0 43e7b115f7 Merge bitcoin-core/secp256k1#1759: ci: Switch to macOS 15 Sequoia Intel-based image 8bc50b72ff ci: Switch to macOS 15 Sequoia Intel-based image c09519f0e3 ci: Drop workaround for Valgrind older than 3.20.0
✓ 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
cryptography-sensitive path
AI analysis · Low 29/100
This is a routine subtree update that pulls in the latest libsecp256k1 maintenance release (0.7.1 → 0.7.2 development). The bundled changes are mostly cleanups: stricter input validation (rejecting NULL pointers in arrays), safer internal serialization helpers, documentation and benchmark fixes, CI updates, and a build fix for x86_64 assembly detection. The vendor's own changelog explicitly lists these as non-security bug fixes and ABI-compatible improvements. There is no evidence in the commit of an undisclosed vulnerability, exploit, or attacker-relevant flaw.
Security candidatewallet: fix `gethdkeys` RPC for descriptors with partial xprvsby rkrux · 6e3a0afc · Jan 23, 2026 · 1 fileMessage 78 · AdequateLow 33Details
Commit message · rkrux
wallet: fix `gethdkeys` RPC for descriptors with partial xprvs
A non-watch-only wallet allows to import descriptors with partial private keys, eg: a multisig descriptor with one private key and one public key. In case an xpub is imported in any such descriptors whose private key the wallet doesn't have, then the `gethdkeys` RPC throws an unhandled error like below when the private keys are requested.
This fix ensures that such calls are properly handled by conditionally finding the corresponding xprv. Some related documentation of this RPC is also updated.
``` ➜ bitcoincli -named gethdkeys private=true error code: -1 error message: map::at: key not found ```
78/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
secret or key materialsigning or wallet path
AI analysis · Low 33/100
This commit fixes a bug in Bitcoin Core's `gethdkeys` RPC command. The command can crash with an unhandled 'key not found' error when a user requests private key information for a wallet that contains descriptors where some extended public keys (xpubs) do not have corresponding private keys in the wallet. The fix prevents the crash by only trying to return the private key when the wallet actually has it, and it updates the related documentation to clarify that the descriptor string shown is the public version.
Security candidatescript: add SCRIPT_ERR_SCRIPTNUM errorby Bruno Garcia · 0ca4dcd7 · Jan 22, 2026 · 2 filesMessage 63 · AdequateInformational 18Details
Commit message · Bruno Garcia
script: add SCRIPT_ERR_SCRIPTNUM error
It will be used for errors related to CScriptNum (e.g. overflow or encoding errors). Currently, we simply return unknown error for these errors.
This commit adds a new, more descriptive error code for problems with numbers inside Bitcoin's script language. Previously, these problems were reported as a generic 'unknown error.' The change only defines the new error label and its human-readable message; it does not yet change any code that actually raises the error. By itself, this is a small cleanup that does not fix or introduce a security vulnerability.
Security candidatetest: clean up tx resurrection (re-org) test in feature_block.pyby Sebastian Falbesoner · 5b2c3960 · Jan 21, 2026 · 1 fileMessage 100 · StrongInformational 15Details
Commit message · Sebastian Falbesoner
test: clean up tx resurrection (re-org) test in feature_block.py
This comment about ECDSA signatures created with the test framework not passing mempool policy has been obsolete for a long time (at least since 2019, see PR #15826), so remove it. While at it, change the resurrected txs to be indeed standard valid, so the `-acceptnonstdtxn=1` parameter can also be removed.
100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundary
AI analysis · Informational 15/100
This is a cleanup change to one of Bitcoin Core's own automated tests. It removes an outdated comment about signature quirks and adjusts the test transactions so they follow normal network rules, allowing a special 'accept non-standard transactions' flag to be removed. It does not change any production code that runs on real Bitcoin nodes, so it has no direct security impact on the network or users.
test(miniscript): Prove avoidance of stack overflow
Can be tested through emptying the function body of ~Node() or replacing Clone() implementation with naive version: ```C++ Node<Key> Clone() const { std::vector<Node> new_subs; new_subs.reserve(subs.size()); for (const Node& child : subs) { new_subs.push_back(child.Clone()); } return Node{internal::NoDupCheck{}, m_script_ctx, fragment, std::move(new_subs), keys, data, k}; } ```
Co-authored-by: Lőrinc <pap.lorinc@gmail.com>
100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
memory safety
AI analysis · Informational 12/100
This commit only adds a new automated test to Bitcoin Core. The test builds an extremely deep Miniscript node tree and then exercises its destructor, clone, and move-assignment to confirm they do not overflow the call stack. It is a defensive regression test, not a fix for any currently broken or exploitable behavior.
Security candidateMerge bitcoin/bitcoin#32143: Fix 11-year-old mis-categorized error code in OP_IF evaluationby Ava Chow · 34784016 · Jan 20, 2026 · 2889 filesMessage 81 · StrongInformational 23Details
Commit message · Ava Chow
Merge bitcoin/bitcoin#32143: Fix 11-year-old mis-categorized error code in OP_IF evaluation
This was introduced by commit ab9edbd6b6eb3efbca11f16fa467c3c0ef905708.
It appears the original author may have gotten tired and pasted the wrong error code into this 1 place. Every other situation where the value stack lacks the required number of arguments for the op-code, SCRIPT_ERR_INVALID_STACK_OPERATION is reported. Not so here.
This commit fixes the situation.
EDIT: Note this turns out to be a dupe of the abandoned #30359 .
ACKs for top commit: billymcbip: tACK a7b581423e44c51fb7d177c5a15fe2cc2ab8aa43 achow101: ACK a7b581423e44c51fb7d177c5a15fe2cc2ab8aa43 darosior: utACK a7b581423e44c51fb7d177c5a15fe2cc2ab8aa43 sedited: ACK a7b581423e44c51fb7d177c5a15fe2cc2ab8aa43
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
cryptography-sensitive pathseed or entropy pathsigning or wallet pathboot or update pathauthentication pathparser or protocol pathmerge-commit duplicate discount
AI analysis · Informational 23/100
This commit fixes a long-standing mistake in how Bitcoin Core reports an error when an OP_IF command is used without enough values on the script stack. In one specific spot, the wrong error code was returned for 11 years. The fix makes the error code consistent with every other similar case. This is a minor correctness/observability fix, not a vulnerability that lets an attacker steal funds or crash nodes.
I think this is just a copy-pasta from the build container. I don't see why we'd need the depends sources available when performing codesigning.
80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 17/100
This commit removes leftover code that unnecessarily shared Bitcoin's dependency source files into the isolated Guix container used for codesigning release binaries. The change is described by the author as a cleanup of copy-pasted build-container options, not a security fix. It slightly reduces the attack surface of the codesigning environment by exposing fewer files, but there is no direct evidence of an exploitable vulnerability.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
cryptography-sensitive pathseed or entropy pathsigning or wallet path
AI analysis · Informational 15/100
This commit is a pure code-style cleanup. It removes unnecessary 'const' keywords from function parameter declarations in header files across the Bitcoin Core codebase and adds a clang-tidy rule to prevent them from being reintroduced. The 'const' on a value parameter in a declaration has no effect on callers and does not change program behavior, security, or runtime semantics. There is no vulnerability here.
The previous `assert` used `>=`, allowing `input_index == psbt.inputs.size()` and out-of-bounds access in `psbt.inputs[input_index]`.
Found during review: https://github.com/bitcoin/bitcoin/pull/31650#discussion_r2685892867
81/100 · StrongMessage clarity
✓ 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 path
AI analysis · Low 45/100
A one-character bug fix in Bitcoin Core's PSBT (Partially Signed Bitcoin Transaction) handling. The code used the wrong comparison in a safety check, so it was possible to request an input index exactly equal to the number of inputs. That would read one element past the end of the list, which can cause a crash or undefined behavior. The fix changes the check so it correctly rejects that out-of-bounds index.
scripted-diff: Remove priority_level from BENCHMARK macro
-BEGIN VERIFY SCRIPT-
sed --in-place --regexp-extended 's/BENCHMARK\(([^,]+), benchmark::PriorityLevel::(HIGH|LOW)\)/BENCHMARK(\1)/g' $( git grep -l PriorityLevel ) sed --in-place 's/#define BENCHMARK(n, priority_level)/#define BENCHMARK(n)/g' ./src/bench/bench.h
-END VERIFY SCRIPT-
83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
cryptography-sensitive pathseed or entropy pathsigning or wallet path
AI analysis · Informational 15/100
This commit is a cleanup change to Bitcoin Core's internal benchmark test code. It removes an unused 'priority level' argument from the BENCHMARK macro and from all benchmark definitions. The change does not affect the live Bitcoin network, wallet funds, node operations, or any security-sensitive code.
Security candidatepsbt: validate pubkeys in MuSig2 pubnonce/partial sig deserializationby tboy1337 · f51665be · Jan 12, 2026 · 2 filesMessage 100 · StrongModerate 60Details
Commit message · tboy1337
psbt: validate pubkeys in MuSig2 pubnonce/partial sig deserialization
Add validation for pubkeys in MuSig2 pubnonce and partial signature deserialization to prevent crashes with invalid curve points.
- Validate aggregate and participant pubkeys in PSBT MuSig2 fields
- Add comprehensive test coverage for invalid pubkey rejection
- Ensure proper error handling during PSBT deserialization
100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarydefensive validationsigning or wallet path
AI analysis · Moderate 60/100
This commit fixes a bug in Bitcoin Core's handling of partially signed Bitcoin transactions (PSBTs) that use the MuSig2 multi-signature scheme. Previously, when reading certain MuSig2 fields, the code accepted invalid public keys (points that are not valid on the Bitcoin elliptic curve). The fix adds checks that reject these invalid keys during deserialization, turning potential crashes or undefined behavior into clean error messages. The commit also adds test cases with deliberately bad keys to confirm they are rejected.
Security candidatedescriptor: ToPrivateString() pass if at least 1 priv key existsby Novo · 9e5e9824 · Jan 7, 2026 · 6 filesMessage 73 · AdequateInformational 23Details
Commit message · Novo
descriptor: ToPrivateString() pass if at least 1 priv key exists
- Refactor Descriptor::ToPrivateString() to allow descriptors with missing private keys to be printed. Useful in descriptors with multiple keys e.g tr() etc. - The existing behaviour of listdescriptors is preserved as much as possible, if no private keys are availablle ToPrivateString will return false
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
secret or key material
AI analysis · Informational 23/100
This Bitcoin Core change alters how wallet descriptors are printed when some (but not all) private keys are present. Previously, exporting a private descriptor would fail entirely if any single key was missing. Now it succeeds and exports the private keys it does have, falling back to public keys for the rest. The commit message and code comments frame this as a usability improvement for multi-key descriptors such as taproot (tr()). There is no direct evidence in the commit of a security vulnerability being fixed; it appears to be a behavior change that could affect information disclosure expectations.
Security candidatedescriptor: refactor ToPrivateString for providersby Novo · 5c4db25b · Jan 7, 2026 · 1 fileMessage 78 · AdequateInformational 21Details
Commit message · Novo
descriptor: refactor ToPrivateString for providers
This commit modifies the Pubkey providers to return the public string if private data is not available. This is setup for a future commit to make Descriptor::ToPrivateString return strings with missing private key information.
Co-authored-by: rkrux <rkrux.connect@gmail.com>
78/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
secret or key material
AI analysis · Informational 21/100
This commit refactors how Bitcoin Core's descriptor code turns key information into text when private keys are requested but not available. Previously, if any private key was missing, the whole private-string output could be dropped or partially empty. Now the code falls back to including the public version of the missing key instead, and reports whether any private keys were actually included. It is a behavior change in output formatting, not a fix for an active exploit, and the commit message explicitly calls it setup for a later change.
Security candidatewallet/migration: use HavePrivateKeys in place of ToPrivateStringby Novo · 2dc74e3f · Jan 7, 2026 · 1 fileMessage 85 · StrongInformational 20Details
Commit message · Novo
wallet/migration: use HavePrivateKeys in place of ToPrivateString
ToPrivateString() behaviour will be modified in the following commits.
In order to keep the scope of this PR limited to the RPC behaviour, this commit updates wallet migration to use 'Descriptor::HavePrivateKeys()' in place of 'Descriptor::ToPrivateString()' to determine watchonly descriptors.
A follow-up PR can be opened to update migration logic to exclude descriptors with some private keys from the watchonly migration wallet.
85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
secret or key materialsigning or wallet path
AI analysis · Informational 20/100
This is a small internal refactoring change in Bitcoin Core's wallet migration code. It swaps one method for another when deciding whether a wallet descriptor should be treated as watch-only during migration. The commit message says this is to keep the current pull request focused on RPC behavior and that a follow-up change may refine the logic later. There is no direct evidence in the commit of a security bug being fixed.
Security candidatedescriptors: add HavePrivateKeys()by Novo · e842eb90 · Jan 7, 2026 · 4 filesMessage 63 · AdequateLow 28Details
Commit message · Novo
descriptors: add HavePrivateKeys()
Previously, to determine if a desc is watchonly, `ToPrivateString()`, was used. It returns `false` if there is at least one pubkey in the descriptor for which the provider does not have a private key.
ToPrivateString() behaviour will change in the following commits to only return `false` if no priv keys could be found for the pub keys in the descriptor.
HavePrivateKeys() is added here to replace the use of ToPrivateString() for determining if a descriptor is 'watchonly'.
This commit adds a new helper function called HavePrivateKeys() to Bitcoin Core's descriptor system. It is a preparatory refactor: it gives the code a clearer way to check whether a wallet descriptor is 'watch-only' (has no private keys) before an upcoming change to ToPrivateString(). The commit itself does not change user-visible behavior; it only introduces the new check and updates tests to use it. There is no direct evidence in the commit that this fixes an active security bug, but it is clearly related to correctly identifying whether private keys are present, which can affect wallet security logic.
Security candidate[test] Add BIP 328 test vectors for Musig2by w0xlt · a3c71c72 · Jan 6, 2026 · 2 filesMessage 55 · ThinInformational 15Details
Commit message · w0xlt
[test] Add BIP 328 test vectors for Musig2
55/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
fuzzing or regression evidencecryptography-sensitive path
AI analysis · Informational 15/100
This commit only adds new test code. It introduces test vectors for BIP 328 (a Bitcoin improvement proposal related to the MuSig2 multi-signature scheme) to verify that public-key aggregation and synthetic extended-public-key generation produce expected outputs. No production code is changed, so it cannot directly introduce a runtime security vulnerability.
psbt: detect invalid MuSig2 pubkeys in deserialization
Throw error while deserializing PSBT if invalid pubkeys are passed as a MuSig2 aggregate or participant.
65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 44/100
This Bitcoin Core patch adds a missing validation check during PSBT (Partially Signed Bitcoin Transaction) parsing. Specifically, it now rejects MuSig2 aggregate and participant public keys that are not cryptographically valid, rather than silently accepting malformed or invalid key bytes. This prevents downstream code from operating on bad public keys, which could lead to incorrect behavior or crashes.
