Bitcoin Core

This is a minor GitHub Actions CI configuration fix. It moves a comment onto its own line so that the cache save and restore steps use identical path patterns. There is no security issue in the code change itself.

This is a routine Continuous Integration (CI) script cleanup. It turns on a stricter shell error mode (`pipefail`) and adjusts how build statistics are parsed so the script keeps working. There is no user-facing Bitcoin node behavior change and no security issue.

This commit simply removes two unused library links from the build configuration for bitcoin-cli, the command-line tool. There is no code change and no security issue is indicated.

This commit replaces the HTTP client library used by bitcoin-cli (libevent) with a new custom-built HTTP client. It is a large refactoring change that touches network communication, credential handling, and error messages. There is no direct evidence in the commit that this fixes a known security bug, but any rewrite of network and authentication code carries a risk of introducing subtle bugs in how bitcoin-cli talks to the Bitcoin server.

This commit only changes Bitcoin Core's internal functional test code. It replaces hardcoded {'rules': ['segwit']} parameters with a shared constant NORMAL_GBT_REQUEST_PARAMS when calling getblocktemplate in tests. There is no change to production node code, no change to consensus rules, and no security fix or vulnerability introduced.

This commit simply marks an old wallet startup option called -walletrbf as deprecated. Since a recent release already makes all transactions replaceable by default, the option is now redundant. The change adds a warning when the option is used and updates tests to expect that warning. There is no security vulnerability here.

This is a routine Bitcoin Core change that hides an old transaction status field called 'bip125-replaceable' from wallet RPC responses by default, marking it as deprecated. Users can still get it back by starting the node with -deprecatedrpc=bip125. It is not a security fix and does not introduce a vulnerability; it is a user-interface/API cleanup following earlier changes that made transactions replaceable by default.

This commit only adds a new automated test for an existing Bitcoin Core data structure. It does not change any production code, network behavior, or wallet logic. There is no security issue here.

This commit fixes a bug in how Bitcoin Core lists external hardware wallets (signers). Previously, if the list contained duplicate signers, the code would stop processing entirely after the first duplicate, potentially hiding valid non-duplicate signers from the user. The fix changes the behavior so duplicates are skipped while the rest of the list is still processed. This is a correctness and usability fix rather than a direct theft-of-funds vulnerability, but it could mislead a user about which hardware wallets are available.

This is a straightforward internal code cleanup in Bitcoin Core's wallet migration feature. It changes how wallet names are passed around so that the code stores names directly in a result structure rather than fetching names from live wallet objects. There is no security-relevant change visible in the diff, and the commit message explicitly calls it a refactor.

This commit only updates hardcoded test data used by Bitcoin Core's internal unit tests. The data is a pre-generated regtest (regression test) blockchain, and the change regenerates it so the tests continue to work with the current code. There is no change to production code, no network-facing change, and no security fix or vulnerability introduced.

This change tightens a safety check in Bitcoin Core's transaction memory pool (mempool) handling. When a group (package) of related transactions is submitted and one fails a final consensus check, the code now removes that failing transaction plus every transaction that comes after it in the package. The commit message calls it a 'belt-and-suspenders' fix to prevent the mempool from becoming internally inconsistent if a parent transaction fails but a child transaction does not. It is a defensive hardening patch rather than a confirmed exploitable bug.

This commit is a straightforward internal code reorganization. It moves the logic that applies custom soft-fork activation settings from one place in the code to another, grouping it into a reusable helper function. There is no change to how Bitcoin Core behaves, no bug fix, and no security-relevant change visible in the diff.

This commit only adds new fuzz testing code and a sanitizer suppression for a known, harmless LevelDB sign-conversion issue. It does not change any production Bitcoin Core code, so it cannot introduce a runtime vulnerability in the software users run.

This change makes a LevelDB database file-size setting configurable rather than hard-coded. It is described by the author as useful for fuzzing (automated testing with random inputs). There is no direct security fix here; it is a test/development plumbing change.

This change adds a new testing-only option for Bitcoin Core's internal database wrapper. It lets fuzz tests and other test code inject a fake, deterministic LevelDB environment. It does not change normal node behavior and is not a security fix or vulnerability.

This commit simply moves a small helper function from one internal source file to a header file so it can be reused elsewhere. There is no change to what the function does, no bug fix, and no security-relevant behavior change.

This commit is a straightforward code cleanup: it adds a timeout parameter to a low-level network connection helper function. Existing callers keep using the same default timeout they used before, so observable behavior is unchanged. There is no indication this fixes a security bug.

This is a harmless code cleanup in Bitcoin Core's internal test framework. A developer extracted a small block of code that creates an RPC connection into a reusable helper function. No behavior changed, no user-facing code was modified, and there is no security issue.

This commit adds a small helper class for reading HTTP response headers in the bitcoin-cli command-line tool. It is purely new infrastructure code with no obvious security bug. There is no fix for a reported vulnerability and no indication this change itself introduces a vulnerability.

This is a tiny test-only change that adds a missing assertion in a unit test. It does not change any production code, network rules, or wallet behavior. There is no security issue here.

This commit only changes comments in a public header file. It clarifies that two Bitcoin kernel functions overwrite their validation-state output parameter rather than preserving any prior contents. No code behavior is changed, so there is no security impact.

This commit only updates comments and test-only assertions in a Bitcoin Core functional test file. It documents why a test can rarely fail and adds checks to make the test more robust. There is no change to production code, no security fix, and no vulnerability.

This commit is a small cleanup of a Bitcoin Core programming interface (API) used by the experimental 'libbitcoinkernel' library. It removes a redundant integer return value from the function that processes new block headers, so callers now rely only on the structured validation-state object to tell whether a header is valid. The change is not a security fix and does not appear to introduce a vulnerability; it mainly makes error handling less ambiguous for developers.

This commit fixes a small but real bug in Bitcoin Core's MuSig2 multi-signature helper. Previously, if someone asked the code to aggregate an empty list of public keys, it would pass an invalid empty list deeper into the cryptographic library, which could cause undefined behavior or a crash. The change now rejects an empty list immediately and returns a failure, and a test was added to make sure this stays fixed.