Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.
Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
This 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)
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
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
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
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…
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
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
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
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
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
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.
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
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 …
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…
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
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
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
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
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
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
✓ 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.
✓ 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.
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
✓ 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.
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.
Lower-priorityargsman: Prevent duplicate option registration across categoriesby Pablo Martin · 32df86f1 · Jun 16, 2026 · 1 fileMessage 73 · AdequateLow 35Details
Commit message · Pablo Martin
argsman: Prevent duplicate option registration across categories
Added a validation in AddArg() preventing the same option name from being registered across different categories, avoiding ambiguous option resolution and make the distinction between global and command-specific options explicit.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Low 35/100
This commit adds a safety check in Bitcoin Core's command-line option parser to prevent the same option name from being registered in more than one category. Previously, an option could accidentally be defined twice under different categories, which could lead to confusing or ambiguous behavior when the program tries to decide which definition applies. The change makes the program crash with an assertion failure during startup if such a duplicate is detected, turning a potential silent misconfiguration into an obvious failure.
doc: add release note for submitSolution IPC changes
50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
documentation-only discount
AI analysis · Informational 15/100
This commit only adds a release note describing a previous change to the inter-process communication (IPC) interface for submitting block solutions. It does not change any code, behavior, or configuration. There is no security issue in this documentation-only commit.
AI review queuedmining: add reason and debug output to submitSolutionby w0xlt · cbaa1696 · Jun 16, 2026 · 5 filesMessage 73 · AdequateLow 32Details
Commit message · w0xlt
mining: add reason and debug output to submitSolution
Add reason and debug output parameters to submitSolution, matching submitBlock. This relays the specific failure reason (e.g. "bad-version(...)", "bad-witness-nonce-size", "duplicate") to callers instead of just a bool.
Use a new capnp ordinal for the updated method and keep the old @7 method as a deprecated entry point returning an explicit error, so old clients do not decode corrupt result fields and are directed to update.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
second-pass: broader security terminology
AI analysis · Low 32/100
This commit changes the internal mining interface so that when a miner submits a solved block through the IPC interface, the caller now receives a specific rejection reason (like 'bad-version', 'duplicate', or 'inconclusive') instead of just a true/false answer. It also keeps the old interface method as a deprecated stub that throws an explicit error telling old clients to update, preventing them from misinterpreting new return values. This is a defensive compatibility and observability improvement, not a fix for an active exploit.
Lower-priorityrefactor: centralize SubmitBlock result handlingby w0xlt · ed75d70f · Jun 16, 2026 · 3 filesMessage 80 · StrongInformational 18Details
Commit message · w0xlt
refactor: centralize SubmitBlock result handling
Move the accepted/new-block/reason consistency check into SubmitBlock() so submitBlock() and submitSolution() use the same success criteria.
This keeps duplicate and inconclusive handling in one place, removes the new_block output parameter from the helper, and makes the helper return whether the submitted block was accepted as a new valid block.
80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
AI analysis · Informational 18/100
This is a small internal cleanup in Bitcoin Core's block submission code. It moves a duplicate-check and success-calculation that existed in two places into a single shared helper function. The visible behavior for the mining RPCs is intended to stay the same, and the change is described by the author as a refactor.
Lower-prioritymining: clarify SubmitBlock result handlingby w0xlt · 83f3bc00 · Jun 16, 2026 · 3 filesMessage 80 · StrongInformational 24Details
Commit message · w0xlt
mining: clarify SubmitBlock result handling
Make the submitBlock return value explicit and check that it stays consistent with the BIP22 reason string, so future changes do not return success with a reason or failure without one.
Report "inconclusive" when no specific block rejection reason is available. This covers blocks accepted without being connected, and processing failures where ProcessNewBlock returns false without an invalid BlockChecked result, for example when ActivateBestChain fails after BlockChecked reported a valid block.
Also document why no validation-interface queue drain is needed before unregistering: BlockChecked is emitted synchronously by ProcessNewBlock, unlike most validation signals.
80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI analysis · Informational 24/100
This Bitcoin Core commit tightens how the mining interface reports whether a submitted block succeeded or failed. Previously, a block could be accepted but not connected to the chain (for example, a valid but lower-work 'stale' block), and the result could be ambiguous or inconsistent. The change makes the success/failure logic explicit, adds a safety check that success and a failure reason cannot both be returned, and introduces an 'inconclusive' reason when the node cannot give a clear validation verdict. It also documents that a particular notification is synchronous, so no extra wait step is needed. There is no direct evidence this fixes an exploitable vulnerability; it is primarily a robustness and clarity improvement for mining clients.
Lower-prioritytest: generalise byte_to_base58 utility function to allow more version typesby rkrux · 4dbaa7cc · Jun 16, 2026 · 1 fileMessage 95 · StrongInformational 15Details
Commit message · rkrux
test: generalise byte_to_base58 utility function to allow more version types
Passing a version in the byte form is allowed now in addition to the integral version type. This will be helpful in the next commit.
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 is a small test-only code cleanup. It changes a helper function used only in Bitcoin Core's functional test framework so it can accept a version number either as a single integer or as a sequence of bytes. There is no change to the live Bitcoin network code, no security fix, and no vulnerability.
Lower-prioritytest: descriptor: bare multisig at TOP level with 3 pubkeys is allowedby brunoerg · 55a4c946 · Jun 16, 2026 · 1 fileMessage 72 · AdequateInformational 15Details
Commit message · brunoerg
test: descriptor: bare multisig at TOP level with 3 pubkeys is allowed
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 is a tiny test-only change. It adds one new test case verifying that a specific Bitcoin descriptor pattern—bare multisig with exactly 3 public keys at the top level—is accepted by the descriptor parser. No production code was changed, so it cannot directly affect live Bitcoin Core behavior or introduce a security vulnerability.
`BaseIndex` currently uses the same name for logs, `getindexinfo`, prune locks, and the sync thread. Linux truncates system thread names to 15 visible bytes after the `b-` prefix, so long indexer names are clipped in system tools.
Pass a separate thread name explicitly at each `BaseIndex` call site and shorten the OS-visible indexer names to `txidx`, `blkfltbscidx`, `coinstatsidx`, and `txospenderidx`. Add an `Assume` to `ThreadRename()` so future OS-visible thread names keep fitting the same Linux limit. The public index names, `getindexinfo` keys, command-line options, and on-disk paths stay unchanged.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100
This change shortens the operating-system-visible names of Bitcoin Core's background indexer threads so they aren't cut off in Linux process tools. It does not change user-facing names, file paths, or command-line options, and it introduces no security-relevant behavior.
Lower-priorityutil: zero-pad thread number suffixesby Lőrinc · d69c4629 · Jun 16, 2026 · 3 filesMessage 68 · AdequateInformational 15Details
Commit message · Lőrinc
util: zero-pad thread number suffixes
Thread names with numeric suffixes are easier to scan when the suffixes use a fixed width. Format `ThreadPool` and script-check worker suffixes as two digits while keeping the compact dotted convention.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100
This commit simply changes how some internal Bitcoin Core worker threads are named. Instead of thread names like 'scriptch.1' or 'http.9', they now appear as 'scriptch.01' or 'http.09' with a leading zero. This makes lists of threads easier to read and sort. It does not change any security behavior, fix a bug, or introduce a vulnerability.
ThreadPool workers currently format their names as `name_pool_N`. Linux truncates the system thread name to 15 visible bytes, so `b-http_pool_N` spends much of that space on the suffix. Use a dotted numeric suffix so HTTP worker names become `b-http.N`, leaving more room for longer pool names.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100
This commit simply changes the naming format for background worker threads in Bitcoin Core from 'name_pool_N' to 'name.N'. The only practical effect is to make thread names shorter and easier to read in Linux debugging tools, because Linux limits visible thread names to 15 characters. There is no security issue here.
Lower-prioritytest: make TestChain100Setup's m_clock timestamp more readableby Hao Xu · 58cc2a04 · Jun 15, 2026 · 1 fileMessage 95 · StrongInformational 15Details
Commit message · Hao Xu
test: make TestChain100Setup's m_clock timestamp more readable
The timestamp 1598887952 is used as the initial value of the node's mocked wall-clock in TestChain100Setup. Comment its UTC date to make the magic number more readable.
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 adds a comment next to an existing test-only timestamp to explain what date it represents. It does not change any code behavior and has no security relevance.