BC
← All projectsBitcoin Core

Bitcoin Core

The Bitcoin network's reference node and wallet implementation.

BitcoinSupply chainNormal
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 queue133AI analyses
210commits · 30 days
492commits · 60 days
1522commits · 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 Chow1564944064
MarcoFalke406219074
Lőrinc177216081
fanquake227196057
Hennadii Stepanov208143063
rkrux5796074
Sjors Provoost8983074
Sebastian Falbesoner3375073
David Gumberg5563072
Pieter Wuille9551066
Hodlinator6650076
Analysis record

Published AI watches

Last scanned 0 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Informational 15 AI analysisMessage 65 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

rpc: expand decodepsbt output script with explicit fields

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 c…

7a851180by satsfy (Renato Britto)+1−11 file
No security note in commit
Informational 24 AI analysisMessage 83 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

wallet: reject sendtoaddress and sendmany for external signers

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 conf…

Prevents misuse of RPCs that cannot complete signing for external-signer walletsAdds explicit error path instead of relying on downstream failureAdds functional test coverage for the new error behavior
2fe34808by Sjors Provoost+20−12 files
No security note in commit
Informational 15 AI analysisMessage 81 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

doc: replace stale signtransaction wording with current signtx flow

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 vulnera…

4fdd4d8dby woltx+4−52 files
No security note in commit
Informational 15 AI analysisMessage 50 · Thin
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

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

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…

6751a323by Hennadii Stepanov+211−10058 files
No security note in commit
Informational 24 AI analysisMessage 83 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

fuzz: reset the mockable steady clock between iterations

This is a small fix inside Bitcoin Core's internal fuzz-testing harness. Fuzz testing feeds the program many random inputs in sequence; the harness is supposed to reset global state between inputs so each test starts clean. The reset code …

State leakage across fuzz iterationsTest-only global state isolation failureMock clock not reset between test runs
19b32a2eby Hao Xu+1−01 file
No security note in 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 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 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: 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 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 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.

Security candidatefuzz: reset the mockable steady clock between iterationsby Hao Xu · 19b32a2e · Jun 7, 2026 · 1 fileMessage 83 · StrongInformational 24Details
Commit message · Hao Xu

fuzz: reset the mockable steady clock between iterations

CheckGlobalsImpl's constructor runs at the start of every fuzz iteration
and already resets the global RNG flags and the mockable NodeClock via
SetMockTime(0s), but it never reset the mockable steady clock. A value
written to g_mock_steady_time by one input therefore leaked into the
next one. For example, FuzzedSock's constructor calls
SetMockTime(INITIAL_MOCK_TIME) and never clears it, so the mocked steady
time stays set for all subsequent iterations.

Reset MockableSteadyClock symmetrically with NodeClock so each input
starts from an unmocked steady clock. This also brings the steady clock
under the same discipline as the system clock: a target that reads
MockableSteadyClock::now() without first mocking it is now caught by the
existing g_used_system_time check instead of silently reusing a leaked
value.

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
entropy or randomnessfuzzing or regression evidence
AI analysis · Informational 24/100

This is a small fix inside Bitcoin Core's internal fuzz-testing harness. Fuzz testing feeds the program many random inputs in sequence; the harness is supposed to reset global state between inputs so each test starts clean. The reset code already cleared the regular mock clock but forgot to clear a separate 'steady' mock clock. That meant one fuzz input could leave a fake time value behind, polluting later inputs and making fuzz results less reliable. The patch adds one line to clear that steady mock clock too. It is a test-infrastructure bug, not a vulnerability in live Bitcoin node code.

Security candidatemigrate: Handle HD chains that have identical seeds but different IDsby Ava Chow · de92208c · Jun 3, 2026 · 2 filesMessage 78 · AdequateLow 41Details
Commit message · Ava Chow

migrate: Handle HD chains that have identical seeds but different IDs

The seed ID is calculated from a pubkey produced by treating the seed as
a private key. This calculation includes a pubkey compression parameter,
even thought that compression is completely irrelevant for the usage of
the seed as a BIP 32 seed. Thus migration should detect if a seed has
been used multiple times by checking if the computed master key was
already processed.

The spkm_migration fuzzer needs to have it's added descriptors
accounting to be updated for this fix.

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 materialfuzzing or regression evidencesigning or wallet path
AI analysis · Low 41/100

This commit fixes a wallet migration bug in Bitcoin Core. When converting old-style wallets to modern descriptor wallets, the migration code could process the same BIP 32 seed more than once because it identified seeds by a 'seed ID' that changes depending on a technical detail (public-key compression) that does not actually affect the seed's value. The fix now detects duplicate seeds by comparing the derived master extended public key, preventing redundant or conflicting descriptors from being created during migration. There is no direct evidence this is exploitable as an attack; it appears to be a correctness and robustness fix.

Security candidatekey: validate BIP32 seed length in CExtKey::SetSeedby Muhammad · 2cf9d79d · May 28, 2026 · 1 fileMessage 81 · StrongLow 42Details
Commit message · Muhammad

key: validate BIP32 seed length in CExtKey::SetSeed

BIP32 specifies that seed must be between 128 and 512 bits
(16 to 64 bytes). CExtKey::SetSeed currently accepts any length,
including empty seeds, which could lead to weak master keys.

Add an Assert at the start of SetSeed to enforce the valid seed
length range.

Fixes #35308

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
secret or key materialdefensive validation
AI analysis · Low 42/100

This commit adds a safety check to Bitcoin Core's code that creates master cryptographic keys from a seed. The BIP32 standard says seeds must be 16 to 64 bytes long, but the function previously accepted any length, including empty seeds. The fix rejects out-of-range seeds with an internal assertion. It is a hardening change rather than a fix for an active exploit path, because callers in the current codebase already supply valid-length seeds.

Security candidatewallet, test: remove -walletrbf startup option from rpc_psbt.pyby rkrux · a2a2b174 · May 27, 2026 · 3 filesMessage 75 · AdequateInformational 15Details
Commit message · rkrux

wallet, test: remove -walletrbf startup option from rpc_psbt.py

Also, include PSBT_GLOBAL_FALLBACK_LOCKTIME key/value while making the PSBT v2
blank for combinepsbt RPC.

75/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ 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 own test code. It removes the obsolete -walletrbf startup option from two functional tests and adds a missing PSBT v2 field (fallback locktime) to a test helper that creates blank PSBTs. There is no change to production wallet or node code, so it does not affect real users' funds, transactions, or network security.

Security candidatetest: add PSBT proprietary merge regression coverageby w0xlt · da769855 · May 17, 2026 · 2 filesMessage 95 · StrongInformational 15Details
Commit message · w0xlt

test: add PSBT proprietary merge regression coverage

Add unit and functional regression tests asserting that combine/merge preserves proprietary fields at the global, input, and output scopes.

95/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
Why it was queued
signing boundaryfuzzing or regression evidencesigning or wallet path
AI analysis · Informational 15/100

This commit only adds new regression tests for Bitcoin Core's PSBT (Partially Signed Bitcoin Transaction) combine/merge logic. It checks that custom 'proprietary' data fields are preserved when two PSBTs are merged at global, input, and output levels. There is no production code change, no bug fix, and no security patch in the diff itself.

Security candidatepsbt: preserve proprietary fields when combining PSBTsby w0xlt · 3f5b3c7a · May 17, 2026 · 1 fileMessage 85 · StrongLow 28Details
Commit message · w0xlt

psbt: preserve proprietary fields when combining PSBTs

CombinePSBTs currently preserves unknown records but drops proprietary records at the global, input, and output levels because the Merge() paths never union m_proprietary.

Preserve proprietary records in PartiallySignedTransaction::Merge(), PSBTInput::Merge(), and PSBTOutput::Merge() so combine/merge keeps all PSBT key-value data.

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

This commit fixes a bug in Bitcoin Core's handling of PSBTs (Partially Signed Bitcoin Transactions). When two PSBTs were combined, the software correctly kept 'unknown' extra data but accidentally discarded 'proprietary' custom data fields added by wallets or tools. The patch makes sure proprietary fields are preserved during merging, preventing potential loss of transaction metadata that some wallets rely on.