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