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 queue199AI 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 Poinsot2244170
Ava Chow1564946064
MarcoFalke4062113074
Lőrinc1772116081
fanquake227199057
Hennadii Stepanov208147063
rkrux5798074
Sjors Provoost8988074
Sebastian Falbesoner3376073
David Gumberg5563072
Pieter Wuille9555066
Hodlinator6654076
Analysis record

Published AI watches

Last scanned 1 minute 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 85 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

refactor: simplify adding SipHash-1-3-UJ

This is a code cleanup (refactor) that moves the internal SipHash mixing steps into shared helper methods. It does not change how Bitcoin hashes data, how many rounds are run, or any user-visible behavior. There is no security bug being fi…

25bfca06by Lőrinc+74−1222 files
No security note in commit
Open full analysis →Source commit ↗
Informational 21 AI analysisMessage 68 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

crypto: add generic SipHash-1-3-UJ

This commit adds a new, weaker variant of the SipHash algorithm inside Bitcoin Core's cryptography module. It is explicitly designed for low-security uses such as internal hash tables, not for protecting funds or network messages. The code…

New weaker cryptographic primitive added (SipHash-1-3 vs. standard SipHash-2-4)Explicit unpadded input design removes length-commitment paddingJumbo 256-bit blocks increase attacker control within a single round
c2d7931bby Pieter Wuille+103−02 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 78 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

bench: add fixed-width SipHash benchmarks

This commit only adds new performance benchmark tests for a hash function called SipHash. It does not change any production code that handles Bitcoin transactions, networking, or wallet data. There is no security issue here.

7ff55cc6by Lőrinc+49−31 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 80 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

crypto: add fixed-width SipHash-1-3-UJ

This commit adds two new shortcut methods for computing a specific SipHash variant on fixed-size inputs. It is a pure performance/ergonomics addition: the new methods copy the hasher's internal state before operating, so they do not alter …

a0ccd4adby Pieter Wuille+21−01 file
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 19 AI analysisMessage 45 · Thin
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

chainparams: delete my DNS seed

A Bitcoin Core developer removed their own DNS seed (seed.bitcoin.sipa.be, run by Pieter Wuille) from the list of hardcoded network seeds that help new Bitcoin nodes find peers when they first start up. This is a routine operational/mainte…

Removal of a trusted bootstrap DNS seed from default chain parametersReduction in peer-discovery redundancy for new mainnet nodesNo vulnerability patch, cryptographic fix, or memory-safety change present
d9080639by Pieter Wuille+1−32 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 95 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: Redeclare variable as signed in `util_tests`

This is a minor fix to a unit test file. A test variable was being assigned a negative value in an unsigned container, which caused a silent underflow and made the test assertion technically incorrect. The patch changes the test to check t…

cd2a4bc5by rustaceanrob+1−21 file
No security note in commit
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 ↗
Repository ledger

Explore captured commits

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

Security candidateHave PSBTInput and PSBTOutput know the PSBT's versionby Ava Chow · 990b084f · Apr 29, 2026 · 4 filesMessage 50 · ThinInformational 18Details
Commit message · Ava Chow

Have PSBTInput and PSBTOutput know the PSBT's version

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 18/100

This commit is a small internal refactor in Bitcoin Core's Partially Signed Bitcoin Transaction (PSBT) handling. It makes each PSBT input and output aware of which PSBT version it belongs to, currently hard-coded to version 0. The change does not fix a known bug or vulnerability by itself; it appears to lay groundwork for future PSBT version support. There is no evidence in the commit or supplied references that this is a security patch.

Security candidatepsbt: Use PSBTInput and PSBTOutput fields instead of accessing global txby Ava Chow · 82c9fe31 · Apr 29, 2026 · 8 filesMessage 73 · AdequateInformational 19Details
Commit message · Ava Chow

psbt: Use PSBTInput and PSBTOutput fields instead of accessing global tx

PSBTInput now has the previous txid and output index, and PSBTOutput has
the amount and script. We no longer need to access the global unsigned
tx for these fields.

Additionally, we can change iterating tx.vin and tx.vout to psbtx.inputs
and psbtx.outputs.

This is in prepration for use with PSBTv2 where the global unsigned tx
will not exist.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 19/100

This commit is a code cleanup in Bitcoin Core's Partially Signed Bitcoin Transaction (PSBT) handling. It changes internal code to read input and output details from the PSBT data structures themselves rather than from the global unsigned transaction. The stated goal is to prepare for a future PSBT version (PSBTv2) where the global unsigned transaction may not exist. There is no direct security fix here, but any inconsistency between the PSBT fields and the global transaction could, in principle, lead to wrong analysis or signing behavior. The patch appears to keep behavior equivalent by using the same data through a different path.

Security candidateAdd PSBTInput::GetOutPointby Ava Chow · 1b7d323a · Apr 29, 2026 · 4 filesMessage 50 · ThinInformational 18Details
Commit message · Ava Chow

Add PSBTInput::GetOutPoint

Helper for getting the PSBTInput COutPoint

50/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides an explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 18/100

This commit is a small code cleanup: it adds a helper function called GetOutPoint to PSBTInput and replaces several direct accesses to transaction input data with calls to that helper. There is no change in behavior or security fix visible in the diff. It appears to be a refactoring to make the code easier to maintain.

Security candidatepsbt: AddInput and AddOutput should take only PSBTInput and PSBTOutputby Ava Chow · 95897507 · Apr 29, 2026 · 4 filesMessage 50 · ThinLow 27Details
Commit message · Ava Chow

psbt: AddInput and AddOutput should take only PSBTInput and PSBTOutput

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 27/100

This commit refactors how inputs and outputs are added to Partially Signed Bitcoin Transactions (PSBTs). Previously, callers had to pass both a raw transaction input/output and a PSBT-specific input/output, which could become inconsistent. Now the functions accept only the PSBT-specific object and derive the raw transaction data from it. For PSBT version 2, the code currently just returns false and does not actually add anything, which appears to be intentional but incomplete support. The change reduces the risk of mismatched data and duplicate inputs, but it is primarily a code-quality and API-safety improvement rather than a fix for an active exploit.

Security candidatepsbt: add tx input and output fields in PSBTInput and PSBTOutputby Ava Chow · 9671aa08 · Apr 29, 2026 · 4 filesMessage 73 · AdequateInformational 19Details
Commit message · Ava Chow

psbt: add tx input and output fields in PSBTInput and PSBTOutput

PSBTInput should be aware of the previous txid, output index, and
sequence numbers for inputs, extracting them from the global
unsigned tx.

PSBTOutput should be aware of the output amount and script, extracting
them from the global unsigned tx.

This prepares for PSBTv2 where these fields are serialized.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 19/100

This commit is a small internal refactor of how Bitcoin Core builds Partially Signed Bitcoin Transactions (PSBTs). It makes each PSBT input and output remember its corresponding transaction details (previous transaction ID, output index, sequence number, amount, and script) directly, instead of only storing them inside the global unsigned transaction. The change prepares the code for a future PSBT version (PSBTv2) where these fields are stored separately. There is no obvious security bug in the diff itself, but it touches serialization and RPC code paths that handle user-provided transaction data.

Security candidatepsbt: make PSBT structs into classesby Ava Chow · 7eacc21f · Apr 29, 2026 · 4 filesMessage 45 · ThinInformational 15Details
Commit message · Ava Chow

psbt: make PSBT structs into classes

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

This commit is a simple code cleanup: it changes three C++ data structures (PSBTInput, PSBTOutput, and PartiallySignedTransaction) from 'struct' to 'class' and adds 'public:' labels so their members remain publicly accessible. It also updates forward declarations in other header files to match. This has no functional or security effect on the Bitcoin Core software.

Security candidategui: Store PSBT in std::optional in PSBTOperationsDialogby Ava Chow · f926c326 · Apr 29, 2026 · 2 filesMessage 77 · AdequateInformational 16Details
Commit message · Ava Chow

gui: Store PSBT in std::optional in PSBTOperationsDialog

Use std::optional to store the PSBT to avoid having a default constructed PSBT

77/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Explains rationale or failure mode
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 16/100

This is a small code-quality change in Bitcoin Core's graphical wallet interface. It switches the internal storage of a partially-signed Bitcoin transaction (PSBT) from a plain object to an optional wrapper, so the code no longer keeps a default/empty PSBT sitting around before one is actually loaded. The change itself does not fix a known crash or vulnerability, but it removes a class of potential bugs where an uninitialized PSBT could accidentally be used.

Security candidatetest: PSBTs should roundtrip through RPCs that do nothingby Ava Chow · 88384180 · Apr 29, 2026 · 1 fileMessage 72 · AdequateInformational 15Details
Commit message · Ava Chow

test: PSBTs should roundtrip through RPCs that do nothing

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

This commit only adds a new automated test to Bitcoin Core. It checks that certain PSBT (Partially Signed Bitcoin Transaction) RPC commands, when called in a way that should make no meaningful change, return the exact same PSBT they were given. There is no change to production code, no bug fix, and no security patch.

Security candidatetest: construct psbt with unknown field programmaticallyby David Gumberg · 00187750 · Apr 29, 2026 · 2 filesMessage 72 · AdequateInformational 15Details
Commit message · David Gumberg

test: construct psbt with unknown field programmatically

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

This commit only changes test code for Bitcoin Core's Partially Signed Bitcoin Transaction (PSBT) handling. It removes one hard-coded test vector from a JSON file and adds a helper function so tests can build PSBTs with made-up unknown fields on the fly. There is no change to production wallet or node code, so it cannot directly affect live funds, network behavior, or introduce a runtime vulnerability.

Security candidatepsbt: Fill hash preimages and taproot builder from SignatureDataby Ava Chow · 0cb884e6 · Apr 29, 2026 · 1 fileMessage 50 · ThinLow 32Details
Commit message · Ava Chow

psbt: Fill hash preimages and taproot builder from SignatureData

Filling these fields was missing.

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 32/100

This commit fixes a gap in Bitcoin Core's Partially Signed Bitcoin Transaction (PSBT) handling. When converting signature data into a PSBT input or output, several pieces of information—hash preimages for certain script operations and the taproot script tree builder—were not being copied over. Missing preimages could prevent a PSBT from being finalized correctly, and missing the taproot builder could prevent proper analysis or signing of taproot outputs. It is a correctness fix in wallet/transaction code rather than a remote-exploitable vulnerability.

Security candidatepsbt: Refactor duplicate key lookup and size checksby Ava Chow · 1e2d146b · Apr 29, 2026 · 2 filesMessage 73 · AdequateInformational 20Details
Commit message · Ava Chow

psbt: Refactor duplicate key lookup and size checks

Every key has a duplicate key lookup check, and many keys have fixed
size checks. These can be refactored to reduce code duplication.

Co-Authored-By: David Gumberg <davidzgumberg@gmail.com>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 20/100

This commit is a code cleanup in Bitcoin Core's Partially Signed Bitcoin Transaction (PSBT) handling. It moves duplicate-key detection and fixed-size checks into shared helpers so the same logic is not repeated dozens of times. The behavior is intended to stay the same; only error messages change in a few test cases. There is no indication this fixes a security bug.

Security candidateDon't pin Python patch versionby Sjors Provoost · 5fefa5a6 · Apr 29, 2026 · 1 fileMessage 78 · AdequateInformational 15Details
Commit message · Sjors Provoost

Don't pin Python patch version

.python-version always matches the minimum supported Python version.
It's main purpose is to catch accidental use of too modern syntax
in scripts and functional tests.

We (currently) don't specify a minimum patch version, so it's not
necessary to do so here. The minor verion is enough.

This also avoids requiring users to keep a potentially unsafe old
patch version installed.

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
access control
AI analysis · Informational 15/100

This commit changes a single configuration file used by developers so it only specifies the broad Python version (3.10) instead of an exact patch release (3.10.14). The stated goal is to avoid forcing developers to keep an old, potentially insecure Python patch release installed. It is a tooling/development hygiene change, not a fix for an exploitable vulnerability in Bitcoin Core itself.

Security candidatemulti_index: fix compilation failure with boost >= 1.91by Cory Fields · 0bc9d354 · Apr 28, 2026 · 3 filesMessage 100 · StrongInformational 15Details
Commit message · Cory Fields

multi_index: fix compilation failure with boost >= 1.91

This effectively reverts a3cb309e7c31853f272bffaa65fb6ab0a7cc4083 from PR #30194.

That PR reduced the multi_index type signatures as recommended upstream, but
this is no longer supported as of boost 1.91 because it is no longer necessary.
1.91 drops support for the pre-c++11 work-arounds that bloated the type
signatures to begin with.

The upstream `BOOST_MULTI_INDEX_ENABLE_MPL_SUPPORT` define is meant to provide
compatibility with removed features, but it does not work for this case. Using
`indexed_by` directly when defining the `multi_index` (as opposed to inheriting
from it) works with all versions, and avoids the use of the back-compat define.

This is a slight regression when building against boost < 1.91 because the
bloated type signatures are reintroduced in that case, but it's not significant
enough to go to the trouble of introducing version detection and ifdefs.

100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundary
AI analysis · Informational 15/100

This commit fixes a build failure that occurs when compiling Bitcoin Core with Boost version 1.91 or newer. It changes how certain in-memory data structures (used for tracking orphan transactions, mempool entries, and transaction requests) are declared so they compile with both old and new Boost versions. There is no runtime behavior change, no vulnerability fix, and no security impact.

Security candidaterefactor: use PSBTFillOptions for filling and signingby Sjors Provoost · dc4a5d12 · Apr 28, 2026 · 20 filesMessage 93 · StrongInformational 15Details
Commit message · Sjors Provoost

refactor: use PSBTFillOptions for filling and signing

Replace the sign, finalize , bip32derivs and sighash_type arguments which
are passed to FillPSBT() and SignPSBTInput() with a PSBTFillOptions struct.

This makes it easier to add additional options later without large code
churn, such as avoid_script_path proposed in #32857. It also makes the
use of default boolean options safer compared to positional arguments
that can easily get mixed up.

93/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
secret or key materialsigning boundarysigning or wallet path
AI analysis · Informational 15/100

This is a straightforward code cleanup (refactor) that bundles several PSBT signing options into a single structure. It does not change what the software does; it only changes how the options are passed around internally. There is no security vulnerability here.

Security candidaterefactor: use SignOptions for MutableTransactionSignatureCreatorby Sjors Provoost · eab72d14 · Apr 28, 2026 · 11 filesMessage 62 · AdequateInformational 15Details
Commit message · Sjors Provoost

refactor: use SignOptions for MutableTransactionSignatureCreator

62/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100

This commit is a straightforward code cleanup: it replaces a raw integer parameter representing the signature hash type with a small structured options object called SignOptions. All call sites are updated to pass the same value inside the new structure. There is no change to what the program actually does, no bug fix, and no security-relevant behavior change.

Security candidatefuzz: mine blocks and send headers for them in cmpctblock harnessby Eugene Siegel · 3c58efe2 · Apr 27, 2026 · 3 filesMessage 95 · StrongInformational 15Details
Commit message · Eugene Siegel

fuzz: mine blocks and send headers for them in cmpctblock harness

The blocks may include mempool and non-mempool transactions. If the
block index was added to, reset the rng, mempool, and chainman. Also
move FinalizeHeader from p2p_headers_presync.cpp to util.h so that
the mining function can use it to create valid headers.

95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
entropy or randomnessfuzzing or regression evidence
AI analysis · Informational 15/100

This commit only changes Bitcoin Core's internal fuzz testing code. It expands a fuzz harness so that the test can mine fake blocks and send headers for them, improving test coverage for compact block processing. There is no change to production network code, wallets, consensus rules, or RPC interfaces, so it does not introduce a security vulnerability in the software users run.

Security candidatefuzz: create and send transactions in cmpctblock harnessby Eugene Siegel · 65162243 · Apr 27, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Eugene Siegel

fuzz: create and send transactions in cmpctblock harness

If the mempool is modified at all (determined by a change in the sequence
counter), reset the rng, mempool, and the chainman for the next iteration.

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

This commit only changes a fuzz test file (src/test/fuzz/cmpctblock.cpp). It makes the compact-block fuzzing harness create and send fake transactions during testing, and resets internal test state if the mempool changes. There is no change to production Bitcoin Core code, network rules, or wallet behavior. It does not fix or introduce a real security vulnerability.

Security candidateFix startup failure with RLIM_INFINITY fd limitsby Sjors Provoost · 4afbabdc · Apr 23, 2026 · 4 filesMessage 78 · AdequateLow 29Details
Commit message · Sjors Provoost

Fix startup failure with RLIM_INFINITY fd limits

When setting the fd limit to unlimited, the node fails to start:

ulimit -n unlimited
build/bin/bitcoind
Error: Not enough file descriptors available. -1 available, 160 required.

This was caused by RaiseFileDescriptorLimit() casting limitFD.rlim_cur
to int, which for RLIM_INFINITY overflows to -1. Fix it by returning
std::numeric_limits<int>::max() instead.

This commit also adds a functional test, which is skipped on environments
with a hard limit below infinity.

Co-authored-by: Luke Dashjr <luke-jr+git@utopios.org>
Co-authored-by: winterrdog

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
memory safety
AI analysis · Low 29/100

This commit fixes a bug where Bitcoin Core would refuse to start if the user's system was configured to allow an unlimited number of open files ('ulimit -n unlimited'). The program incorrectly treated 'unlimited' as -1 available file descriptors, then reported 'Not enough file descriptors available' and exited. The fix makes the program recognize 'unlimited' as the maximum integer value instead, so startup succeeds. This is a reliability/availability fix, not a security vulnerability that an attacker can exploit.

Security candidaterefactor: use _MiB consistently for Mebibyte conversionsby Lőrinc · af0ee28e · Apr 20, 2026 · 36 filesMessage 100 · StrongInformational 20Details
Commit message · Lőrinc

refactor: use _MiB consistently for Mebibyte conversions

Replace hard-coded MiB byte conversions (e.g. `1024*1024`, `1<<20`, `1048576`) with the existing `_MiB` literal to improve readability and avoid repeating constants.
In the few spots where arithmetic involves signed values, the result is identical to the previous code assuming those quantities never turn negative.

Also switch to brace init on every declaration assigned from `_MiB`/`_GiB` literals so a future oversized value (e.g. `unsigned int x{4096_MiB}`) becomes a compile error through the C++11 narrowing check instead of silently truncating.

Extend unit tests to cover the 32-bit `size_t` overflow boundary and to assert equivalence for integer and floating-point conversions.

Co-authored-by: MarcoFalke <*~=`'#}+{/-|&$^_@721217.xyz>
Co-authored-by: w0xlt <94266259+w0xlt@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✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
memory safetyseed or entropy path
AI analysis · Informational 20/100

This is a code cleanup change that replaces scattered hard-coded byte counts like 1024*1024 with a single named helper, _MiB, and adds unit tests for it. It does not change any user-visible behavior or fix a known security bug. The main safety benefit is making future accidental mistakes (for example, writing the wrong number of zeros) less likely and turning some oversized-value mistakes into compile-time errors.

Security candidateutil: add _GiB for Gibibyte conversionsby Lőrinc · b3edd30a · Apr 20, 2026 · 6 filesMessage 83 · StrongInformational 15Details
Commit message · Lőrinc

util: add _GiB for Gibibyte conversions

Introduce `operator""_GiB`, sharing the overflow-checked conversion logic with the existing `operator""_MiB`.

Use `1_GiB` in a few existing places where it is a drop-in replacement (e.g. `1024_MiB`, `1<<30`) and extend unit tests to cover boundary behavior.

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
memory safety
AI analysis · Informational 15/100

This commit adds a new code helper for writing byte sizes in gigabytes (GiB) and replaces a few existing hard-coded numbers with the new helper. It is a code cleanup and readability change with no security-relevant behavior change.

Security candidatenet: cleanup SOCKS5 auth loggingby takeshikurosawaa · b2debc92 · Apr 19, 2026 · 1 fileMessage 73 · AdequateLow 49Details
Commit message · takeshikurosawaa

net: cleanup SOCKS5 auth logging

Do not log SOCKS5 auth credentials.

Keep the log entry for the auth path, but omit the
username and password.

No behavior change intended.

73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
credential or privilege state
AI analysis · Low 49/100

This commit removes a debug log line that printed SOCKS5 proxy usernames and passwords in plain text. The change prevents sensitive credentials from being written to log files, which could otherwise expose them to anyone with access to those logs. It is a straightforward cleanup with clear security benefit, though it only affects debug-level logging.

Security candidatetor: torcontrol disconnect on too many lines to avoid OOMby David Gumberg · 9fe5896a · Apr 17, 2026 · 2 filesMessage 98 · StrongModerate 62Details
Commit message · David Gumberg

tor: torcontrol disconnect on too many lines to avoid OOM

This commit ensures the `TorControlConnection::m_message` buffer doesn't
grow unbounded and exhaust memory, by limiting the number of lines
handled by `TorControlConnection::ProcessBuffer()` to `MAX_LINE_COUNT =
1000`. Now the most memory that can be occupied by `m_message` is on the
order of `MAX_LINE_LENGTH * MAX_LINE_COUNT= 100MB`

Although this is not compliant with the tor control protocol in general,
where commands like `GETINFO ns/all` will likely return thousands of
lines, it is more than sufficient for handling the replies from the
commands that are used by a node:

`AUTHENTICATE`: 1 line:
The server responds with 250 OK on success or 515 Bad
authentication if the authentication cookie is incorrect. Tor closes
the connection on an authentication failure.

https://spec.torproject.org/control-spec/commands.html#authenticate

`GETINFO net/listener/socks`: 2 lines
A quoted, space-separated list of the locations where Tor is
listening...

https://spec.torproject.org/control-spec/commands.html#getinfo

`AUTHCHALLENGE SAFECOOKIE`: 1 line
If the server accepts the command, the server reply format is:

```
"250 AUTHCHALLENGE" SP "SERVERHASH=" ServerHash SP "SERVERNONCE="
ServerNonce CRLF
```

https://spec.torproject.org/control-spec/commands.html#authenticate

`PROTOCOLINFO`: 4-5 lines

The server reply format is:

```
250-PROTOCOLINFO" SP PIVERSION CRLF \*InfoLine "250 OK" CRLF
InfoLine = AuthLine / VersionLine / OtherLine
```

(https://spec.torproject.org/control-spec/commands.html#protocolinfo)

`ADD_ONION`: 2-3 lines for Bitcoin Core's tor control client.

The server reply format is:

```
"250-ServiceID=" ServiceID CRLF
["250-PrivateKey=" KeyType ":" KeyBlob CRLF]
*("250-ClientAuth=" ClientName ":" ClientBlob CRLF)
"250 OK" CRLF
```

...

The server response will only include a private key if the server
was requested to generate a new keypair

...

If client authorization is enabled using the “BasicAuth” flag (which
is v2 only), the service will not be accessible to clients without
valid authorization data (configured with the “HidServAuth” option).
The list of authorized clients is specified with one or more
“ClientAuth” parameters. If “ClientBlob” is not specified for a
client, a new credential will be randomly generated and returned."

https://spec.torproject.org/control-spec/commands.html#add_onion

We don't set the `BasicAuth` flag, so the response will not include any
`ClientAuthLines`.

98/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
secret or key materialaccess controlcredential or privilege state
AI analysis · Moderate 62/100

This change fixes a memory safety issue in Bitcoin Core's connection to the Tor control port. A malicious or misbehaving Tor control server could send an endless stream of reply lines, causing Bitcoin Core to keep allocating memory until the system ran out. The patch caps the number of lines accepted in a single reply at 1,000, after which the connection is closed. The commit message explicitly says this is to avoid out-of-memory (OOM) exhaustion.

Security candidatewallet, bdbro: Enforce overflow data lengthsby Ava Chow · dc3a2b9c · Apr 16, 2026 · 1 fileMessage 73 · AdequateModerate 60Details
Commit message · Ava Chow

wallet, bdbro: Enforce overflow data lengths

The total length of the data in an overflow record is being given to us.
We should validate that the length is reasonable (fits in the total size
of the file), and to stop reading additional data if the amount of data
read exceeds the stated legnth. This prevents infinite looping behavior.

73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
memory safetydefensive validationsigning or wallet path
AI analysis · Moderate 60/100

This patch fixes a bug in Bitcoin Core's wallet migration code that reads old Berkeley DB wallet files. A malformed wallet file could claim an overflow data record was extremely long, causing the software to loop through pages forever. The fix checks that the claimed length fits within the actual file size and stops reading if the collected data exceeds that claimed length. This prevents a denial-of-service via infinite loop when opening a crafted wallet file.

Security candidateSquashed 'src/secp256k1/' changes from 57315a6985..7262adb4b4by fanquake · dfd54c95 · Apr 9, 2026 · 41 filesMessage 96 · StrongLow 34Details
Commit message · fanquake

Squashed 'src/secp256k1/' changes from 57315a6985..7262adb4b4

7262adb4b4 Merge bitcoin-core/secp256k1#1841: gha: Bump deprecated GHA workflow dependencies
c5cd9d6d9a gha: Bump deprecated GHA workflow dependencies
95b702de34 Merge bitcoin-core/secp256k1#1839: ecdsa: VERIFY_CHECK result of _fe_set_b32_limit
634215f3fc Merge bitcoin-core/secp256k1#1837: tests: Fix function pointer initialization C89 error in ellswift tests
43fca0ff55 ecdsa: VERIFY_CHECK result of _fe_set_b32_limit
b84635ed3b tests: Fix C89 function pointer initialization in ellswift tests
ffc25a2731 Merge bitcoin-core/secp256k1#1834: ecmult: Document and test ng=NULL in ecmult
3a403639dc eckey: Call ecmult with NULL instead of zero scalar
7e68c0c88b ecmult: Document and test ng=NULL in ecmult
1aafe15139 Merge bitcoin-core/secp256k1#1777: Make SHA256 compression runtime pluggable
b9cb1cbfd7 Merge bitcoin-core/secp256k1#1824: util: introduce and use `ARRAY_SIZE` macro
4d92a083bc sha256: speed up writes using multi-block compression
0753f8b909 Add API to override SHA256 compression at runtime
fdb6a91a5e Introduce hash context to support pluggable SHA256 compression
c0a2aba088 Merge bitcoin-core/secp256k1#1811: bench: Update help functions in bench and bench_internal
10f546a2c0 Merge bitcoin-core/secp256k1#1832: testrand: Remove testrand_finish
8d0eda07e9 testrand: Remove testrand_finish
95e6815843 Merge bitcoin-core/secp256k1#1825: hash: remove redundant `secp256k1_sha256_initialize` in tagged hash midstate functions
f48b1bfa5d hash: add midstate initializer and use it for tagged hashes
3019186a6d Merge bitcoin-core/secp256k1#1829: ci: Fix leftover use of old ECMULTGENPRECISION
79e9f25237 ci: Fix leftover use of old ECMULTGENPRECISION
dfe042feb2 Merge bitcoin-core/secp256k1#1828: Revert "ci, docker: Fix LLVM repository signature failure"
76e92cfeea Revert "ci, docker: Fix LLVM repository signature failure"
ac561601b8 Merge bitcoin-core/secp256k1#1760: cmake: Add dynamic test discovery to improve parallelism
c7a7f732bd Merge bitcoin-core/secp256k1#1821: ellswift: fix overflow flag handling in secp256k1_ellswift_xdh
921b9711ea util: introduce and use `ARRAY_SIZE` macro
b99a94c382 Add tests for bad scalar inputs in ellswift XDH
307b49f1b9 ellswift: fix overflow flag handling in secp256k1_ellswift_xdh
322d0a4358 Merge bitcoin-core/secp256k1#1823: ci: Load Docker image by ID from builder step
ed02466d3f ci: Load Docker image by ID from builder step
c49c9be504 bench: Update help functions in bench and bench_internal
1d146ac3ed Merge bitcoin-core/secp256k1#1819: tests: Improve secp256k1_scalar_check_overflow tests (Issue #1812)
f47bbc07f0 test: add unit tests for secp256k1_scalar_check_overflow
d071aa56d5 Merge bitcoin-core/secp256k1#1815: refactor: remove unnecessary `malloc` result casts
99ab4a105e Merge bitcoin-core/secp256k1#1817: ci: Disable Docker build summary generation
c5da3bde9c Merge bitcoin-core/secp256k1#1818: ci: Enforce base-10 evaluation
97de5120cf Merge bitcoin-core/secp256k1#1804: test: show both CMake and Autotools usage for ctime_tests
4fb7ccf5d4 ci: Enforce base-10 evaluation
3ae72e7867 ci: Disable Docker build summary generation
97b3c47849 refactor: remove unnecessary `malloc` result casts
1bc74a22f8 test: show both Autotools and CMake usage for ctime_tests
8354618e02 cmake: Set `LABELS` property for tests
29f26ec3cf cmake: Integrate DiscoverTests and normalize test names
f95b263f23 cmake: Add DiscoverTests module
4ac651144b cmake, refactor: Deduplicate test-related code

git-subtree-dir: src/secp256k1
git-subtree-split: 7262adb4b40074201fb30847035a82b8d742f350

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
signing boundarymemory safetycryptography-sensitive path
AI analysis · Low 34/100

This is a routine subtree update that pulls in many upstream libsecp256k1 changes. The most notable user-visible change is a new API that lets callers replace the internal SHA256 compression function with a custom one (for example, a hardware-accelerated version). The update also fixes a small bug in the EllSwift ECDH helper where an all-zero secret key was not always rejected, and it adds several code-quality and test improvements. There is no evidence in the commit message or diff of an undisclosed security vulnerability being patched.

Security candidaterefactor: normalize CCoinsView whitespace and signaturesby Lőrinc · a9f92e34 · Apr 8, 2026 · 4 filesMessage 77 · AdequateInformational 15Details
Commit message · Lőrinc

refactor: normalize CCoinsView whitespace and signatures

Let's get these out of the way to simplify riskier followup commits

77/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body
Why it was queued
signing boundary
AI analysis · Informational 15/100

This commit is purely a code cleanup: it changes spacing and formatting in C++ function signatures (for example, moving the ampersand in `COutPoint &outpoint` to `COutPoint& outpoint` and adjusting line breaks). No program behavior is changed, and there is no security risk.