Bitcoin Core

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

This commit adds two new optional controls to Bitcoin Core's peer eviction logic: a flag to only evict transaction-relaying peers, and a way to protect a specific peer from being evicted. The existing call site still behaves exactly as before (the new flag is set to false). The change is a preparatory refactor for future commits and does not, by itself, alter live network behavior or fix a known vulnerability.

This is a one-line build-script fix that removes a harmless CMake warning on non-Linux build hosts. It changes how an optional linker-flags variable is passed to CMake so that, when the variable is empty, no empty argument is passed. There is no indication this affects runtime behavior, wallet funds, consensus, network security, or built binaries.

This commit removes redundant '--verbose' flags from Guix build scripts. The verbose output is already controlled by an environment variable, so these flags were unnecessary. There is no security relevance.

This commit removes an unused header file (`<variant>`) from a benchmark source file. It is a code cleanup change with no security relevance. It does not affect the Bitcoin Core software that users run, only an internal performance-testing program.

This commit removes an unused, broken developer-only profiling feature from Bitcoin Core's test framework. It deletes the `--perf` command-line option, related documentation, and the code that launched the Linux `perf` tool during functional tests. There is no change to the actual Bitcoin node software that users run, and nothing here affects live funds, network consensus, or wallet security.

This commit simply increases the time limit for one automated testing job in Bitcoin Core's continuous integration (CI) pipeline. It changes a single number from 150 to 180 minutes so that a memory-sanitizer fuzzing test is less likely to time out when caches are missing. There is no change to Bitcoin Core's actual code, no security fix, and no vulnerability.

This commit tightens the maximum allowed mock time in Bitcoin Core's testing-only RPC command `setmocktime` from the year 2262 down to the year 2106 (the maximum value a 32-bit unsigned timestamp can hold). The change prevents two types of bugs that can occur only when a developer or tester manually sets an extremely far-future mock time: signed 64-bit integer overflow in time calculations, and silent truncation when the mocked time is copied into a 32-bit block timestamp field. The command is not available in production nodes and cannot be triggered by ordinary network peers, so this is a low-severity hardening fix for a testing tool.

This is a tiny build-system revert. It changes one line in a CMake file so that the 'mptest' target is no longer excluded from the generated compile_commands.json database used by developer tools like clang-tidy. There is no indication this affects runtime security, user funds, network consensus, or shipped binaries. It appears to be a developer-quality or tooling fix.

This commit is a code cleanup in Bitcoin Core's RPC help documentation. It restructures how the help text for the getblock command is generated, replacing duplicated inline descriptions with shared helper functions. It does not change what data the software returns, how it processes network data, or any security-sensitive logic.

This commit is a code cleanup that extracts a repeated list of RPC help text fields into a reusable helper function. It only affects how the documentation/help output for the listsinceblock command is generated, not how transactions or wallet data are processed. There is no security issue visible in the change.

This commit is a straightforward code cleanup in Bitcoin Core's RPC help documentation. It extracts repeated fee-estimation help text into reusable helper functions so the code is easier to maintain. It does not change what the software actually does, what data it returns, or how it handles user input.

This commit is a documentation-only change for the Bitcoin Core wallet's 'getaddressinfo' RPC command. It replaces a vague placeholder in the help text with a detailed, explicit list of fields that can appear inside the 'embedded' object. No wallet logic, validation rules, or network behavior is changed.

This commit is a code cleanup for Bitcoin Core's RPC help documentation. It restructures how the help text for getrawtransaction verbosity=2 is generated, making it more consistent with other RPC documentation. It does not change how transactions are fetched, validated, or returned at runtime. There is no indication this fixes a security bug.

This commit is a documentation-only change in the Bitcoin Core RPC help output. It replaces a vague placeholder description for the 'script' field inside decodepsbt with an explicit, structured description reused from another part of the code. There is no code behavior change, no bug fix, and no security relevance.