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 makes three Bitcoin command-line tools (bitcoin-tx, bitcoin-util, and bitcoin-wallet) automatically pick the fastest SHA-256 hashing implementation available on the computer, such as hardware-accelerated versions on modern CPUs…
This is a one-line fix in Bitcoin Core's network code. It changes how the size of a list of block headers is converted to a signed integer inside a loop. Previously, if the list was empty, the conversion could trigger undefined-behavior wa…
UndefinedBehaviorSanitizer integer sanitizer warning addressedImplicit signed/unsigned conversion in loop counterUnsigned integer wraparound on empty vector size
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
✓ 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 release notes describing a previously merged change. It does not modify any executable code, network behavior, or RPC logic. There is no security issue in this documentation-only commit.
This key has been marked deprecated since v29, it can be removed from the RPC response now unless the user requests it via the -deprecatedrpc=bip125 node argument.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 20/100
This commit removes a long-deprecated 'bip125-replaceable' field from several Bitcoin mempool-related RPC responses by default. Users can still get the old field back by starting their node with -deprecatedrpc=bip125. It is a routine API cleanup, not a security fix.
rpc, mempool: rpcdeprecate `fullrbf` key in getmempoolinfo RPC response
mempoolfullrbf=1 behaviour has been the default since v28 and the argument has been removed since v29 subsequently. The getmempoolinfo RPC need not return the deprecated `fullrbf` key in the response anymore unless the user requests it via -deprecatedrpc=fullrbf node argument.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100
This change removes a now-obsolete 'fullrbf' field from the getmempoolinfo RPC response by default, while still allowing it to appear if the user explicitly requests legacy behavior with -deprecatedrpc=fullrbf. It is a routine cleanup of a deprecated API field and does not fix or introduce any security vulnerability.
Lower-prioritybench: make `setup()` use single-iteration epochsby Lőrinc · e6430b27 · Apr 23, 2026 · 7 filesMessage 68 · AdequateInformational 15Details
Commit message · Lőrinc
bench: make `setup()` use single-iteration epochs
`setup()` in nanobench runs once per epoch, not once per timed call. If an epoch executes the benchmark body multiple times, `setup()` can silently leave later iterations with different preconditions.
Make `setup()` force `epochIterations(1)` itself: keep rejecting incompatible larger explicit epoch sizes, but allow existing single-iteration callers such as `-sanity-check`.
With `setup()` handling this centrally, remove the redundant `epochIterations(1)` calls from the benchmarks that use it.
Co-authored-by: David Gumberg <davidzgumberg@gmail.com>
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100
This commit fixes a correctness issue in Bitcoin Core's internal benchmarking tool. Previously, benchmark setup code could run once per batch of repeated measurements, meaning later repeats might not start from a clean state. The change forces setup to run before every single measurement. This only affects benchmark tests, not the live Bitcoin network software, so it has no direct security impact on users.
`MempoolCheckEphemeralSpends` wrote every prevout to `tx2.vin[0]` instead of `tx2.vin[i]`. That left only one child input pointing at the parent transaction, while the remaining inputs kept default prevouts.
Write each prevout to `vin[i]` instead. Add an assertion that the last child input spends the last parent output.
Co-authored-by: David Gumberg <davidzgumberg@gmail.com>
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 16/100
This commit fixes a bug in a Bitcoin Core benchmark test, not in the live network code. The benchmark was supposed to create a test transaction with multiple inputs spending outputs from a parent transaction, but due to a typo it kept writing all the input details to the first input slot only. The remaining inputs were left empty/default. The fix writes each input to its correct slot and adds a sanity check. It does not affect real Bitcoin transactions, wallets, or consensus rules.
`WalletBalanceMine` duplicated `WalletBalanceClean` exactly. Remove the duplicate registration so the balance benchmark list stays distinct.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit removes a duplicate benchmark test in Bitcoin Core. The 'WalletBalanceMine' benchmark was identical to 'WalletBalanceClean', so registering it twice served no purpose. This change only affects internal performance testing code and has no impact on the actual Bitcoin wallet software or its users.
AI review queuedutil/stdmutex: Drop StdLockGuardby Anthony Towns · 904c0d07 · Apr 23, 2026 · 1 fileMessage 35 · OpaqueInformational 15Details
Commit message · Anthony Towns
util/stdmutex: Drop StdLockGuard
35/100 · OpaqueMessage clarity
✓ Descriptive subject! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI analysis · Informational 15/100
This commit removes a two-line backwards-compatibility type alias named StdLockGuard from a header file. It is a routine cleanup with no functional change to how the software behaves or to its security.
On 32-bit systems we build with _FILE_OFFSET_BITS=64 (see CMakeLists.txt), which makes rlim_t 64-bit when building against glibc (see bits/resource.h). Since size_t could be 32-bit, clamp RLIMIT_MEMLOCK to std::numeric_limits<size_t>::max() in PosixLockedPageAllocator::GetLimit().
Co-authored-by: Luke Dashjr <luke-jr+git@utopios.org>
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Low 43/100
This change fixes a type-size mismatch on 32-bit systems. On those systems, the operating system can report a memory-lock limit as a 64-bit number, but the program stores it in a 32-bit variable. Without the fix, a very large limit could wrap around to a tiny value, potentially causing the wallet to lock far less memory than intended and possibly mishandle sensitive key data. The patch clamps the value to the largest safe 32-bit size before using it.
Similar to the previous commit, this is fixed by capping the limit to std::numeric_limits<int>::max().
Co-authored-by: Luke Dashjr <luke-jr+git@utopios.org>
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Low 33/100
This commit fixes a bug where Bitcoin Core would fail to start if the operating system allowed an unusually high number of open files (file descriptors). The limit was being treated as a negative number due to a conversion overflow, causing the program to incorrectly report that no file descriptors were available. The fix caps the value at the maximum a normal integer can hold, preventing the startup failure.
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.
test: Use MiB operator directly in cuckoocache_tests
Previously, they were using a pattern of defininig a constant megabytes symbol, and then multiplying that by 1_MiB.
It is easier to use the _MiB operator directly.
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 minor cleanup of Bitcoin Core's internal test code. It changes how test helpers express memory sizes, replacing a two-step 'megabytes × 1_MiB' calculation with the '_MiB' operator directly. There is no change to the actual Bitcoin node software, no security fix, and no behavior change in the tests beyond the same numeric values being passed through.
Lower-prioritykernel: guard btck::Handle move-assignment against self-moveby Thomas · 14547eb4 · Apr 23, 2026 · 2 filesMessage 73 · AdequateModerate 62Details
Commit message · Thomas
kernel: guard btck::Handle move-assignment against self-move
The move-assignment operator for btck::Handle<> unconditionally called DestroyFunc(m_ptr) before reading the source pointer. On a self-move (h = std::move(h)), this destroyed the held resource and then reassigned the now-dangling pointer back to m_ptr via std::exchange, leading to a double-free when the object is later destroyed.
Mirror the existing self-check in the copy-assignment operator by guarding the move-assignment with 'if (this != &other)' so a self-move becomes a no-op, leaving the object in a valid state as required by the standard library.
Handle<> is the base of 16 public types in the kernel C++ API wrapper (Transaction, Block, BlockHeader, ChainParams, Context, Coin, BlockValidationState, ScriptPubkey, TransactionOutput, Txid, OutPoint, TransactionInput, PrecomputedTransactionData, BlockHash, BlockSpentOutputs, TransactionSpentOutputs), so self-move can arise from generic algorithms operating on containers of these types.
Extend CheckHandle in test_kernel to cover self-move-assignment for every Handle-derived type.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Moderate 62/100
This commit fixes a bug in Bitcoin Core's kernel C++ API wrapper where a special kind of assignment—moving an object into itself—could accidentally destroy its own underlying resource and later cause a crash (double-free) when the object is cleaned up. The fix adds a self-check, similar to one already used for copy assignment, so self-moves do nothing harmful. The change also adds tests for all 16 public types built on this wrapper.
See https://github.com/bitcoin-core/bitcoincore.org/pull/1240 and https://github.com/bitcoin/bitcoin/pull/35132.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
Why it was queued
documentation-only discount
AI analysis · Informational 11/100
This is a documentation-only edit to the Bitcoin Core 31.0 release notes. It adds a notice that older versions (28.x and below) are no longer supported and that details of one medium-or-high-severity vulnerability fixed in version 29.0 will be disclosed in two weeks. The commit itself does not change any code, nor does it describe the actual vulnerability.
Lower-prioritytests: Add some fuzz test coverage for command-specific argsby Anthony Towns · 89af67d7 · Apr 22, 2026 · 1 fileMessage 60 · AdequateInformational 15Details
Commit message · Anthony Towns
tests: Add some fuzz test coverage for command-specific args
60/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 15/100
This commit only adds new fuzz testing code. It expands an existing test to randomly exercise the handling of command-specific arguments in Bitcoin Core's argument manager. There is no change to production code, no user-facing behavior change, and no security fix or vulnerability introduced.
Lower-prioritytests: Add some test coverage for ArgsManager::AddCommandby Anthony Towns · 92df7858 · Apr 22, 2026 · 1 fileMessage 75 · AdequateInformational 15Details
Commit message · Anthony Towns
tests: Add some test coverage for ArgsManager::AddCommand
Co-Authored-By: l0rinc <pap.lorinc@gmail.com>
75/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
AI analysis · Informational 15/100
This commit only adds new unit tests for an existing argument-parsing helper in Bitcoin Core. It does not change any production code, so it cannot introduce a security vulnerability or fix one. It simply verifies that command-specific options are accepted or rejected as expected.
AI review queuedArgsManager: automate checking for correct command optionsby Anthony Towns · 33c8090b · Apr 22, 2026 · 4 filesMessage 50 · ThinLow 28Details
Commit message · Anthony Towns
ArgsManager: automate checking for correct command options
50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 28/100
This commit adds an automated check in Bitcoin Core's argument manager so that command-line options meant only for specific wallet-tool commands (like -dumpfile) are rejected when used with the wrong command. It replaces a one-off manual check with a general mechanism and adds a test. It is a hardening improvement, not a fix for an active vulnerability.
AI review queuedbitcoin-wallet: use command-specific optionsby Anthony Towns · 186354a0 · Apr 22, 2026 · 1 fileMessage 45 · ThinInformational 15Details
Commit message · Anthony Towns
bitcoin-wallet: use command-specific options
45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This is a tiny user-interface cleanup for the bitcoin-wallet command-line tool. It moves the '-dumpfile' option into a 'command-specific' category and declares that it only applies to the 'dump' and 'createfromdump' commands. There is no change to how data is handled, no bug fix, and no security relevance visible in the commit.
Lower-priorityArgsManager: support command-specific optionsby Anthony Towns · d21e82b7 · Apr 22, 2026 · 3 filesMessage 45 · ThinInformational 17Details
Commit message · Anthony Towns
ArgsManager: support command-specific options
45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Informational 17/100
This commit is a code cleanup and feature addition for Bitcoin Core's command-line help system. It lets individual commands (like 'getblock' or 'send') declare their own specific options, and shows those options indented under the command in help output. There is no direct security bug here; it is a refactor that changes how help text is formatted and how command-specific options are registered.
Lower-prioritydoc: update release process to mention security advisories pre-announcementsby Antoine Poinsot · 4abc0c2e · Apr 21, 2026 · 2 filesMessage 55 · ThinInformational 15Details
Commit message · Antoine Poinsot
doc: update release process to mention security advisories pre-announcements
55/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Names security-relevant behavior explicitly! No meaningful explanatory body
Why it was queued
documentation-only discount
AI analysis · Informational 15/100
This commit only changes documentation. It updates Bitcoin Core's release notes template and release process checklist to remind maintainers to mention upcoming security advisories when announcing a new release. No code, no bug fix, no vulnerability is present in the patch.
Lower-priorityAdd release notes for exportasmapby Fabian Jahr · 2a90b613 · Apr 21, 2026 · 1 fileMessage 45 · ThinInformational 15Details
Commit message · Fabian Jahr
Add release notes for exportasmap
45/100 · ThinMessage clarity
✓ 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 short release note describing a new RPC command called exportasmap. There is no code change, no bug fix, and no security-related content.
✓ Subject identifies a change! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI analysis · Informational 23/100
This commit adds a new Bitcoin Core RPC command called exportasmap. It lets a user with RPC access write a copy of the built-in network-mapping database (the ASMap file) to a file on the node's disk. The file path is relative to the node's data directory, cannot escape it, and any existing file at that path is overwritten. It is a straightforward export feature with no obvious code-level security bug, but it does add another way for an authenticated RPC user to write files on the server, which is normally a capability reserved for trusted administrators.
AI review queuedrefactor: replace `DataStream` with `SpanReader` in block deserialization testsby Lőrinc · 13c8df4d · Apr 21, 2026 · 1 fileMessage 95 · StrongInformational 15Details
Commit message · Lőrinc
refactor: replace `DataStream` with `SpanReader` in block deserialization tests
These benchmark inputs are immutable fixture bytes, so `DataStream` adds an unnecessary owned buffer and the setup needed to recreate or preserve its state.
Use `SpanReader` for block deserialization in `checkblock` instead. This keeps `DeserializeBlockTest` focused on deserialization work, while `CheckBlockTest` still uses untimed setup only to rebuild a fresh uncached `CBlock` for the timed `CheckBlock()` call.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
second-pass: broader security terminology
AI analysis · Informational 15/100
This is a small internal cleanup in Bitcoin Core's benchmark code. It swaps one helper class for another when reading a fixed test block, removes unused header includes, and simplifies how the benchmark obtains mainnet chain parameters. There is no change to how real network blocks are validated or to any user-facing behavior.
AI review queuedrefactor: use `SpanReader` in `PrevectorDeserialize`by Lőrinc · 2529f255 · Apr 21, 2026 · 2 filesMessage 97 · StrongInformational 15Details
Commit message · Lőrinc
refactor: use `SpanReader` in `PrevectorDeserialize`
`PrevectorDeserialize` only needs a reusable read-only view over fixed serialized bytes. Keeping a mutable `DataStream` around just to call `Rewind()` is unnecessary.
Rebuild a fresh `SpanReader` for each benchmark run and remove `DataStream::Rewind()`, whose remaining use was this benchmark-only reset path. The benchmark can now serialize exactly the 1000 entries it deserializes, so drop the stale extra element that used to avoid full consumption.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
second-pass: broader security terminology
AI analysis · Informational 15/100
This is a code cleanup change in Bitcoin Core's internal benchmarking code. It swaps a mutable data stream for a simple read-only view in a performance test, and removes an unused helper function called Rewind(). There is no security issue here.
AI review queuedrefactor: use `SpanReader` in `TestBlockAndIndex`by Lőrinc · b8eb6c20 · Apr 21, 2026 · 1 fileMessage 92 · StrongInformational 15Details
Commit message · Lőrinc
refactor: use `SpanReader` in `TestBlockAndIndex`
`TestBlockAndIndex` still deserialized its fixed block fixture through `DataStream` and appended a dummy byte to avoid compaction after full consumption.
Use `SpanReader` for that fixture instead. This removes the leftover dummy-byte workaround and reads the immutable fixture through a read-only view.
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
Why it was queued
second-pass: broader security terminology
AI analysis · Informational 15/100
This is a small internal cleanup in Bitcoin Core's benchmarking code. It swaps one way of reading a fixed test block fixture for another, read-only way, and removes a workaround that added a dummy byte. There is no user-facing or security-relevant change.
Lower-priorityrefactor: use `DataStream::clear` in `::read` and `::ignore`by Lőrinc · 61d678a6 · Apr 21, 2026 · 1 fileMessage 85 · StrongInformational 15Details
Commit message · Lőrinc
refactor: use `DataStream::clear` in `::read` and `::ignore`
When `DataStream` is fully consumed, both `read()` and `ignore()` reset it to an empty state by clearing the backing buffer and resetting the read position.
Call `clear()` in both places instead of open-coding the same state transition. This keeps the behavior unchanged while documenting the fully-consumed reset in one place.
Remove the unused `Compact()` method as well - it has been unused for a long time and can be added back if it is ever needed.
85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
AI analysis · Informational 15/100
This is a small internal cleanup in Bitcoin Core's data-stream class. It replaces two snippets of identical code with a single call to an existing `clear()` method and removes an unused helper function. The commit message explicitly states the behavior is unchanged. There is no security-relevant change visible in the diff or references.