Bitcoin Core

This commit only deletes documentation files—specifically, draft release-notes fragments for the upcoming 31.0 release. No program code, configuration defaults, or runtime behavior is changed. It is a routine housekeeping change and has no security relevance on its own.

This commit only updates a documentation file (doc/bips.md) listing which Bitcoin Improvement Proposals (BIPs) are implemented in Bitcoin Core. It adds entries for BIPs 327, 328, 373, and 390, all related to MuSig2 multi-signature support. No code, logic, or configuration was changed, so this commit has no direct security impact.

This commit removes leftover documentation and example files from the Boost dependency after it is built. It is a cleanup change with no apparent security relevance.

This commit turns off a Qt build feature called SBOM generation in Bitcoin Core's dependency build system. SBOMs are inventory lists of software components. The change is a build-hygiene measure; there is no direct evidence in the commit that it fixes an exploitable security vulnerability.

This commit only updates a documentation file describing how asmap-data files are accepted into a related repository. It changes the rule from needing 5+ participants with a matching majority result to needing a result hash signed by 5+ participants. There is no code change and no direct security impact on Bitcoin Core itself.

This is a minor cleanup of Bitcoin Core's own functional test code. It changes two helper methods to be static (they don't need access to test class state) and rewrites a comment to be clearer about why the test still sends an initial GETADDR message. There is no change to the actual Bitcoin node software, no security fix, and no vulnerability.

This commit fixes a flaky Bitcoin Core functional test. The test was sometimes failing because the node would disconnect an outbound peer after the test advanced its internal clock too far. The fix makes the test announce the latest block header to the peer, which tells the node to protect that peer from disconnection. It is purely a test change and does not affect real network behavior or user funds.

This commit fixes bugs in a Bitcoin Core functional test script, not in the actual Bitcoin network node software. The test was checking address relay behavior using the wrong peer index and was silently passing because a setup step was missing. The fix moves an empty address message earlier and corrects which peer's statistics are checked. There is no change to production code and no security risk to running nodes.

This commit only adds a comment explaining what a particular function returns in different situations. No code behavior was changed, so it cannot introduce or fix a security issue.

This is a routine test-only change for Bitcoin Core. It adds the new '-txospenderindex' option to an existing initialization test and refactors the list of index arguments into a shared constant. There is no change to production code, no security fix, and no vulnerability.

This commit only changes test code. It replaces Unix-only socketpair() with a cross-platform TCP loopback socket helper so the same socket tests can run on Windows. There is no change to production Bitcoin Core networking code, consensus logic, or wallet handling, so it does not affect live node security.

This is a test-only change. It adds two lines to a single functional test file to wait for an internal index to finish syncing before continuing the test. There is no change to production Bitcoin Core code, no wallet or consensus logic is touched, and no security vulnerability is present in the commit.

This is a one-line change to a Bitcoin Core functional test. It adds a mempool synchronization step before the test checks that transactions are visible across nodes. It does not change production code, consensus rules, networking, or wallet behavior, and it does not fix a security issue in the Bitcoin software itself.

This commit adds a new bash tab-completion helper script for a new 'bitcoin' command-line wrapper tool. It only lives in the contrib/ directory (optional add-on files) and does not change any Bitcoin Core wallet, networking, or consensus code. There is no security issue visible in the change.

This commit adds fuzz-testing coverage for whitelist permission settings inside a test harness. It does not change production network code, user-facing behavior, or fix a live vulnerability. It is a test-quality improvement that helps automated fuzzers explore more code paths in CConnman initialization.

This commit contains only cosmetic formatting fixes: removing a blank line at the top of a header file, deleting an accidental backslash at the end of a C++ source line, and adding a trailing comma in a Python test dictionary. None of these changes affect program behavior or security.

This commit only changes the user-facing help text for the `-loadblock` command-line option. It adds a note that the option cannot read obfuscated (scrambled) block files. There is no code behavior change, no bug fix, and no security-relevant change.

This commit is a simple internal code cleanup in Bitcoin Core. It removes a small wrapper class called ConnectTrace and replaces it with a plain list (std::vector) of connected blocks, renaming some variables for clarity. There is no change to network rules, transaction validation, wallet behavior, or any user-facing feature. It does not fix a bug or introduce a known security issue.

This commit only changes a test file. It improves an existing functional test that exercises a known undefined-behavior bug in Bitcoin Core's block index handling. The test now uses a separate node, creates a three-way block race instead of a two-way race, and triggers the bug more reliably across different C++ standard library implementations. It does not change production code, so it does not fix or introduce a vulnerability by itself.

This commit fixes a low-level memory-handling bug in Bitcoin Core's startup code. When loading the chain tip, the program was changing a value (nSequenceId) that is also used to sort a set of candidate blocks, while the block was still in that set. In C++, changing a sort key while an item is in a sorted set is 'undefined behavior'—the program may crash, corrupt data, or behave unpredictably. The fix moves the population of the candidate set to after all such changes are complete. A second, related problem existed with the experimental assumeutxo feature, where two separate chain states share the same block objects and could interfere with each other's candidate sets. The patch addresses both by clearing and repopulating candidate sets at safe points.

This commit fixes a test-only race condition during shutdown of benchmark and unit tests that use Bitcoin Core's index objects. It adds a missing Stop() call in one benchmark and removes unnecessary synchronization comments/calls in several tests. The issue is not exploitable by users or network attackers; it only affects internal test code and could cause flaky or incorrect test results, including a potential virtual-pointer (vptr) race during benchmark teardown.

This commit removes a redundant function call and its assertion from the snapshot activation code in Bitcoin Core. The commit message explains the call was doing nothing useful because an earlier step already set the same state. There is no security-relevant change visible in the diff or commit message.

This commit adds a new fuzz test to Bitcoin Core that checks whether PSBT (Partially Signed Bitcoin Transaction) data can be serialized and then deserialized back to the exact same bytes. It is a defensive test meant to catch future bugs where the software might write a PSBT format it cannot later read. The commit itself does not fix any active vulnerability; it adds a regression test.

This commit fixes a flaky automated test in Bitcoin Core. It replaces a complicated node restart/sync dance with a simpler helper that manually copies blocks between test nodes via RPC. There is no change to production code, no security fix, and no vulnerability.

This commit swaps the internal macro used to detect Windows builds in a third-party subprocess helper header. Previously the code checked for Microsoft Visual C++ or MinGW compilers to decide 'this is Windows'; now it uses the standard WIN32 macro. There is no change to actual program logic, only to the condition that selects Windows-specific versus Unix-specific code paths. It is a portability/build cleanup, not a security fix.