Bitcoin Core

This change adjusts how Bitcoin Core's build system installs the Boost C++ library headers. It places Boost headers in a unique subdirectory so that other software components included in the build don't accidentally pick up Boost headers when they shouldn't. This is a defensive build-hygiene fix, not a direct patch for a known exploit.

This commit changes how a tracing header file (systemtap's sdt.h) is installed during Bitcoin Core's dependency build. Previously the header was placed directly in a shared include folder, which could cause other unrelated dependencies to accidentally pick it up. The patch moves it to a package-specific subfolder and explicitly tells the build system where to find it. This is a defensive hardening change rather than a fix for a known active exploit.

This is a one-line build-system fix that adds a missing dependency on Boost header files for an internal inter-process communication library. It does not change any runtime code, network behavior, or wallet logic, and there is no indication it fixes a security vulnerability.

This commit removes an old wallet-loading code path called NEED_REWRITE that was used to automatically rewrite certain very old Berkeley DB (BDB) wallets from Bitcoin versions 0.4.0 and 0.5.0. The change is described as cleanup because those wallets can no longer be loaded outside of migration, and migration already rewrites the database. There is no direct evidence in the commit of a security vulnerability being fixed.

This commit removes leftover calls to a wallet method called RewriteDB that no longer had any real implementation. It is a small code cleanup with no security impact.

This is a Bitcoin Core test-only change. It fixes a unit test so that the miniscript it builds is actually valid, and renames the test to better reflect that it stresses stack usage during node construction/destruction/cloning. No production code is changed, and there is no security fix or vulnerability being patched.

This commit only adds a two-line comment explaining why the code manipulates vectors of objects rather than individual objects. It changes no program logic, no data structures, and no behavior. There is no security issue here.

This commit only adds documentation: a release note explaining that the Bitcoin Core fee estimator now tracks lower fee rates (down to 0.1 sat/vB instead of 1 sat/vB). There is no code change, no bug fix, and no security issue in the diff itself.

This commit only changes a Bitcoin Core functional test file. It adds a new test to verify that the fee estimator can return estimates below 1 satoshi per virtual byte, and refactors how the test tracks confirmed and unspent transaction outputs. There are no changes to production code, consensus rules, networking, or wallet behavior, so it does not introduce or fix a live security issue.

This commit removes an unused placeholder value from the fee estimator's saved data file format. It is a cleanup change with no apparent security relevance.

This commit simply updates a version number used when Bitcoin Core saves its fee-estimation data to disk. It is a routine compatibility marker, not a security fix. There is no vulnerability here.

This commit lowers the lowest fee-rate bucket used by Bitcoin Core's built-in transaction fee estimator from 1000 to 100. It is a follow-up to an earlier policy change that reduced the default minimum relay fee. The change keeps the estimator in sync with the new lower bound so users can still get reasonable fee estimates when the network is quiet. It is not a vulnerability fix and does not introduce a clear security flaw, though any change to fee-estimator constants can affect user-facing fee recommendations.

This is a Bitcoin Core test-only fix. It resets a small piece of connection-manager state between repeated fuzz-test runs so that earlier iterations do not influence later ones. It does not change production network code and is not an exploitable security bug in live Bitcoin software.

This commit is a minor test-only code cleanup. It adds a single convenience method called Reset() to a test helper class, so that fuzz tests can call one method instead of two. It does not change any production Bitcoin networking code and has no security relevance for live nodes.

This commit is a simple documentation fix. It updates a single hyperlink in a README file because the bpftrace project moved its installation instructions to a different web address. There is no code change and no security relevance.

This commit adds a new automated fuzz test for Bitcoin Core's coin selection algorithm. It does not change any production wallet code, network behavior, or consensus rules. The test brute-forces small coin-selection problems and checks that the Branch-and-Bound (BnB) solver finds a minimum-waste solution. It is purely a testing/quality-assurance addition.

This change only adds a '--failfast' flag to Bitcoin Core's internal continuous integration script. It tells the test runner to stop after the first test failure instead of continuing. There is no security relevance: it does not change production code, network behavior, wallet handling, or any user-facing functionality.

This commit changes Bitcoin Core's GitHub Actions CI workflow. It removes a hard cap that previously tested only the 6 most recent ancestor commits in a pull request, and instead tests every non-head commit. It also switches the CI runner to a faster Cirrus-hosted runner. There is no change to Bitcoin's runtime code, consensus rules, wallet handling, or network behavior, and no security vulnerability is introduced or fixed.

This commit updates a patch file used in Bitcoin Core's continuous integration (CI) tooling. The patch guides an automated code-style checker (include-what-you-use) to recommend modern C++ headers like <cstdint> instead of older C-style headers. It does not change any Bitcoin Core runtime code, consensus logic, or network behavior, and has no direct security impact on users.

This is a routine build-system cleanup. Bitcoin Core's internal 'kernel' library no longer needs to force programs that use it to also depend on the Boost C++ library, because the kernel's public interface has been rewritten to avoid BOOST. The change simply removes one line from a CMake build file so BOOST is kept as a private dependency of the kernel itself rather than being propagated to downstream consumers. There is no security-relevant code change.

This commit only changes test code in Bitcoin Core. It loosens a C++ concept check so more byte-returning types can be tested, switches a test comparison from 'different sizes' to 'different contents', and tightens a range helper to require non-empty ranges. There is no change to production code, consensus logic, networking, or wallet handling, so it does not introduce a security vulnerability.

This commit only changes test code comments. It adds named labels (like /*reindex=*/true) to function arguments in Bitcoin Core's kernel tests so the code is easier to read and can be checked by a style tool called clang-tidy. It does not change any real Bitcoin node behavior or fix a security issue.

This is a pure code cleanup (refactoring) change in Bitcoin Core's libbitcoinkernel. It replaces a few verbose type names and function calls with shorter equivalents, removes an unused header include, and rewords a documentation comment. There is no change to program behavior, no bug fix, and no security relevance.

This commit removes a Valgrind suppression rule. Valgrind is a debugging tool used to detect memory errors; a suppression rule simply tells Valgrind to ignore a known, harmless false-positive warning. Removing it does not change Bitcoin Core's actual code, behavior, or security. It only affects internal testing diagnostics, and only on a specific platform (musl libc on 64-bit ARM) when running Valgrind. The suppression was originally added because of a bug in Valgrind itself, which the commit message says is fixed in Valgrind 3.22.

This commit only adds documentation. It explains what ASMap data is, how it is sourced and verified, and adds a checklist item to the release process reminding developers to update the embedded ASMap file before a release. No code, configuration, or data files were changed.