Bitcoin Core

This is a minor code cleanup that changes how a function accepts a list of block headers. It switches from requiring a specific container type (std::vector) to accepting any contiguous view (std::span), and updates the loop style. There is no change to security logic, no bug fix, and no behavior change visible to users or attackers.

This is a code cleanup change. It makes the way Bitcoin Core calculates 'proof of work' from block headers simpler and slightly more efficient, without changing the actual math or security rules. There is no indication this fixes a vulnerability.

This is a tiny code cleanup in Bitcoin Core's peer-to-peer message handling. It changes how one internal flag is set so that an existing true value is preserved, rather than rechecking a condition that cannot change a false value. There is no security issue visible in the diff.

This commit is a small performance optimization for Bitcoin Core. It changes how temporary in-memory data caches are cleaned up after use. Previously, these short-lived caches were always emptied and then immediately re-created, only to be destroyed moments later. The patch adds an option to skip that pointless re-creation step. It is not a security fix and does not change what data is stored or how it is validated.

This is a small internal performance cleanup in Bitcoin Core's coin cache code. It replaces two hash-map operations with one, reducing CPU work when copying coin data from a child cache into a parent cache. The commit explicitly says behavior is unchanged; no security vulnerability is described or evident in the diff.

This commit only changes documentation. It adds a new 'Privacy recommendations' section to the I2P guide and slightly rewords an existing note in the Tor guide. The text warns users that running a node on multiple networks at once can help protect the Bitcoin network against certain attacks, but may also allow an adversary to link those identities. There is no code change and no vulnerability being fixed.

This change tightens how Bitcoin Core handles the -asmap command-line option. Previously, starting the node with just -asmap (no filename) would silently try to load a file named ip_asn.map from the data directory. Now the user must explicitly provide a filename such as -asmap=ip_asn.map, otherwise the node refuses to start with a clear error. This is a behavior-hardening and documentation-clarity fix, not a patch for an active security vulnerability.

This commit only reformats Rust 'format!' strings to use a newer, shorter style supported by recent Rust compiler versions. It changes how variables are inserted into strings, not what the strings do. There is no security impact.

This commit adds a harmless debug annotation to Bitcoin Core's GitHub Actions CI workflow. It prints the pull request number as a machine-readable notice during CI runs, which helps link check runs back to their pull requests. There is no security issue here.

This is a harmless test-only change. It adds a new test case to make sure developers know that a mining interface function called submitBlock() changes the block template even when the submitted block is rejected. There is no security fix or vulnerability here.

Bitcoin Core's new mining IPC interface had a bug where it could accept an invalid block as the new chain tip. When an external mining client submitted a block solution with a new coinbase transaction, the node failed to re-check the block's witness commitment. This cached check could remain marked valid from the original template, allowing a block with a missing or wrong witness commitment to be accepted. The fix resets those cached checks whenever the coinbase is swapped in, and adds a test proving such invalid blocks are now rejected.

This commit only changes a code comment in a header file to clarify when a particular block-building helper function is safe to use. No executable code was modified, so it cannot introduce or fix a security vulnerability on its own.

This commit only changes a user-interface tooltip in the Bitcoin Core wallet creation dialog. It removes an outdated sentence that incorrectly said an HD seed could be added later to a blank wallet, which is not true for descriptor wallets. There is no code behavior change and no security impact.

This commit only adds a documentation note to the Tor setup guide. It warns users that running a Bitcoin node on multiple networks (like regular internet and Tor) can make it easier for attackers to correlate the node's identities, which may reduce privacy. No code was changed and no vulnerability was fixed.

This is a one-line change in a test file that resolves filesystem symlinks before looking up the Cap'n Proto include directory. It only affects the test suite's ability to find header files when the `capnp` binary is installed via a symbolic link. There is no security issue here.

This is a small defensive code change in Bitcoin Core that changes an internal size-measuring helper from using the system's native size type (size_t) to always using a 64-bit unsigned integer (uint64_t). On 64-bit computers nothing effectively changes. On 32-bit computers, the change prevents a theoretical integer overflow when calculating the serialized size of very large or malformed data. The commit message mentions this could matter for a specific malformed compact-block handling bug tracked as CVE-2025-46597 on 32-bit builds, but the patch itself only changes the return type and internal variable; it does not fix the compact-block logic directly.

This is a code cleanup change that swaps the variable type `size_t` for `uint64_t` in a handful of places that store serialized data sizes. On 64-bit computers the two types are the same size, so nothing changes. On 32-bit computers, `uint64_t` is larger and could in theory prevent a rare overflow if a serialized object ever exceeded about 4 GB. The commit message explicitly calls this a defensive refactor and says the practical risk is theoretical and unexpected. There is no reported bug, exploit, or security incident tied to this change.

This commit is a pure code cleanup: it replaces plain 'int' and 'unsigned int' type names with explicitly fixed-width 'int32_t' and 'uint32_t' in a few data structures. The project already assumed these sizes elsewhere, and the serialization format does not change, so there is no security or behavior impact.

This commit updates Bitcoin Core's continuous integration (CI) build scripts to install the python3-dev package instead of (or alongside) the base python3 package on two CI environments, including riscv64. It is a build-infrastructure fix, not a change to the Bitcoin node software that users run. There is no indication it fixes a security vulnerability in the Bitcoin protocol or wallet code.

This commit only updates a documentation file (INSTALL.md) describing how to install the Guix build environment. It removes an outdated note about the packaging situation and tweaks wording. There are no code changes and no security relevance.

This is a tiny GitHub Actions CI configuration fix. A previous code reorganization accidentally made the lint job run on GitHub's own virtual machines instead of the project's dedicated Cirrus runner machines. The fix changes the condition used to pick the runner so the lint job again uses the Cirrus runners and can access their local caches. It has no effect on the Bitcoin Core software users run, on wallets, transactions, consensus, or network security.

This is a minor cleanup change in Bitcoin Core's fuzz testing code (test-only, not production). It replaces a raw memory copy with a safer C++ standard library copy to silence a warning from the Undefined Behavior Sanitizer when the source data is empty. It does not fix a security vulnerability in live Bitcoin software.

This commit updates the SQLite library used by Bitcoin Core's build system from version 3.46.1 to 3.50.4, and switches to SQLite's newer 'Autosetup' build system. It also tightens some compile-time options, such as disabling dynamic extensions and adding a debug flag in debug builds. There is no direct evidence in the commit that this fixes a specific security vulnerability, but routine dependency updates can include upstream security fixes.

This commit adds the Tcl programming language package to the Guix build environment used to create reproducible Bitcoin Core releases. It is a build-system dependency fix, not a change to Bitcoin's wallet, networking, consensus, or node logic. There is no indication this introduces a security vulnerability or fixes one.

This commit is a documentation-only cleanup for Bitcoin Core's RPC help text. It makes the help description for the wallet's gettransaction RPC match the actual fields returned, and lets the shared DecodeTxDoc helper show an extra 'ischange' field only when used in wallet contexts. There is no code behavior change, no bug fix, and no security impact.