CommitWatch RSS
BC
← All projectsBitcoin Core

Bitcoin Core

The Bitcoin network's reference node and wallet implementation.

BitcoinSupply chainNormal
Source repository ↗
Repository coverage

3170 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.

318security candidates668second-pass queue3006AI analyses
148commits · 30 days
328commits · 60 days
1301commits · 180 days
2862commits · 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.

71/100 average clarity
1175Strong · 80–100
1206Adequate · 60–79
701Thin · 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.
merge-script2024588389
Antoine Poinsot22422170
Ava Chow19868191069
MarcoFalke41421408074
fanquake23121228058
Lőrinc18121177081
Hennadii Stepanov22316211064
rkrux57957074
Sjors Provoost89889074
Sebastian Falbesoner33733073
David Gumberg55655072
Pieter Wuille95595066
Analysis record

Published AI watches

Last scanned 57 minutes ago

Low 32 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#34371: wallet: allow importprunedfunds for spending transactions

This change fixes a Bitcoin Core wallet bug where the `importprunedfunds` RPC command could only re-import transactions that sent money to the wallet, not transactions that spent money from it. After this fix, both incoming and outgoing tr…

Logic bug in wallet transaction import scopeIncorrect balance possible after removing and re-importing spending transactionFix routes import through existing involvement check (IsMine + IsFromMe)
ed7dd7cfby Ava Chow+36−203 files
No security note in commit
Open full analysis →Source commit ↗
Low 28 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#29278: Wallet: Add `maxfeerate` wallet startup option

This commit adds a new Bitcoin Core wallet startup option called -maxfeerate. It lets users set a maximum fee rate (fee per unit of transaction size) that the wallet will allow when creating or broadcasting transactions. Previously, the wa…

New wallet startup option -maxfeerate to cap transaction fee rateNew transaction error type MAX_FEE_RATE_EXCEEDEDBroadcastTransaction now checks both max absolute fee and max fee rate
f80aaf4bby Ava Chow+303−7930 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 64 AI analysisMessage 86 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35984: sign: skip signing SIGHASH_SINGLE inputs with no corresponding output

This Bitcoin Core update fixes a wallet-signing quirk. When a user chose the SIGHASH_SINGLE signature mode, an input that had no matching output index would sign essentially nothing meaningful. That signature could then stay valid even if …

Funds-redirection footgun from SIGHASH_SINGLE signatures with no committed outputInconsistent guard between SignTransaction and SignPSBTInput pathsFix centralizes the guard in the low-level signature creator to cover future signing paths
e19f83e9by Ava Chow+37−82 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 86 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35696: i2p: update leaseset encryption types

This change updates Bitcoin Core's I2P (Invisible Internet Project) privacy network settings to use newer, stronger encryption for the published 'leaseset' that describes how other peers can contact a node. The old setting included ElGamal…

Cryptographic algorithm update (ElGamal to MLKEM-768)Use of I2P 'legacy' encryption type removedConfiguration-only change in network privacy layer
65e075f8by Ava Chow+2−21 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 81 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35948: init: correct first-run disk space estimate

This change fixes a labeling bug in Bitcoin Core's first-run disk-space warning. The estimate was stored in GiB (binary gigabytes, 1024-based) but displayed as GB (decimal gigabytes, 1000-based), and for pruned nodes it showed the full-cha…

d26f19c7by Ava Chow+5−42 files
No security note in commit
Open full analysis →Source commit ↗
Low 44 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36284: wallet: don't double discard output groups with avoidpartialspends

This is a wallet bug, not a theft or remote-code bug. When a Bitcoin Core user turns on the optional 'avoidpartialspends' or 'avoid_reuse' setting, an output group rejected during coin selection could be counted twice as 'discarded.' That …

Logic error causing double-counting of discarded UTXO groupsCan trigger false 'insufficient funds' failure in coin selectionAffects avoidpartialspends / avoid_reuse wallets only
e8e7e91aby Ava Chow+43−14 files
No security note in commit
Open full analysis →Source commit ↗
Informational 18 AI analysisMessage 81 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35890: doc: use overwrite (>) instead of append (>>) for one-shot PSBT files in offline-signing-tutorial.md

This is a documentation-only fix in a tutorial file. It changes two shell examples from using '>>' (append to file) to '>' (overwrite file). If a user followed the old instructions and ran the same command twice, the file would contain two…

No security signal: change is limited to documentationNo code changes to Bitcoin Core binaries, RPC, wallet, or consensus logicNo cryptographic, network, or privilege-boundary implications
bfdcd979by merge-script+2−21 file
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35675: mining: add block template manager

This is a large internal code reorganization (refactor) in Bitcoin Core. It creates a new BlockTemplateManager class that takes over block-template creation, block submission, and tip-waiting helpers that were previously spread across seve…

Large refactor touching mining, RPC, interfaces, and test shutdown pathsNew object lifetime dependency: BlockTemplateManager holds references to mempool, chainman, and notifications; explicit reset ordering added in Shutdown/InitAndLoadChainstate/test setupsRemoval of early-init node.mining interface; BlockTemplateManager is now created after chainstate load, with a comment that it must exist before setChainstateLoaded(true) unblocks IPC waiters
5c726f20by Ryan Ofsky+561−44926 files
No security note in commit
Open full analysis →Source commit ↗
Informational 12 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35301: Silent Payments: Implement bip352 (take 2)

This commit adds the first implementation of BIP352 (Silent Payments) to Bitcoin Core. Silent Payments are a new type of privacy-preserving Bitcoin address that lets someone receive payments without publicly revealing a fixed address. The …

New cryptographic feature implementation (BIP352 Silent Payments)Extensive use of secp256k1 silentpayments moduleInput public key extraction from P2PKH, P2WPKH, P2SH-P2WPKH, and P2TR inputs
be5d0b55by Ava Chow+6951−010 files
No security note in commit
Open full analysis →Source commit ↗
Low 45 AI analysisMessage 96 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35440: wallet: check descriptor cache xpub length before decoding

This update fixes a wallet database loading bug where a damaged or tampered Bitcoin wallet file could cause the program to read past the end of a stored extended public key (xpub). The patch makes the loader check the stored xpub length be…

Out-of-bounds read in wallet descriptor cache deserializationASan container-overflow triggered by malformed on-disk recordMissing length validation between record size prefix and fixed-size decoder
b3f846ecby Ava Chow+225−8511 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 20 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35813: wallet, rpc: Add listrawtransactions RPC

This commit adds a new wallet RPC called listrawtransactions to Bitcoin Core. It is a feature addition that lets users list every transaction their wallet knows about, including internal transfers and consolidations that the existing listt…

No security-relevant bug fix or vulnerability patch is present in the diff.New RPC exposes additional wallet transaction metadata, but only to callers already authorized for wallet RPCs.Code is a refactor of existing gettransaction logic into shared helpers; no new cryptographic, network, or consensus code.
2b95b45aby Ava Chow+334−276 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 68 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35752: wallet: make encryption state updates atomic

This Bitcoin Core update fixes several wallet bugs where a failed database write could leave a wallet in an inconsistent state. For example, encrypting a wallet or changing its passphrase could appear to succeed in memory while the change …

Atomicity fix for encryption state and descriptor key persistenceFailure to persist master key during encryption previously reported success in memoryPassphrase change could activate new passphrase only in memory
7ee3d622by Ava Chow+379−16418 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35619: test: ExtendedPrivateKey follow-ups

This commit only changes Bitcoin Core's internal functional test code. It replaces hard-coded test keys and addresses with ones generated from a new test helper class, and unifies how tests tell nodes not to create a default wallet. There …

248ce46fby merge-script+18−244 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36261: test: cover PSBT unknown field merging

This commit only adds a new automated test to Bitcoin Core. It checks that when two partially-signed Bitcoin transactions (PSBTs) are combined, any custom 'unknown' data fields attached to them are preserved correctly. There is no change t…

bbc40edeby merge-script+130−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 18 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36230: wallet: Improve `HasWalletDescriptor` performance and other canonical descriptor string followups

This is a Bitcoin Core wallet maintenance patch. It speeds up a wallet function that checks whether a descriptor already exists by caching a hash of the descriptor's canonical text, instead of rebuilding that text every time. It also tidie…

No security-relevant signal in commit message or diffChange is described as performance improvement and code cleanupBackwards-compatibility test notes a known miniscript wallet loading incompatibility between v31.0/v31.1 and other versions, but this is a documented compatibility quirk, not a vulnerability
4a583f38by merge-script+97−429 files
No security note in commit
Open full analysis →Source commit ↗
Informational 21 AI analysisMessage 81 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36297: rpc: Correct invalid OpenRPC defaults

This is a documentation-only fix for Bitcoin Core's machine-readable RPC help data. It changes several default values from literal strings to 'hint' labels (because the real default depends on context) and corrects one boolean default from…

OpenRPC schema/default mismatch correctionRPC help metadata type correction (string 'false' to boolean false)No executable code path changes
5f05d8c5by merge-script+6−63 files
No security note in commit
Open full analysis →Source commit ↗
Informational 20 AI analysisMessage 68 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

rpc: Correct OpenRPC default metadata

This commit fixes documentation metadata for six Bitcoin Core RPC arguments. It changes how default values are described so that automatically generated API docs and schemas are accurate. The actual behavior of the software when running is…

No runtime code changesOnly RPC help/schema metadata modifiedVendor explicitly states runtime behavior is unchanged
b7f740c5by will+6−63 files
No security note in commit
Open full analysis →Source commit ↗
Informational 24 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36286: crypto: Fix MuHash3072 division by itself

This commit fixes a bug in Bitcoin Core's MuHash3072 cryptographic code where dividing a MuHash object by itself (x /= x) produced the wrong mathematical result. The fix is straightforward: the code now saves the divisor's numerator before…

Cryptographic correctness bug in MuHash3072 division operatorSelf-aliasing in operator/= produces incorrect 1/D result instead of empty setNo production code path identified that triggers self-division
d48e76e6by merge-script+11−13 files
No security note in commit
Open full analysis →Source commit ↗
Informational 18 AI analysisMessage 93 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36285: refactor: Use static const over inline const to work around ld64 bug

This is a build-compatibility fix, not a security patch. It changes how some constant data is stored internally so that Apple's macOS linker (ld64) can build Bitcoin Core correctly. The change avoids a linker bug that caused build failures…

No security-relevant code logic changedChange is a linker bug workaround, not a vulnerability fixConstants remain read-only; no new attack surface introduced
ad97933aby merge-script+8−82 files
No security note in commit
Open full analysis →Source commit ↗
Informational 23 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#34861: wallet: Add importdescriptors interface

This commit refactors Bitcoin Core's wallet descriptor import feature so the same logic can be used by both the RPC command and a new GUI-facing interface. It also tightens one input rule: negative timestamps are now rejected, and the mini…

Refactor of security-sensitive wallet import code into shared CWallet pathNew input validation: negative timestamps rejected for importdescriptorsCentralization of descriptor range bound checks in CheckDescriptorRangeBounds
2bbbeaa6by Ava Chow+619−26415 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.

Lower-prioritytest: introduce ExtendedPrivateKey and ExtendedPublicKey classesby rkrux · afdb3780 · Jun 19, 2026 · 1 fileMessage 100 · StrongInformational 15Details
Commit message · rkrux

test: introduce ExtendedPrivateKey and ExtendedPublicKey classes

Using these classes allows the developers to dynamically create
xprvs and xpubs so that they don't need to hardcode such long keys
in the tests that most of the times clutter the tests and make them
difficult to update.

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✓ Explains rationale or failure mode✓ Mentions testing or verification
AI analysis · Informational 15/100

This commit adds a new test-only helper file that implements BIP32-style extended private and public keys for Bitcoin Core's functional test framework. It is purely test infrastructure code and does not change any production wallet, consensus, or networking logic. There is no security-relevant change to the Bitcoin Core software that users run.

Lower-prioritytest: p2p: Nodes ignore unsolicited CMPCTBLOCK'sby David Gumberg · e845e263 · Jun 18, 2026 · 1 fileMessage 67 · AdequateInformational 15Details
Commit message · David Gumberg

test: p2p: Nodes ignore unsolicited CMPCTBLOCK's

67/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
AI analysis · Informational 15/100

This commit only adds a new functional test to Bitcoin Core. It verifies that nodes ignore unsolicited compact block (CMPCTBLOCK) messages from peers that are not in high-bandwidth mode, while still accepting them from high-bandwidth peers or when explicitly requested. There is no change to production code, so it cannot directly introduce or fix a runtime security vulnerability.

Lower-prioritytest: (Un)solicited invalid cb -> get disconnected.by David Gumberg · 92cea63c · Jun 18, 2026 · 1 fileMessage 95 · StrongInformational 12Details
Commit message · David Gumberg

test: (Un)solicited invalid cb -> get disconnected.

Modifies the invalid_cmpctblock_message test to check that both HB peers
sending unsolicited and non-HB peers sending solicited invalid
cmpctblock's get the boot from us. Also refactors the test to make it
less stateful.

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
AI analysis · Informational 12/100

This commit only changes a test file. It expands an existing test to verify that Bitcoin Core correctly disconnects peers that send badly formed compact block messages, whether those peers are high-bandwidth or low-bandwidth. It does not change any production code, so it cannot directly introduce or fix a live security vulnerability.

Lower-priorityp2p: Ignore CMPCTBLOCK from peer that hasn't sent SENDCMPCTby David Gumberg · 9c5dd292 · Jun 18, 2026 · 4 filesMessage 83 · StrongLow 47Details
Commit message · David Gumberg

p2p: Ignore CMPCTBLOCK from peer that hasn't sent SENDCMPCT

This commit also changes the default sendcmpct version in the functional
test to `2`, since this is the version that nodes expect, prior to this
commit, nowhere in the functional test framework was the default version
value used:

git grep -P 'msg_sendcmpct\((?![^)]*version\s*=)' HEAD^

`version=2` is a sensible default, since this is the version nodes
currently expect in the SENDCMPCT handshake.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Low 47/100

This Bitcoin Core update tightens the rules for compact block messages. Before the change, a peer could send a compressed block (CMPCTBLOCK) even if it had never advertised support for compact blocks via the SENDCMPCT handshake. The fix makes the node ignore such unexpected CMPCTBLOCK messages. The commit also updates the test framework so that simulated peers use the current compact-block version 2 by default. This is a hardening change that reduces the attack surface for malformed or unexpected compact-block traffic, but the commit message does not describe it as a security fix and no exploit is demonstrated.

Lower-prioritytest: Tighten getblocktxn checks in parallel cb reconstruction test.by David Gumberg · 25457a32 · Jun 18, 2026 · 1 fileMessage 95 · StrongInformational 14Details
Commit message · David Gumberg

test: Tighten getblocktxn checks in parallel cb reconstruction test.

Clear the getblocktxn message so we're not checking existing messages,
and check that the hash in the getblocktxn match the cmpctblock being
announced.

Without this tightening of checks, a later commit that ignores
CMPCTBLOCK messages that are unsolicited will succeed these tests while
silently failing in reality.

Co-authored-by: Hodlinator <172445034+hodlinator@users.noreply.github.com>

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
AI analysis · Informational 14/100

This commit only changes a Bitcoin Core functional test file. It tightens the checks in a test that verifies how nodes request missing transactions from compact blocks. There is no change to the actual Bitcoin node software, so it cannot directly affect live network behavior or user funds. It is a test-quality improvement that makes future changes to the real code harder to pass by accident if they silently break compact-block behavior.

Lower-priorityp2p: Drop unsolicited CMPCTBLOCK from non-HB peerby David Gumberg · 83135917 · Jun 18, 2026 · 3 filesMessage 88 · StrongModerate 58Details
Commit message · David Gumberg

p2p: Drop unsolicited CMPCTBLOCK from non-HB peer

Processing unsolicited CMPCTBLOCK's from a peer that has not been marked
high bandwidth is not well-specified behavior in BIP-0152, in fact the
BIP seems to imply that it is not permitted:

"[...] method is not useful for compact blocks because `cmpctblock`
blocks can be sent unsolicitedly in high-bandwidth mode"

See https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#separate-version-for-segregated-witness

This partially mitigates a mempool leak described in
[#28272](https://github.com/bitcoin/bitcoin/issues/28272), but that
particular issue will persist for peers that have been selected as high
bandwidth.

This also mitigates potential DoS / bandwidth-wasting / abusive
behavior that is discussed in the comments of #28272.

88/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
AI analysis · Moderate 58/100

This Bitcoin Core change tightens the rules for a fast block-relay feature called compact blocks (BIP 152). Previously, any peer could send a compact block announcement without being asked. Now, if a peer sends one without being marked as a 'high-bandwidth' peer and without the node having requested the block from them, the message is ignored. The commit says this partly closes a known mempool information leak and reduces the risk of bandwidth-wasting abuse, but it is only a partial fix because high-bandwidth peers can still send unsolicited compact blocks.

Lower-priorityp2p: make blocksonly nodes ignore CMPCTBLOCK messagesby David Gumberg · bf9884f4 · Jun 18, 2026 · 2 filesMessage 81 · StrongModerate 60Details
Commit message · David Gumberg

p2p: make blocksonly nodes ignore CMPCTBLOCK messages

blocksonly nodes don't benefit from compact blocks, since they don't
have a mempool to aid in reconstruction, so they should not process
CMPCTBLOCK messages.

This is not just belt-and-suspenders, as a blocksonly node will
trivially reveal exactly which transactions in a block are its own in
the GETBLOCKTXN response to a CMPCTBLOCK. Since it will be missing every
transaction in the block, except for its own.

See discussion: https://github.com/bitcoin/bitcoin/issues/28272

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
AI analysis · Moderate 60/100

This change fixes a privacy leak in Bitcoin Core's 'blocksonly' mode. Blocksonly nodes intentionally avoid keeping a mempool of unconfirmed transactions. Previously, they would still try to process compact block (CMPCTBLOCK) messages from peers. Because they lack a mempool, they would be missing almost every transaction referenced in a compact block—except for transactions they themselves created. When responding to ask for the missing transactions, the node would reveal exactly which transactions were its own, linking those transactions to that node's IP address. The fix makes blocksonly nodes simply ignore incoming compact block messages, so they never send those revealing responses. The commit message explicitly calls this out as a real privacy issue, not just a defensive cleanup.

Lower-priorityqa: Avoid UTXO reuse between test functionsby Hodlinator · 55e3a57f · Jun 18, 2026 · 1 fileMessage 55 · ThinInformational 15Details
Commit message · Hodlinator

qa: Avoid UTXO reuse between test functions

55/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Mentions testing or verification! No meaningful explanatory body
AI analysis · Informational 15/100

This is a minor fix inside Bitcoin Core's own test suite. It changes how test UTXOs are consumed so that different test functions don't accidentally reuse the same fake coin. It does not affect the live Bitcoin network, wallets, or node software.

Lower-priorityrefactor: test: Static assert_highbandwidth_statesby David Gumberg · 44f377a7 · Jun 18, 2026 · 1 fileMessage 77 · AdequateInformational 15Details
Commit message · David Gumberg

refactor: test: Static assert_highbandwidth_states

This is move-only, and allows assert_highbandwidth_states to be used by
other tests.

77/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Uses a recognizable type or scope✓ Provides an explanatory body✓ Mentions testing or verification
AI analysis · Informational 15/100

This commit is a minor code cleanup in Bitcoin Core's test suite. It moves a small helper function from inside one test method to the class level so other tests can reuse it. There is no change to the actual Bitcoin network code, no change to how nodes communicate, and no security issue.

Lower-prioritydepends: latest config.guess & config.subby fanquake · 8f035499 · Jun 18, 2026 · 2 filesMessage 45 · ThinInformational 15Details
Commit message · fanquake

depends: latest config.guess & config.sub

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Informational 15/100

This commit updates two helper scripts used during Bitcoin Core's build process to the latest versions from the GNU project. These scripts only detect what kind of computer and operating system is being used so the build can choose the right settings. The changes add support for newer or less common platforms (Ironclad, mlibc, sw_64) and update copyright years. There is nothing here that changes how Bitcoin handles money, network messages, wallets, or cryptography.

Lower-prioritylint: Require scripted-diff script to succeedby MarcoFalke · fab28742 · Jun 18, 2026 · 1 fileMessage 45 · ThinInformational 18Details
Commit message · MarcoFalke

lint: Require scripted-diff script to succeed

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Informational 18/100

This commit tightens a Bitcoin Core lint check that verifies 'scripted-diff' commits. Previously, the shell command running the script could silently ignore failures due to a fragile chain of '&&' and '||' operators. The fix makes the script explicitly fail if the scripted diff does not apply cleanly or leaves unexpected changes. It is a hardening improvement in developer tooling, not a fix for an active vulnerability in the Bitcoin software itself.

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.

Lower-priorityscripted-diff: Rename SteadyClockContext to FakeSteadyClockby Hao Xu · 855a3fee · Jun 18, 2026 · 5 filesMessage 83 · StrongInformational 15Details
Commit message · Hao Xu

scripted-diff: Rename SteadyClockContext to FakeSteadyClock

SteadyClockContext and FakeNodeClock are both LimitOne RAII helpers that mock a
clock in tests -- the steady clock and the node clock, respectively. Rename the
former so the two follow a consistent FakeXClock naming scheme.

-BEGIN VERIFY SCRIPT-
sed -i 's/SteadyClockContext/FakeSteadyClock/g' $(git grep -l SteadyClockContext)
-END VERIFY SCRIPT-

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 15/100

This commit is a simple automated rename of a test-only helper class from SteadyClockContext to FakeSteadyClock. It only changes names in comments and test/fuzz code to make naming consistent. There is no functional change and no security impact.

Lower-prioritytest: announce field must be 0 or 1 in sendcmpctby brunoerg · abc33ff0 · Jun 17, 2026 · 1 fileMessage 67 · AdequateInformational 23Details
Commit message · brunoerg

test: announce field must be 0 or 1 in sendcmpct

67/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
AI analysis · Informational 23/100

This commit adds a new test to Bitcoin Core's functional test suite. The test verifies that if a peer sends a 'sendcmpct' message with an invalid 'announce' value (anything other than 0 or 1), the node logs an error and disconnects that peer. This is a test-only change; it does not modify the actual network handling code. It confirms existing behavior required by BIP152, the compact blocks standard.

Lower-prioritytest: Add missing test case for getdata requests from blocks-only peersby Roqqit · 278710a8 · Jun 17, 2026 · 1 fileMessage 72 · AdequateInformational 15Details
Commit message · Roqqit

test: Add missing test case for getdata requests from blocks-only peers

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

This commit only adds a new test case to Bitcoin Core's test suite. It verifies that a block-relay-only peer cannot request transaction data via getdata messages. There is no change to production code, no bug fix, and no security patch.

Lower-prioritynet_processing: fix BIP152 first integer interpretationby brunoerg · 2d0dce0a · Jun 17, 2026 · 1 fileMessage 50 · ThinLow 47Details
Commit message · brunoerg

net_processing: fix BIP152 first integer interpretation

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Low 47/100

This change tightens how Bitcoin Core handles a compact-blocks handshake message. The old code read a small number from the network and treated any non-zero value as 'true'; the new code rejects values other than 0 or 1. This prevents a peer from sending malformed values that could, in theory, be misinterpreted by downstream logic and cause inconsistent state between nodes.

Lower-priorityargsman: allow duplicate registration between HIDDEN and other categoriesby Pablo Martin · f963f2b6 · Jun 17, 2026 · 1 fileMessage 93 · StrongLow 26Details
Commit message · Pablo Martin

argsman: allow duplicate registration between HIDDEN and other categories

The assertion added in #35470 to prevent duplicate option registration
across categories was too strict — it also fired when an option was
registered in OptionsCategory::HIDDEN and then again in a real category
(or vice versa).

This is intentional behavior introduced in #13441: options unavailable
in a given binary (e.g. GUI args in bitcoind) are pre-registered as
hidden so shared bitcoin.conf files don't fail. In bitcoin-qt,
SetupServerArgs registers GUI args as hidden, then SetupUIArgs registers
them properly under OptionsCategory::GUI, triggering the assertion and
crashing on startup.

The fix relaxes the assertion to exclude HIDDEN from the cross-category
duplicate check, preserving the original intent of #13441 while still
catching unintentional duplicates between real categories.

93/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
AI analysis · Low 26/100

This commit fixes a bug where Bitcoin Core's graphical wallet (bitcoin-qt) would crash immediately on startup. The crash was caused by an overly strict internal safety check that treated a normal, intentional code pattern as a duplicate-setting error. The fix narrows the check so it ignores entries marked as 'hidden' (used for settings that don't apply to a particular program version), restoring normal startup. There is no indication this bug could be exploited by an attacker.

Lower-priorityutil: Check write failures before renaming settings.jsonby Shrey · 0654511e · Jun 17, 2026 · 3 filesMessage 91 · StrongLow 43Details
Commit message · Shrey

util: Check write failures before renaming settings.json

In WriteSettings(), verify that writing to the stream and closing it
succeeded before returning true. This prevents RenameOver() from replacing
a valid settings.json with a corrupted or zero-byte file when write limits
or a full disk are encountered.

Additionally, update the ReadSettings() parse failure message to mention
power loss, full disk, or storage error as possible causes.

Fixes #35373

91/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
AI analysis · Low 43/100

This commit fixes a bug in how Bitcoin Core saves its settings file. Previously, if the disk was full or a write failed, the program could replace the user's valid settings file with an empty or corrupted one. Now it checks that the new file was written successfully before overwriting the old one. It also updates an error message to mention power loss, full disk, or storage errors as possible causes of a damaged settings file. This is a reliability and data-loss fix, not an attack that a remote hacker can exploit.

Lower-priorityci: updated docs to reflect removal of REPO_USE_WARP_RUNNERS flagby Max Edwards · 744d4950 · Jun 17, 2026 · 1 fileMessage 62 · AdequateInformational 15Details
Commit message · Max Edwards

ci: updated docs to reflect removal of REPO_USE_WARP_RUNNERS flag

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
documentation-only discount
AI analysis · Informational 15/100

This is a one-line documentation update in the CI README. It simply updates instructions for how to use third-party WarpBuild runners in a fork after a configuration variable was removed. There is no code change and no security relevance.

Lower-prioritytest: add fuzz test for private broadcastby kevkevinpal · 2ee4fafa · Jun 17, 2026 · 3 filesMessage 82 · StrongInformational 15Details
Commit message · kevkevinpal

test: add fuzz test for private broadcast

Co-authored-by: Greg Sanders <gsanders87@gmail.com>
Co-authored-by: Vasil Dimov <vd@FreeBSD.org>

82/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 15/100

This commit only adds a new automated fuzz test for an existing Bitcoin Core feature called private transaction broadcast. It does not change any production code that runs on the network, so it cannot by itself introduce a security vulnerability or fix one. It is purely extra test coverage.

Lower-priorityprivate broadcast: enforce sending to unique node idsby Vasil Dimov · 08b7c61f · Jun 17, 2026 · 2 filesMessage 73 · AdequateLow 47Details
Commit message · Vasil Dimov

private broadcast: enforce sending to unique node ids

Sending more than one transaction to a given node would be a privacy
leak and thus enforce that this is not done. `GetSendStatusByNode()`
assumes unique node ids.

Note that sending more than one transaction to a given address is fine,
if that is done via separate connections, in which case the node ids
would be different.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Low 47/100

This change adds a safety check inside Bitcoin Core's private transaction-broadcast feature. It prevents the same node from being chosen more than once to receive different transactions, because doing so could let that node figure out which transactions belong to the same wallet. The patch uses an internal assumption check and returns nothing if a duplicate node is about to be reused.

Lower-prioritylint: Require scripted-diff script to succeedby Hodlinator · 2a36d6a5 · Jun 17, 2026 · 1 fileMessage 78 · AdequateInformational 21Details
Commit message · Hodlinator

lint: Require scripted-diff script to succeed

Previous version of commit-script-check.sh would succeed as long as git diff succeeded.

Can be verified through adding a failing scripted diff commit such as:
git commit --allow-empty -m $'scripted-diff: foo\n\n-BEGIN VERIFY SCRIPT-\nadsasd\n-END VERIFY SCRIPT-\n'
...and running...
cargo run --manifest-path ./test/lint/test_runner/Cargo.toml -- --lint=scripted_diff

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 21/100

This is a small fix to a developer linting tool that checks whether automated 'scripted-diff' commits actually run their embedded scripts. Previously, if the script itself failed, the check could still report success because the success/failure logic depended only on whether the git diff command succeeded. The patch makes the script's own exit status required for the overall check to pass. This is a tooling bug, not a vulnerability in Bitcoin Core's network or wallet code.

Lower-prioritytest: SOCKS5 proxy: expect that connection may be reset during handshakeby Vasil Dimov · 9a8ef9b0 · Jun 17, 2026 · 1 fileMessage 95 · StrongInformational 15Details
Commit message · Vasil Dimov

test: SOCKS5 proxy: expect that connection may be reset during handshake

The client (e.g. `bitcoind`) may open a connection to the proxy and
close it in the middle of the SOCKS5 handshake if it is restarted for
example. Log these as debug messages instead of full blown Python
exception error messages with backtraces.

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

This commit only changes a test helper script used during Bitcoin Core's automated testing. It makes the built-in SOCKS5 test proxy log expected connection resets as debug messages instead of printing full error backtraces. There is no change to the actual Bitcoin node software, no fix for a real vulnerability, and no security impact on users running Bitcoin Core.

Lower-prioritytest: SOCKS5 proxy: expect that connection may be reset when forwardingby Vasil Dimov · eb320836 · Jun 17, 2026 · 2 filesMessage 95 · StrongInformational 15Details
Commit message · Vasil Dimov

test: SOCKS5 proxy: expect that connection may be reset when forwarding

The `forward_sockets()` function used by the SOCKS5 proxy forwards data
between two connected sockets. It might happen that one of those sockets
gets closed/reset abruptly, without sending EOF first. This is to be
expected if e.g. `bitcoind` is shutdown and shouldn't result in noisy
harmless messages like:

```
2026-06-03T13:23:56.966859Z TestFramework.socks5 (ERROR): socks5 request handling failed (running True)
Traceback (most recent call last):
File ".../socks5.py", line 199, in handle
forward_sockets(self.conn, conn_to, self.wakeup_socket_pair[1], self.serv)
~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File ".../socks5.py", line 76, in forward_sockets
data = s.recv(4096)
ConnectionResetError: [Errno 104] Connection reset by peer
```

Instead turn this into a debug log message with a nice prefix containing
enough information to identify the two forwarded sockets.

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

This commit only changes Bitcoin Core's internal test framework. It makes the SOCKS5 proxy helper used in tests quieter when a test socket is closed unexpectedly, turning an ERROR log into a DEBUG log. There is no change to production Bitcoin node code and no security impact.

Lower-priorityci: Use GCC consistently in i686 taskby MarcoFalke · fae482b4 · Jun 16, 2026 · 1 fileMessage 92 · StrongInformational 15Details
Commit message · MarcoFalke

ci: Use GCC consistently in i686 task

According to the comment removed in commit
fae0295a799499268caca9c385ac4d7061543980, clang was only used to avoid
OOM. Using GCC today should be fine.

92/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI analysis · Informational 15/100

This commit changes a Bitcoin Core continuous integration (CI) test script to use the GCC compiler instead of Clang for a 32-bit Intel (i686) build. It removes the Clang/LLVM packages and compiler flags from the CI environment. There is no change to the actual Bitcoin Core software that users run, and nothing in the commit suggests a security issue.