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
`CDBBatch` already owns key and value serialization buffers, but manually reserved and cleared them on each call.
Reserve those scratch buffers once in the constructor, then guard `Write()` and `Erase()` use with `ScopedDataStreamUsage`, requiring empty streams on entry and clearing them on every exit path. `WriteImpl()` and `EraseImpl()` pass the bytes immediately to LevelDB's write batch, which copies them and does not retain pointers.
`Clear()` now asserts the guards left both scratch streams clean.
Co-authored-by: Andrew Toth <andrewstoth@gmail.com>
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 16/100
This change is a small internal cleanup in how Bitcoin Core prepares database writes. It reuses temporary memory buffers instead of repeatedly reserving and clearing them, and adds a helper to make sure those buffers are empty before and after each use. There is no direct evidence this fixes an active security bug; it is best described as defensive hardening or code-quality improvement.
The next commits reuse scratch streams on `CDBBatch` and `CDBIterator`.
Extend dbwrapper tests to reuse a batch after `Clear()`, seek repeatedly on one iterator, and fail a too-large `CDBIterator::GetValue()` decode before reading the same entry successfully. This locks down the reuse and failed-decode contracts before the production changes.
90/100 · StrongMessage clarity
✓ 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 adds new test cases for the database wrapper code. It checks that a database batch can be reused after being cleared, and that a database iterator can be seeked multiple times and recover from a failed value decode. There are no changes to production code, so this commit does not introduce or fix a security vulnerability by itself.
Some DB paths reuse caller-owned `DataStream` scratch buffers across calls.
Add a small RAII helper that asserts the stream is empty on entry and clears it on exit. This preserves the old temporary-stream contract while making accidental nested reuse fail fast in debug builds.
This commit adds a small helper class that wraps a temporary data buffer used internally by Bitcoin Core's database code. It makes sure the buffer is empty when use starts and clears it when use ends, and in debug builds it will crash the program if a buffer is accidentally reused while still in use. It is a defensive hardening change, not a fix for a known exploitable bug.
validation: Don't add pruned blocks to m_blocks_unlinked on startup
LoadBlockIndex() adds to m_blocks_unlinked based only on nTx > 0, without checking BLOCK_HAVE_DATA. Pruning preserves nTx but clears BLOCK_HAVE_DATA, so a pruned block whose parent was header-only gets re-added on every restart, causing the CheckBlockIndex() assertion that entries must have data on disk to fail.
Check that BLOCK_HAVE_DATA is set before inserting into m_blocks_unlinked.
Fixes #35050.
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 53/100
This commit fixes a bug where Bitcoin Core could crash on startup with a failed internal consistency check. The crash happened when a node had 'pruned' old block data while also having some header-only blocks, causing the program to incorrectly re-add pruned blocks to an internal list that is supposed to contain only blocks still stored on disk. The fix adds a check to skip pruned blocks when rebuilding that list during startup.
Using an existing block or a newly created block, send a compact block message to the target node. Some of the time, the harness will prefill multiple transactions from the block. Adds a FuzzedCBlockHeaderAndShortTxIDs class that's used to populate the protected prefilledtxn and shorttxids fields.
78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 15/100
This commit only adds new fuzz testing code for Bitcoin Core's compact block (CMPCTBLOCK) handling. It does not change any production network or consensus code, so it cannot introduce a runtime security vulnerability in the software users run. It is a test-harness improvement.
fuzz: send blocktxn messages in cmpctblock harness
Sometimes, blindly take an existing block and choose random transactions to request in a blocktxn message.
80/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 15/100
This commit adds a new test case to an existing fuzzing harness for Bitcoin Core's compact block (cmpctblock) handling. It does not change production code, network behavior, or wallet logic. The new code only runs inside a fuzz test and randomly sends 'blocktxn' messages to exercise more code paths during automated testing. There is no security vulnerability here.
Security candidatefuzz: mine blocks and send headers for them in cmpctblock harnessby Eugene Siegel · 3c58efe2 · Apr 27, 2026 · 3 filesMessage 95 · StrongInformational 15Details
Commit message · Eugene Siegel
fuzz: mine blocks and send headers for them in cmpctblock harness
The blocks may include mempool and non-mempool transactions. If the block index was added to, reset the rng, mempool, and chainman. Also move FinalizeHeader from p2p_headers_presync.cpp to util.h so that the mining function can use it to create valid headers.
95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
entropy or randomnessfuzzing or regression evidence
AI analysis · Informational 15/100
This commit only changes Bitcoin Core's internal fuzz testing code. It expands a fuzz harness so that the test can mine fake blocks and send headers for them, improving test coverage for compact block processing. There is no change to production network code, wallets, consensus rules, or RPC interfaces, so it does not introduce a security vulnerability in the software users run.
fuzz: create and send transactions in cmpctblock harness
If the mempool is modified at all (determined by a change in the sequence counter), reset the rng, mempool, and the chainman for the next iteration.
83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
entropy or randomnessfuzzing or regression evidence
AI analysis · Informational 15/100
This commit only changes a fuzz test file (src/test/fuzz/cmpctblock.cpp). It makes the compact-block fuzzing harness create and send fake transactions during testing, and resets internal test state if the mempool changes. There is no change to production Bitcoin Core code, network rules, or wallet behavior. It does not fix or introduce a real security vulnerability.
Lower-prioritynet, fuzz: move CMPCTBLOCK_VERSION to header, use in cmpctblock harnessby Eugene Siegel · 8c9a3fd0 · Apr 27, 2026 · 3 filesMessage 75 · AdequateInformational 15Details
Commit message · Eugene Siegel
net, fuzz: move CMPCTBLOCK_VERSION to header, use in cmpctblock harness
The cmpctblock harness now adds peers and processes the sendcmpct message.
75/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 15/100
This commit moves a constant for compact block version from one file to a shared header and updates a fuzz test to exercise the sendcmpct network message. It is a test/refactoring change with no visible security fix or behavior change in production code.
Adds a fuzz harness cmpctblock to test BIP152 compact block relay. Currently just sets mock time in a loop.
70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 15/100
This commit adds a new fuzz-testing harness for compact block relay in Bitcoin Core. Fuzz testing is an automated quality-assurance technique that feeds random or semi-random data into code to find crashes or bugs. The harness currently only sets mock time in a loop and does not change any production networking, consensus, or wallet code. It is purely a test addition.
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Informational 15/100
This commit only changes the wording of a log message produced when Bitcoin Core's database verification tool finishes. It does not alter security behavior, fix a bug, or change any code logic. The new message simply reports how many blocks were checked and at what verification level, and only claims 'no inconsistencies' when an appropriate deep check was actually performed.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 29/100
This is a defensive coding change in Bitcoin Core. It removes the default way to use CTransactionRef (a shared pointer to a transaction) as a key in hash tables, because the default behavior would compare memory addresses instead of transaction content. The change forces developers to explicitly choose a proper hash function, reducing the risk of subtle bugs in the future. It does not by itself fix a known active vulnerability.
Cherry-pick include-what-you-use commit 52f85e1f4d99 onto the clang_22 branch tracked by ci/test/00_setup_env_native_iwyu.sh, fixing the false positive where std::hash was mapped to <string_view>/<variant> instead of its real provider (<functional>, <memory>, etc).
90/100 · StrongMessage clarity
✓ 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 updates Bitcoin Core's continuous integration (CI) tooling. It adds a patch for the include-what-you-use (IWYU) static analysis tool so that IWYU correctly recognizes which C++ standard library headers provide std::hash. This is a tooling-only change and does not alter the Bitcoin Core software that users run, so it has no direct security impact on the Bitcoin network or node operators.
cmake: Remove NetBSD-specific workaround from `add_boost_if_needed`
The patched package is available as of the `pkgsrc-2026Q1` release.
65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
AI analysis · Informational 15/100
This commit removes a build-system workaround that was only needed for NetBSD's package manager. The workaround adjusted where the compiler looks for Boost header files on NetBSD. It is being removed because the upstream NetBSD package has been fixed. There is no indication this change fixes a security vulnerability in Bitcoin Core itself.
AI review queuedrpc: combinerawtransaction now rejects unmergeable transactionsby Adam Andrews · 6d86184a · Apr 27, 2026 · 2 filesMessage 73 · AdequateLow 29Details
Commit message · Adam Andrews
rpc: combinerawtransaction now rejects unmergeable transactions
Previously, combinerawtransaction would silently return the first tx when asked to combine unrelated txs. Now, it will check tx mergeability and throws a descriptive error if tx cannot be merged.
73/100 · AdequateMessage clarity
✓ Specific, 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 · Low 29/100
This change fixes a behavior in Bitcoin Core's combinerawtransaction RPC command. Previously, if you gave it transactions that didn't belong together, it would quietly return the first transaction as if nothing was wrong. Now it checks that the transactions are actually mergeable and returns a clear error if they aren't. It also now requires at least two transactions to be provided. This is mostly a robustness and usability improvement rather than a critical security fix.
AI review queuedtest: add coverage for loading a wallet in a non-writable directoryby furszy · 08925d5e · Apr 25, 2026 · 1 fileMessage 87 · StrongLow 33Details
Commit message · furszy
test: add coverage for loading a wallet in a non-writable directory
Previously, wallets in non-writable directories were loaded, leading to crashes on any subsequent write.
87/100 · StrongMessage clarity
✓ Specific, 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
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 33/100
This commit adds a new automated test to Bitcoin Core. The test checks that the program refuses to load a wallet stored in a directory where it cannot write files. The commit message says that, before this behavior existed, loading such a wallet would cause the node to crash whenever it later tried to write data. The change itself only adds a test; it does not change the wallet-loading code. So the actual crash-prevention logic must have been introduced in an earlier commit that is not shown here.
AI review queuedtest: add coverage for wallet creation in non-writable directoryby furszy · 0218966c · Apr 25, 2026 · 2 filesMessage 72 · AdequateInformational 14Details
Commit message · furszy
test: add coverage for wallet creation in non-writable directory
72/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 14/100
This commit only adds a new automated test that checks Bitcoin Core correctly refuses to create a wallet in a directory without write permission. It does not change the wallet-creation logic itself, so it does not fix or introduce a security issue in the software.
We currently allow loading wallets located on non-writable directories. This is problematic because the node crashes on any subsequent write. E.g. generating a block is enough to trigger it.
2) For wallet creation, this improves the returned error msg.
Before: creating a wallet would return a generic error: "SQLiteDatabase: Failed to open database: unable to open database file"
After: creating a wallet returns: "SQLiteDatabase: Failed to open database in directory <dir_path>: directory is not writable"
80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
signing or wallet pathsecond-pass: broader security terminologysecond-pass: security-sensitive path
AI analysis · Low 44/100
This Bitcoin Core commit fixes a bug where the program would crash if a wallet was loaded from a directory that cannot be written to. It also gives a clearer error message when someone tries to create a wallet in such a directory. The fix checks whether the directory is writable before opening the wallet database, and reports a helpful error instead of crashing or showing a generic failure.
On some systems the old example of using xargs to pass list of profraw files can exceed xargs's argument limit resulting in multiple executions of llvm-profdata merge command which overwrites it's output file losing coverage information. Switch to using a file with a list of filenames.
78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
documentation-only discount
AI analysis · Informational 15/100
This commit only updates a documentation example for developers about how to merge code-coverage data files. It changes the suggested shell command from using xargs to using a file list, preventing a tool from running multiple times and accidentally overwriting its own output. There is no change to Bitcoin Core's actual code, network behavior, or wallet security.
Lower-priorityrefactor: Run ShouldWarnOversizedDbCache calculation in u64by MarcoFalke · fa43da21 · Apr 24, 2026 · 3 filesMessage 95 · StrongInformational 15Details
Commit message · MarcoFalke
refactor: Run ShouldWarnOversizedDbCache calculation in u64
This follows the approach of the MiB and GiB operators.
This allows to remove some `if constexpr (SIZE_MAX == UINT64_MAX)` in the tests.
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 internal cleanup change in Bitcoin Core. It changes a helper function that decides whether to warn users about an oversized database cache so that it always uses 64-bit unsigned integers instead of the platform-dependent `size_t` type. The tests are simplified accordingly. There is no user-facing behavior change and no security fix.
util: Return uint64_t from _MiB and _GiB operators
50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Informational 15/100
This is a routine code-quality change in Bitcoin Core. It changes two helper functions that convert 'MiB' and 'GiB' values into byte counts so they always return a 64-bit unsigned integer instead of a size type that can be 32-bit on some platforms. It also removes runtime overflow exceptions for values that used to be too large on 32-bit systems. There is no security bug being fixed here.
Recently, I ran clang-tidy in my system and had to figure out setting it up correcty on my system (macOS) & understanding its output while tweaking few arguments that made the output easier to parse.
This patch documents those in the developer notes.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
documentation-only discount
AI analysis · Informational 15/100
This is a documentation-only change to the developer notes. It adds clearer instructions for running the clang-tidy code-quality tool on Bitcoin Core. There are no code changes, no security fixes, and no behavior changes to the Bitcoin software itself.
Lower-priorityci: add --extended when using --usecliby Pol Espinasa · a49bc1e2 · Apr 24, 2026 · 1 fileMessage 90 · StrongInformational 15Details
Commit message · Pol Espinasa
ci: add --extended when using --usecli
Add the flag --extended to a test (00_setup_env_i686_no_ipc.sh) with the --usecli flag to cover all tests with --usecli.
90/100 · StrongMessage clarity
✓ 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 continuous integration (CI) test script to add the '--extended' flag when running tests with '--usecli'. It does not modify any production code, network behavior, wallet handling, or consensus logic. There is no security issue here.
The alias of the size() method is confusing, because:
* It claims to be part of the Bitcoin Core stream subset (streams interface), but this is not used by any other stream interface. Mostly the `write(std::span)` and `read(std::span)` define the stream interface. * It casts the size_t to i32, but the only place that calls the function casts that back to size_t. * Providing this alias for size() without a proper reason is confusing.
Fix all issues by removing it and using the size() method.
80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI analysis · Informational 15/100
This commit is a simple code cleanup: it removes a confusing alias named `in_avail()` from a data stream class and replaces its only use with a direct call to `size()`. There is no security issue here.
This commit can be reviewed with the git options: --color-moved=dimmed-zebra --color-moved-ws=ignore-all-space
60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
AI analysis · Informational 15/100
This commit simply moves the existing code that handles PONG network messages into a new helper function called ProcessPong(). There are no functional changes, no bug fixes, and no security changes. It is a code-cleanup refactor to make the large ProcessMessage() function easier to read and maintain.