CommitWatch RSS
BC
← All projectsBitcoin Core

Bitcoin Core

The Bitcoin network's reference node and wallet implementation.

BitcoinSupply chainNormal
Source repository ↗
Repository coverage

2876 commits in the local evidence base

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.

252security candidates603second-pass queue166AI analyses
210commits · 30 days
492commits · 60 days
1521commits · 180 days
2876commits · 365 days
Backfill bands
Aug 5 → Feb 61351 seen45 candidatesComplete
Feb 6 → Jun 61033 seen63 candidatesComplete
Jun 6 → Jul 6281 seen11 candidatesComplete
Jul 6 → Aug 5207 seen5 candidatesComplete
Commit communication

Does the history explain itself?

Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.

70/100 average clarity
915Strong · 80–100
1187Adequate · 60–79
686Thin · 40–59
88Opaque · 0–39
6security candidates with opaque commit messaging
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
Antoine Poinsot2243170
Ava Chow1564946064
MarcoFalke4062112074
Lőrinc1772111081
fanquake227198057
Hennadii Stepanov208147063
rkrux5797074
Sjors Provoost8984074
Sebastian Falbesoner3375073
David Gumberg5563072
Pieter Wuille9552066
Hodlinator6652076
Analysis record

Published AI watches

Last scanned 42 minutes ago

Informational 15 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

refactor: Make all `const static` class members `constexpr`

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…

05c35c40by rustaceanrob+38−4024 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 83 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

scripted-diff: Use long form of shell options in Guix scripts

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…

2cb3bfa8by Hennadii Stepanov+6−66 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 45 · Thin
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

guix: Add copyright headers to Guix scripts

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.

711eb10fby Hennadii Stepanov+20−27 files
No security note in commit
Open full analysis →Source commit ↗
Low 28 AI analysisMessage 96 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Squashed 'src/secp256k1/' changes from bd0287d650..d2d04864ef

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
a33f2405by fanquake+13939−13434 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 90 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

scripted-diff: Use C.UTF-8 locale in Guix scripts

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…

8916f796by Hennadii Stepanov+15−1515 files
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 68 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

p2p: Assume v2transport for addresses from seeds

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
cf0f2aeaby Martin Zumsande+10−22 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 90 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: add shared SipHash vectors

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…

af50ba85by Lőrinc+797−237 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 72 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: compat, ensure downgrade preserves tx witness variants

This commit adds a new regression test to Bitcoin Core. It checks that when a wallet created on a newer version is loaded on an older version and then brought back to the newer version, the wallet still remembers alternative 'witness varia…

99bdcb06by furszy+74−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 68 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

fuzz: clang-format LIMITED_WHILE

This commit is purely a code-style cleanup. It adds a space between the macro name LIMITED_WHILE and its opening parenthesis across many fuzz test files, plus a few tiny formatting fixes like removing a redundant semicolon and fixing inden…

fab8eeedby MarcoFalke+91−14265 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 63 AI analysisMessage 90 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

net_processing: add a global delay queue for sending txs

This commit adds a global rate limiter to how many transaction announcements (INV messages) a Bitcoin node sends out. Before, each peer had its own queue, so a node could receive one transaction and announce it to over 100 peers, acting li…

Global rate limiting replaces per-peer queues to prevent transaction-announcement amplificationDual token buckets bound both INV count and relay bandwidthCommit message explicitly describes the change as limiting transaction-spam amplification and excessive memory/CPU usage
df31ee57by Anthony Towns+176−252 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 24 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: add regression test for in-memory SQLiteDatabase reopen

This commit only adds a new automated test. It checks that Bitcoin Core's in-memory SQLite wallet database correctly refuses to reopen after being closed, because reopening would silently create a fresh empty database and discard any previ…

Regression test for data-loss prevention behavior in wallet database layerIn-memory SQLite database reopen could silently discard wallet dataOpen() now throws std::runtime_error instead of returning a fresh connection
777d23f2by Pablo Martin+9−01 file
No security note in commit
Open full analysis →Source commit ↗
Low 43 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

refactor: Use u64 over size_t for all cache sizes to fix a 32-bit overflow

This commit fixes a bug in Bitcoin Core that only affects 32-bit computers. When the program calculated how much database cache to allocate, it multiplied a large default cache value by 10. On 32-bit systems that multiplication overflowed,…

Integer overflow in cache-size calculation on 32-bit systemsUnsigned multiplication overflow explicitly mentioned in commit message with runtime sanitizer outputType promotion from size_t to uint64_t to prevent platform-dependent width issues
fabafd91by MarcoFalke+37−285 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 23 AI analysisMessage 85 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

wallet: Use Descriptor::CanSelfExpand() in CanGetAddresses()

This is a small Bitcoin Core wallet change that lets the wallet generate addresses from certain descriptors even when it does not have private keys and has already used up its pre-derived address range. It only affects descriptors that can…

Changes address-derivation gating logic in wallet codeExpands conditions under which addresses can be produced without private keysNo explicit security framing, CVE, or advisory language in commit
1e996640by Ava Chow+1−11 file
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 58 · Thin
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

descriptor: Add CanSelfExpand()

This commit adds a new helper method called CanSelfExpand() to Bitcoin Core's descriptor system. It lets the code ask whether a wallet descriptor can produce its Bitcoin address(es) on its own, without needing a saved cache or private keys…

New API surface added to descriptor subsystem (CanSelfExpand)No change to existing expansion, signing, or key-derivation logicNo bounds, memory, or cryptographic operations modified
d2ee9227by Ava Chow+57−184 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: introduce NodeSigner, run feature_taproot.py without wallet compiled

This commit only changes Bitcoin Core's internal functional test code. It introduces a small test helper class called NodeSigner so that one specific test (feature_taproot.py) can run even when Bitcoin Core is compiled without its built-in…

91586f70by Sebastian Falbesoner+49−142 files
No security note in commit
Open full analysis →Source commit ↗
Informational 17 AI analysisMessage 83 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

scripted-diff: Rename `StatusLevel::{INFO,WARN,ERR}`

This is a straightforward code cleanup change that renames three internal status labels (INFO, WARN, ERR) to different capitalisation (Info, Warn, Error) because one of those names clashed with a system macro on illumos operating systems w…

41ceea40by Hennadii Stepanov+24−242 files
No security note in commit
Open full analysis →Source commit ↗
Informational 12 AI analysisMessage 72 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: cover common HTTP attacks and common malformed requests

This commit only adds new automated tests to Bitcoin Core. It does not change the actual server code that handles HTTP requests. The tests verify that the existing HTTP server correctly rejects or handles common web attacks such as path tr…

Adds regression tests for HTTP security boundary conditionsDocuments libevent leniency on duplicate Content-Length and line foldingNo changes to src/httpserver.cpp or any production HTTP handling code
881d4b6cby Matthew Zipkin+210−121 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 72 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: add extendedkey.py unit tests by using BIP32 test vectors

This commit only adds new unit tests for Bitcoin Core's internal test framework. It checks that a helper class for BIP32 extended keys produces the well-known public test-vector outputs. No production wallet, consensus, or networking code …

d2a03d50by rkrux+36−02 files
No security note in commit
Open full analysis →Source commit ↗
Informational 21 AI analysisMessage 96 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Squashed 'src/secp256k1/' changes from 7262adb4b4..bd0287d650

This commit is a routine subtree update of the secp256k1 cryptographic library inside Bitcoin Core. It pulls in a batch of upstream secp256k1 changes: build-system cleanups, new tests, documentation fixes, a minor MuSig nonce-generation cl…

MuSig secret-key wipe now happens on both success and failure paths in `secp256k1_musig_nonce_gen_counter`New `_ecmult_gen_ge` helper clears Jacobian intermediate state to reduce potential side-channel leakageForce-inlining of performance-critical field operations (mul/sqr) is a hardening/performance change, not a vulnerability fix
1f3f0a4eby fanquake+257−9025 files
No security note in commit
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 78 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

rpc: tighten setmocktime upper bound to UINT32_MAX

This commit tightens the maximum allowed mock time in Bitcoin Core's testing-only RPC command `setmocktime` from the year 2262 down to the year 2106 (the maximum value a 32-bit unsigned timestamp can hold). The change prevents two types of…

Integer overflow (int64_t) in time arithmetic when offsets are added to an overly large mock timeSilent truncation to uint32_t when mocked time is assigned to block header nTime fieldsUBSan/integer sanitizer findings motivating the bound change
406c2348by stringintech+6−63 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Repository ledger

Explore captured commits

Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.

Security candidaterefactor: Make all `const static` class members `constexpr`by rustaceanrob · 05c35c40 · Jul 24, 2026 · 24 filesMessage 100 · StrongInformational 15Details
Commit message · rustaceanrob

refactor: Make all `const static` class members `constexpr`

If a `static class` member is not inlined or `constexpr`, the linker
will fail when attempting to ODR-use the constant (passing as `const
T&`). These can be fixed by finding all member variables that are
`const` qualified and inlining them with `constexpr`. There is a
clang-tidy pull request that would lint these callsites: https://github.com/llvm/llvm-project/pull/162741

A script was used to modify these sites, however it cannot run as a
scripted-diff because it uses clang-query and a build folder.

The script only queries for integer and enumeration types, as other data
members would have to be marked `constexpr` or `inline` from what I
understand: https://en.cppreference.com/cpp/language/static#Constant_static_members

Removing the ZMQ forward declaration was a clang-tidy lint.

The script used to find these sites, LLM assisted:
```
set -uxo pipefail

cd "$(git rev-parse --show-toplevel)"

BUILD=${BUILD:-build}
if [ ! -f "${BUILD}/compile_commands.json" ]; then
echo "error: ${BUILD}/compile_commands.json not found. Run cmake -B ${BUILD} first." >&2
exit 1
fi
if ! command -v clang-query >/dev/null; then
echo "error: clang-query not on PATH. Install clang-tools." >&2
exit 1
fi
if ! git diff --quiet || ! git diff --cached --quiet; then
echo "error: working tree has uncommitted changes. Commit or stash first." >&2
exit 1
fi

MATCHER='match varDecl(hasParent(cxxRecordDecl()),
hasType(qualType(isConstQualified(),
anyOf(hasCanonicalType(isInteger()),
hasDeclaration(enumDecl())))),
hasInitializer(expr()),
unless(isConstexpr()),
isExpansionInFileMatching("/src/"))'

RAW=$(mktemp)
trap 'rm -f "$RAW"' EXIT

echo "Sweeping TUs (batched, may take a few minutes)..." >&2
find src -type d \( -name secp256k1 -o -name leveldb -o -name crc32c \
-o -name minisketch -o -name libmultiprocess -o -name ctaes \) -prune -o \
-name '*.cpp' -print0 \
| xargs -0 -n 50 clang-query -p "${BUILD}" \
-c 'set output diag' \
-c "${MATCHER}" \
>>"$RAW" || true

ROOT=$(pwd)
LOCS=$(grep -oE "${ROOT}/src/[^:]+:[0-9]+:[0-9]+:" "$RAW" \
| sed -E "s|^${ROOT}/||; s|:[0-9]+:$||" \
| sort -u)

if [ -z "$LOCS" ]; then
echo "no matches" >&2
exit 0
fi

FILTERED=""
while IFS=: read -r file line; do
case "$file" in
src/secp256k1/*|src/leveldb/*|src/crc32c/*|src/minisketch/*|src/ipc/libmultiprocess/*|src/crypto/ctaes/*) continue ;;
src/tinyformat.h) continue ;;
esac
src=$(sed -n "${line}p" "$file")
case "$src" in *inline*) continue ;; esac
FILTERED+="${file}:${line}"$'\n'
done <<<"$LOCS"
FILTERED=$(printf '%s' "$FILTERED" | sed '/^$/d')

if [ -z "$FILTERED" ]; then
echo "no matches after filtering" >&2
exit 0
fi

echo "Sites to rewrite ($(echo "$FILTERED" | wc -l)):" >&2
echo "$FILTERED" >&2

declare -A LINES
while IFS=: read -r file line; do
LINES[$file]+="${line} "
done <<<"$FILTERED"

for file in "${!LINES[@]}"; do
args=()
for line in ${LINES[$file]}; do
args+=(-e "${line}s/static const /static constexpr /")
done
sed -i "${args[@]}" "$file"
done

echo >&2
echo "===== proposed diff =====" >&2
git --no-pager diff
```

100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
Why it was queued
cryptography-sensitive pathsigning or wallet path
AI analysis · Informational 15/100

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. There is no functional change to Bitcoin's behavior, no bug fix, and no security-relevant change.

Security candidatescripted-diff: Use long form of shell options in Guix scriptsby Hennadii Stepanov · 2cb3bfa8 · Jul 23, 2026 · 6 filesMessage 83 · StrongInformational 15Details
Commit message · Hennadii Stepanov

scripted-diff: Use long form of shell options in Guix scripts

This improves readability and consistency across all Guix scripts.

-BEGIN VERIFY SCRIPT-

sed -i "s/^set -e\>/set -o errexit/g" \
$( git grep -l "set -e" ./contrib/guix )

-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
signing or wallet pathboot or update path
AI analysis · Informational 15/100

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 immediately if any command fails. There is no security issue and no functional change.

Security candidateguix: Add copyright headers to Guix scriptsby Hennadii Stepanov · 711eb10f · Jul 23, 2026 · 7 filesMessage 45 · ThinInformational 15Details
Commit message · Hennadii Stepanov

guix: Add copyright headers to Guix scripts

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing or wallet pathboot or update path
AI analysis · Informational 15/100

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.

Security candidateSquashed 'src/secp256k1/' changes from bd0287d650..d2d04864efby fanquake · a33f2405 · Jul 23, 2026 · 34 filesMessage 96 · StrongLow 28Details
Commit message · fanquake

Squashed 'src/secp256k1/' changes from bd0287d650..d2d04864ef

d2d04864ef Merge bitcoin-core/secp256k1#1765: Add "silentpayments" module implementing BIP352 (take 4, limited to full-node scanning)
9e4ec507e9 Merge bitcoin-core/secp256k1#1890: nonce: terminate RFC6979 loop at UINT_MAX
afff8cba00 Merge bitcoin-core/secp256k1#1894: extrakeys: check invariant that x-only pubkeys have even Y
b1bc6f3e0c nonce: terminate RFC6979 loop at UINT_MAX
89a54b5aaf extrakeys: check invariant that x-only pubkeys have even Y
cea6d11410 silentpayments: drop "shuffle outputs" recommendation from API docs
1ae90bde8b silentpayments: flush labels before direct match
84a02fa989 silentpayments: extract label batch checker
8c3e6e6d99 Merge bitcoin-core/secp256k1#1889: field: serialize elements by word
11dad6d06c Merge bitcoin-core/secp256k1#1887: Make theStack a maintainer and a security contact
4aa16704ce silentpayments: skip slow benchmarks for low iters count (<= 2)
7e4b313cd5 docs: update README
f27a29687d ci: enable silentpayments module
4f7a578d4b tests: add sha256 tag test
936907b03f tests: add constant time tests
b608a9d91b tests: add BIP-352 test vectors
ca0136dcd5 silentpayments: optimize scanning by using batch inversion
7ae555c524 silentpayments: add benchmarks for scanning
f0fdd99d31 silentpayments: add examples/silentpayments.c
1c1b2753f4 silentpayments: respect per-group recipients protocol limit (K_max=2323)
d72a743273 silentpayments: receiving
c83b6783b8 silentpayments: recipient label support
b30ea3ebe4 silentpayments: sending
a93e696a17 build: add skeleton for new silentpayments (BIP352) module
e217ead5c4 field: serialize elements by word
d5c64bafc7 SECURITY.md: Align the table
9bd50f0cef SECURITY.md: Add theStack's key
ebf594320d Merge bitcoin-core/secp256k1#1884: SECURITY.md: remove Jonas Nick from trusted keys
21645c03a2 SECURITY.md: remove Jonas Nick from trusted keys
b90075a074 Merge bitcoin-core/secp256k1#1882: scalar: correct `_scalar_get_bits_{limb32,var}` input condition docs
5a8a411425 Merge bitcoin-core/secp256k1#1877: field: correct `fe_equal` magnitude bound for `b`
6a599a4428 scalar: correct `_scalar_get_bits_{limb32,var}` input condition docs
994b35010d field: correct fe_equal's b magnitude bound
2ce4f71dc5 Merge bitcoin-core/secp256k1#1845: Improve checks for scalar _get_bits methods
68b45fd4e2 Merge bitcoin-core/secp256k1#1881: tests: Fix GCC 17 snapshot warning
9d75769dec tests: Fix GCC 17 snapshot warning
9e3a165ad0 Merge bitcoin-core/secp256k1#1879: ci: add 'brew trust' invocation to macOS CI
66260b78a2 ci: add 'brew trust' invocation to macOS CI
0cad3df503 Improve checks for scalar _get_bits methods

git-subtree-dir: src/secp256k1
git-subtree-split: d2d04864ef9b056151603a3ced7980958b058028

96/100 · StrongMessage clarity
✓ 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
fuzzing or regression evidenceconstant-time or timing behaviorcryptography-sensitive path
AI analysis · Low 28/100

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 Bitcoin payments. The update also includes several smaller fixes and documentation updates, such as correcting a technical limit in a field-element comparison function, adding a safety check that x-only public keys must have even Y coordinates, and terminating a nonce-generation loop at a fixed maximum iteration count. There is no direct evidence in the commit message or diff that this is an emergency security patch for an active vulnerability; it reads as a routine feature and maintenance subtree update.

Security candidatescripted-diff: Use C.UTF-8 locale in Guix scriptsby Hennadii Stepanov · 8916f796 · Jul 22, 2026 · 15 filesMessage 90 · StrongInformational 15Details
Commit message · Hennadii Stepanov

scripted-diff: Use C.UTF-8 locale in Guix scripts

The C.UTF-8 locale is set by default in `guix shell`, and there is no
reason to avoid it nowadays. This change also silences superfluous
warnings from Qt tools, making build logs cleaner and other issues
easier to spot.

Locales in the `guix-*` launch scripts have been updated as well for
consistency with the rest of the codebase.

-BEGIN VERIFY SCRIPT-

sed -i "s/\<export LC_ALL=C\>/export LC_ALL=C.UTF-8/g" \
$( git grep -l "export LC_ALL=C" ./contrib/guix/* )

-END VERIFY SCRIPT-

90/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
signing or wallet pathboot or update path
AI analysis · Informational 15/100

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 be exploited. The stated purpose is to reduce harmless warning messages from Qt tools during builds.

Security candidatep2p: Assume v2transport for addresses from seedsby Martin Zumsande · cf0f2aea · Jul 21, 2026 · 2 filesMessage 68 · AdequateInformational 19Details
Commit message · Martin Zumsande

p2p: Assume v2transport for addresses from seeds

By now, the vast majority of nodes in the network supports BIP324.
Even if the optimistic guess would turn out to be wrong for a given
node, we would just reconnect with v1.
This is better than making v1 connections with peers when both nodes support v2.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
secret or key materialparser or protocol path
AI analysis · Informational 19/100

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 a network-hardening/performance tweak, not a fix for an exploitable vulnerability.

Security candidatetest: add shared SipHash vectorsby Lőrinc · af50ba85 · Jul 18, 2026 · 7 filesMessage 90 · StrongInformational 15Details
Commit message · Lőrinc

test: add shared SipHash vectors

Lock SipHash-2-4 behavior into shared vectors before refactoring its round and finalization code.
Store inputs as ordered hex byte blocks so `CSipHasher` and the independent Python implementation hash the same byte sequence, with applicable `PresaltedSipHasher` overloads checked against the same vectors.
Add the 64 official SipHash-2-4 vectors alongside block-partition and empty-block cases for the generic path.
Move randomized generic/fixed comparisons to the integer fuzzer.

SipHash-1-3-UJ coverage can add expected outputs for compatible 8- and 32-byte block sequences.
The Python test reads a build-tree copy so functional-test staging behaves consistently when files are symlinked or copied.

Co-authored-by: Pieter Wuille <pieter@wuille.net>

90/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
Why it was queued
fuzzing or regression evidencecryptography-sensitive path
AI analysis · Informational 15/100

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 SipHash implementation behaves correctly and stays correct during future cleanups.

Security candidatetest: compat, ensure downgrade preserves tx witness variantsby furszy · 99bdcb06 · Jul 16, 2026 · 1 fileMessage 72 · AdequateInformational 15Details
Commit message · furszy

test: compat, ensure downgrade preserves tx witness variants

72/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
update trustsigning or wallet path
AI analysis · Informational 15/100

This commit adds a new regression test to Bitcoin Core. It checks that when a wallet created on a newer version is loaded on an older version and then brought back to the newer version, the wallet still remembers alternative 'witness variants' of a transaction. It is purely a test file change and does not modify any production wallet or consensus code.

Security candidatefuzz: clang-format LIMITED_WHILEby MarcoFalke · fab8eeed · Jul 14, 2026 · 65 filesMessage 68 · AdequateInformational 15Details
Commit message · MarcoFalke

fuzz: clang-format LIMITED_WHILE

This is a whitespace-only clang-format change.

To verify it, one can run:

```sh
(git show | git apply --reverse ) && ( git diff -U0 | ./contrib/devtools/clang-format-diff.py -p1 -i -v ) && git diff HEAD
```

A few minor, non-macro formatting adjustments were made in touched files:

* `src/wallet/test/fuzz/crypter.cpp`: Removed a redundant double semicolon
* `src/test/fuzz/txorphan.cpp`: Corrected indentation on an `else if` block.
* `src/test/fuzz/mini_miner.cpp`: Removed an unnecessary empty line.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidencecryptography-sensitive pathsigning or wallet path
AI analysis · Informational 15/100

This commit is purely a code-style cleanup. It adds a space between the macro name LIMITED_WHILE and its opening parenthesis across many fuzz test files, plus a few tiny formatting fixes like removing a redundant semicolon and fixing indentation. No program behavior changes, no security fixes, and no production code is touched.

Security candidatenet_processing: add a global delay queue for sending txsby Anthony Towns · df31ee57 · Jul 11, 2026 · 2 filesMessage 90 · StrongModerate 63Details
Commit message · Anthony Towns

net_processing: add a global delay queue for sending txs

Without the per-peer rate limiting, nodes can act as an amplifier for
transaction spam -- receiving many transactions from one node, but
relaying each of them to over 100 other nodes. Limit the impact of this
by providing a global rate limit.

This is implemented using dual token buckets, one that consumes a
token for every transaction, and one that consumes a token for every
serialized byte. This rate limits both per-tx resource usage (eg INV
messages) and overall relay bandwidth.

Main bucket parameters:
* Count: 14tx/s rate, 420tx (30s) capacity
* Size: 12MB/600s rate (4-6 blocks per target block interval), 50MB capacity

The size bucket is expected to be large enough to almost never have an
impact in normal usage, even during transaction storms, and is primarily
intended to mitigate attack-like scenarios.

Outbound connections get a separate pair of buckets, with rates boosted
by a 2.5x multiplier.

This avoids the excessive memory and CPU usage due to the 100x multiplier
from the queues being per-peer.

Note that this also reduces the size of INV messages we send for general
tx relay back to a more reasonable level of under 600 txs in 99.999%
of cases.

90/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
Why it was queued
explicit security language
AI analysis · Moderate 63/100

This commit adds a global rate limiter to how many transaction announcements (INV messages) a Bitcoin node sends out. Before, each peer had its own queue, so a node could receive one transaction and announce it to over 100 peers, acting like an amplifier for spam and wasting bandwidth and CPU. The new code caps both the number of transactions announced per second and the total bytes announced, with higher limits for outbound peers. It also changes transaction broadcast to use a single shared backlog sorted by mempool quality, rather than per-peer queues. This is a defensive hardening change, not an active vulnerability fix, and the commit message explicitly frames it as mitigating transaction-spam amplification.

Security candidatetest: add regression test for in-memory SQLiteDatabase reopenby Pablo Martin · 777d23f2 · Jul 8, 2026 · 1 fileMessage 100 · StrongInformational 24Details
Commit message · Pablo Martin

test: add regression test for in-memory SQLiteDatabase reopen

InMemoryWalletDatabase::Open() now throws to prevent silently returning
a fresh empty connection after close, which would discard all data. Add a
test to pin this behaviour.

Co-authored-by: Jan B <608446+janb84@users.noreply.github.com>

100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
access controlfuzzing or regression evidencesigning or wallet path
AI analysis · Informational 24/100

This commit only adds a new automated test. It checks that Bitcoin Core's in-memory SQLite wallet database correctly refuses to reopen after being closed, because reopening would silently create a fresh empty database and discard any previous wallet data. The actual protective change (making Open() throw) is already in the codebase; this commit just pins the behavior with a regression test so it cannot accidentally break in the future.

Security candidaterefactor: Use u64 over size_t for all cache sizes to fix a 32-bit overflowby MarcoFalke · fabafd91 · Jul 8, 2026 · 5 filesMessage 100 · StrongLow 43Details
Commit message · MarcoFalke

refactor: Use u64 over size_t for all cache sizes to fix a 32-bit overflow

This is a refactor on 64-bit systems, because size_t is equal to u64.

However, on 32-bit systems, it fixes an integer overflow while calculating the cache sizes:

src/node/caches.cpp:71:49: runtime error: unsigned integer overflow: 471859200 * 10 cannot be represented in type size_t (aka "unsigned int")

This happens while multiplying the default cache size (450MiB) by 10:

index_sizes.tx_index = std::min(total_cache * 10 / 100, ...)
^^^^^^^^^^^^^^^^

The issue was introduced in commit d06dabf26bea7d9ca8d635e8338f64aec74c56a8.

====

Also, add missing includes in touched files, according to IWYU.

100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
Why it was queued
memory safety
AI analysis · Low 43/100

This commit fixes a bug in Bitcoin Core that only affects 32-bit computers. When the program calculated how much database cache to allocate, it multiplied a large default cache value by 10. On 32-bit systems that multiplication overflowed, producing a much smaller or incorrect number. The fix changes the internal type from size_t (32-bit on 32-bit systems) to uint64_t (always 64-bit) so the multiplication stays correct. On normal 64-bit computers the change is harmless and just a cleanup.

Security candidatewallet: Use Descriptor::CanSelfExpand() in CanGetAddresses()by Ava Chow · 1e996640 · Jul 2, 2026 · 1 fileMessage 85 · StrongInformational 23Details
Commit message · Ava Chow

wallet: Use Descriptor::CanSelfExpand() in CanGetAddresses()

If a descriptor does not need any caches or private keys in order to
expand, then CanGetAddresses() should return true for that descriptor.

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 23/100

This is a small Bitcoin Core wallet change that lets the wallet generate addresses from certain descriptors even when it does not have private keys and has already used up its pre-derived address range. It only affects descriptors that can expand entirely on their own (public-only, no cached data needed). The change is more of a correctness/availability fix than a security flaw, and there is no direct evidence in the commit that it fixes a vulnerability.

Security candidatedescriptor: Add CanSelfExpand()by Ava Chow · d2ee9227 · Jul 2, 2026 · 4 filesMessage 58 · ThinInformational 19Details
Commit message · Ava Chow

descriptor: Add CanSelfExpand()

CanSelfExpand() reports whether a descriptor can be expanded without
needing any caches or private keys to be provided by the caller of
Expand().

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
Why it was queued
secret or key materialsigning or wallet path
AI analysis · Informational 19/100

This commit adds a new helper method called CanSelfExpand() to Bitcoin Core's descriptor system. It lets the code ask whether a wallet descriptor can produce its Bitcoin address(es) on its own, without needing a saved cache or private keys. The change is mostly a new capability with matching tests; it does not by itself fix a known bug or change user-facing behavior, but it lays groundwork that could later be used to avoid loading private keys just to display addresses.

Security candidatetest: introduce NodeSigner, run feature_taproot.py without wallet compiledby Sebastian Falbesoner · 91586f70 · Jun 30, 2026 · 2 filesMessage 100 · StrongInformational 15Details
Commit message · Sebastian Falbesoner

test: introduce NodeSigner, run feature_taproot.py without wallet compiled

Introduce a new simple `NodeSigner` wallet replacement that delegates
signing to a specified node via the `signrawtransactionwithkey` RPC,
and plug in that new class to the functional test feature_taproot.py,
so that it can be ran without the Bitcoin Core wallet compiled.

100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100

This commit only changes Bitcoin Core's internal functional test code. It introduces a small test helper class called NodeSigner so that one specific test (feature_taproot.py) can run even when Bitcoin Core is compiled without its built-in wallet. There is no change to production node or wallet code, and nothing in the commit suggests a security bug or fix.

Security candidatescripted-diff: Rename `StatusLevel::{INFO,WARN,ERR}`by Hennadii Stepanov · 41ceea40 · Jun 27, 2026 · 2 filesMessage 83 · StrongInformational 17Details
Commit message · Hennadii Stepanov

scripted-diff: Rename `StatusLevel::{INFO,WARN,ERR}`

The `ERR` macro is defined on illumos-based systems in the `regset.h`
header included by the Boost.Test framework, which may cause a
compilation error.

-BEGIN VERIFY SCRIPT-

ren() { sed -i "s/\<$1\>/$2/g" $( git grep -l "$1" ./src/qt/psbtoperationsdialog.* ) ; }
ren StatusLevel::INFO StatusLevel::Info
ren INFO Info
ren StatusLevel::WARN StatusLevel::Warn
ren WARN Warn
ren StatusLevel::ERR StatusLevel::Error
ren ERR Error

-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
signing boundarysigning or wallet path
AI analysis · Informational 17/100

This is a straightforward code cleanup change that renames three internal status labels (INFO, WARN, ERR) to different capitalisation (Info, Warn, Error) because one of those names clashed with a system macro on illumos operating systems when running tests. It does not change program logic, user-facing behaviour, or security properties. It only prevents a possible build failure on an uncommon platform.

Security candidatetest: cover common HTTP attacks and common malformed requestsby Matthew Zipkin · 881d4b6c · Jun 22, 2026 · 1 fileMessage 72 · AdequateInformational 12Details
Commit message · Matthew Zipkin

test: cover common HTTP attacks and common malformed requests

72/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
explicit security language
AI analysis · Informational 12/100

This commit only adds new automated tests to Bitcoin Core. It does not change the actual server code that handles HTTP requests. The tests verify that the existing HTTP server correctly rejects or handles common web attacks such as path traversal, request smuggling, null bytes, invalid HTTP versions, and malformed authentication headers. Because no production code is modified, the commit itself does not introduce or fix a vulnerability.

Security candidatetest: add extendedkey.py unit tests by using BIP32 test vectorsby rkrux · d2a03d50 · Jun 19, 2026 · 2 filesMessage 72 · AdequateInformational 15Details
Commit message · rkrux

test: add extendedkey.py unit tests by using BIP32 test vectors

72/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
secret or key materialfuzzing or regression evidence
AI analysis · Informational 15/100

This commit only adds new unit tests for Bitcoin Core's internal test framework. It checks that a helper class for BIP32 extended keys produces the well-known public test-vector outputs. No production wallet, consensus, or networking code is changed, and no security bug is being fixed.

Security candidateSquashed 'src/secp256k1/' changes from 7262adb4b4..bd0287d650by fanquake · 1f3f0a4e · Jun 18, 2026 · 25 filesMessage 96 · StrongInformational 21Details
Commit message · fanquake

Squashed 'src/secp256k1/' changes from 7262adb4b4..bd0287d650

bd0287d650 Merge bitcoin-core/secp256k1#1859: field: force-inline 5x52 mul and sqr
fdcf2d41e2 Merge bitcoin-core/secp256k1#1865: test: enable -Wunused-function in test suite (Fix #1831)
b2d2bd362d Merge bitcoin-core/secp256k1#1860: cmake: Emulate Libtool's behavior on NetBSD and OpenBSD
87bec430bf Merge bitcoin-core/secp256k1#1867: test: musig: fix dead "aggnonce encodes two points at infinity" check
71fcd8410e field: force-inline 5x52 mul and sqr
a77dacad9a test: enable -Wunused-function in test suite (Fix #1831)
aea86bc350 Merge bitcoin-core/secp256k1#1864: test: refactor: simplify tests by using `_ecmult_gen_ge` helper, add test
2ee79e77e6 test: add unit test for `_ecmult_gen_ge`
d7125e517d test: musig: fix dead "aggnonce encodes two points at infinity" check
1eab757207 cmake: Fix shared library versioning on OpenBSD
a401c5145a cmake: Fix shared library versioning on NetBSD
8a0f4002c7 cmake, refactor: Improve documenting in `SetLibtoolAbiVersion` module
acf2084aa7 cmake, refactor: Introduce `SetLibtoolAbiVersion` module
0f4a7e6bf9 Merge bitcoin-core/secp256k1#1855: bench: add internal benchmark for `secp256k1_fe_normalize_var`
ca68daf8e1 test: refactor: simplify tests by using `_ecmult_gen_ge` helper
13db747f2b Merge bitcoin-core/secp256k1#1861: refactor: introduce `_ecmult_gen_ge` helper (preventing accidental gej leaks)
9e017e5062 refactor: rename `_ecmult_gen` -> `_ecmult_gen_gej` for consistency
a3296d5e23 refactor: introduce `_ecmult_gen_ge` helper (preventing accidental gej leaks)
c63062380f Merge bitcoin-core/secp256k1#1852: Add exhaustive test for ECDH module
240578eef5 bench: add internal benchmark for `secp256k1_fe_normalize_var`
5698e66c64 Add exhaustive test for ECDH module
a39093de15 Merge bitcoin-core/secp256k1#1851: doc: correct API docs for ECDSA signing out-params (s/array/signature object/)
8363a2d8d1 Merge bitcoin-core/secp256k1#1854: tests: compare full MuSig aggregate nonce
af1fdd1215 tests: compare full MuSig aggregate nonce
40a0d874a6 doc: correct API docs for ECDSA signing out-params (s/array/signature object/)
b11340b3ce Merge bitcoin-core/secp256k1#1849: musig: always clear out secret key in `secp256k1_musig_nonce_gen_counter`
8479eafa57 musig: always clear out secret key in `secp256k1_musig_nonce_gen_counter`
c1a9e4fe64 Merge bitcoin-core/secp256k1#1848: ci: Bump GCC snapshot major version to 17
3cca6451a2 ci: Bump GCC snapshot major version to 17
ea174fe045 Merge bitcoin-core/secp256k1#1846: ci: Replace `ilammy/msvc-dev-cmd` with manual MSVC setup
285cb788e9 ci: Replace `ilammy/msvc-dev-cmd` with manual MSVC setup

git-subtree-dir: src/secp256k1
git-subtree-split: bd0287d650c24dc41e0362675a9f6a49ee952def

96/100 · StrongMessage clarity
✓ 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 boundarycryptography-sensitive path
AI analysis · Informational 21/100

This commit is a routine subtree update of the secp256k1 cryptographic library inside Bitcoin Core. It pulls in a batch of upstream secp256k1 changes: build-system cleanups, new tests, documentation fixes, a minor MuSig nonce-generation cleanup, and a refactor that adds a helper for converting secret-key multiplications into plain (non-Jacobian) curve points. None of the changes appear to fix an exploitable vulnerability in Bitcoin Core itself, and the commit message does not describe any security issue.

Security candidaterpc: tighten setmocktime upper bound to UINT32_MAXby stringintech · 406c2348 · Jun 13, 2026 · 3 filesMessage 78 · AdequateLow 35Details
Commit message · stringintech

rpc: tighten setmocktime upper bound to UINT32_MAX

The previous bound (~year 2262) was too permissive: paths that add an offset to the mocked time (e.g. the future-time check in ContextualCheckBlockHeader) can overflow int64_t (caught by UBSan), and paths that assign it to a uint32_t field (e.g. pblock->nTime in miner.cpp) silently truncate it (caught by the integer sanitizer). UINT32_MAX is the natural ceiling since block header nTime is uint32_t, and mocking beyond it is meaningless for anything consensus-related.

Add setmocktime bound checks to the existing _test_y2106 case in rpc_blockchain.py, and remove the negative bound check from rpc_uptime.py.

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
memory safetydefensive validation
AI analysis · Low 35/100

This commit tightens the maximum allowed mock time in Bitcoin Core's testing-only RPC command `setmocktime` from the year 2262 down to the year 2106 (the maximum value a 32-bit unsigned timestamp can hold). The change prevents two types of bugs that can occur only when a developer or tester manually sets an extremely far-future mock time: signed 64-bit integer overflow in time calculations, and silent truncation when the mocked time is copied into a 32-bit block timestamp field. The command is not available in production nodes and cannot be triggered by ordinary network peers, so this is a low-severity hardening fix for a testing tool.

Security candidaterpc: expand decodepsbt output script with explicit fieldsby satsfy (Renato Britto) · 7a851180 · Jun 13, 2026 · 1 fileMessage 65 · AdequateInformational 15Details
Commit message · satsfy (Renato Britto)

rpc: expand decodepsbt output script with explicit fields

Reuse ScriptPubKeyDoc(), which matches what ScriptToUniv() emits here
wrapped in ElideGroup().

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 · Informational 15/100

This commit is a documentation-only change in the Bitcoin Core RPC help output. It replaces a vague placeholder description for the 'script' field inside decodepsbt with an explicit, structured description reused from another part of the code. There is no code behavior change, no bug fix, and no security relevance.

Security candidatewallet: reject sendtoaddress and sendmany for external signersby Sjors Provoost · 2fe34808 · Jun 11, 2026 · 2 filesMessage 83 · StrongInformational 24Details
Commit message · Sjors Provoost

wallet: reject sendtoaddress and sendmany for external signers

The sendtoaddress and sendmany RPCs always go through SendMoney(), which
expects to sign internally. External signer wallets should use the PSBT
flow instead, via the send RPC.

Return a more specific error for external signer wallets and add
functional test coverage for both RPCs.

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
signing boundarysigning or wallet path
AI analysis · Informational 24/100

This change makes Bitcoin Core refuse two older wallet commands (sendtoaddress and sendmany) when the wallet is controlled by an external signer, such as a hardware wallet. Previously these commands could be called but would fail in a confusing way because they expect to sign transactions internally. Now they return a clear message telling the user to use the newer send command instead. It is a usability and safety improvement, not a fix for an active attack.

Security candidatedoc: replace stale signtransaction wording with current signtx flowby woltx · 4fdd4d8d · Jun 11, 2026 · 2 filesMessage 81 · StrongInformational 15Details
Commit message · woltx

doc: replace stale signtransaction wording with current signtx flow

The protocol documentation still described a "signtransaction" command
driven by sendtoaddress and sendmany. Those RPCs never gained external
signer support: it was effectively precluded by #21201, which was
merged a few days before external signer support landed in #16546, so
the interaction was missed in review (#33112 has a commit making the
rejection explicit). Spending from an external signer wallet uses
send/sendall (and bumpfee for fee-bumping), which invoke the signer
with `<cmd> --stdin` and pass the `signtx` subcommand and PSBT over
stdin.

Update the spending example and the protocol description accordingly,
using `bitcoin rpc` for the example since it enables -named by default.

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 · Informational 15/100

This commit only updates documentation and a code comment to match how external (hardware) signers actually work in current Bitcoin Core. It does not change any executable code, RPC behavior, or security logic. There is no security vulnerability here.

Security candidatefuzz: test non-max descriptor satisfaction weightby woltx · 526aae37 · Jun 10, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · woltx

fuzz: test non-max descriptor satisfaction weight

Also assert that the availability of the satisfaction weight estimate
does not depend on the signature-size assumption, and that assuming
non-max-size signatures never increases the estimate.

83/100 · StrongMessage clarity
✓ 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
signing boundaryfuzzing or regression evidence
AI analysis · Informational 15/100

This commit is a small fuzz-test improvement. It fixes an obvious test bug where the same function was being called twice with the same argument, and instead calls it with both possible arguments, then adds assertions about the results. It does not change any production wallet, consensus, or networking code, and there is no security fix or vulnerability indicated.

Security candidateiwyu: Fix warnings in `src/bench` and treat them as errorby Hennadii Stepanov · 6751a323 · Jun 10, 2026 · 58 filesMessage 50 · ThinInformational 15Details
Commit message · Hennadii Stepanov

iwyu: Fix warnings in `src/bench` and treat them as error

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
cryptography-sensitive pathsigning or wallet path
AI analysis · Informational 15/100

This commit is a code cleanup that adjusts which C++ header files are included in the project's benchmark code and a few related source files. It enables a stricter 'include what you use' (IWYU) check for the benchmark directory so missing or unnecessary #include lines are treated as errors in continuous integration. There is no change to program logic, no bug fix, and no security-relevant behavior.