Bitcoin Core

This commit is a small, additive change to Bitcoin Core's public-key derivation code. It adds an optional way for callers to retrieve the 'tweak' value used when deriving child public keys under the BIP32 standard. The change is needed so that a newer multi-signature scheme called MuSig2 can sign with derived keys. There is no direct evidence in the commit that this fixes a security bug; it appears to be a feature or API improvement.

This commit fixes a capitalization typo in the help text for the `finalizepsbt` RPC command. The documentation previously referred to `final_scriptWitness` but the actual PSBT field name is `final_scriptwitness` (all lowercase). This is purely a documentation string change and has no effect on code behavior, transaction processing, or security.

This commit swaps one continuous-integration (CI) test runner from CentOS to Alpine Linux (musl). It only changes build/test automation files, not the Bitcoin Core software that users run. There is no security-relevant code change here.

This commit fixes a math bug in the Bitcoin Core block-building code. The original code subtracted a safety margin from the maximum block weight and then compared the current block weight to that lower number. Because the variables are unsigned integers, if the block weight was already larger than expected, the subtraction could underflow and wrap around to a huge number, making the comparison behave incorrectly. The fix rewrites the comparison as an addition on the other side, which cannot underflow. The practical effect is on when the miner decides to stop trying to add more transactions; the bug could make it give up too early or keep going too long in edge cases.

This commit is a routine Bitcoin Core merge that increases the rate at which transactions are relayed to peers (from 7 to 14 per second for inbound peers, and up to 35 for outbound peers). It is described by the project as a safety-margin improvement to keep per-peer inventory queues from growing too large when blocks contain many small transactions. The change is a single constant tweak in the P2P networking code and is not presented as a security fix.

This commit is a test-only bugfix for the Bitcoin Core QA suite. It changes the rpc_bind functional test so that it skips the non-loopback network binding test when the machine running the tests has no non-loopback IP address available. It does not change any production code that runs on real Bitcoin nodes, wallets, or miners, and therefore has no direct security impact on users of the software.

This commit only rewords a log message and updates the matching test. It changes 'signature validations' to 'script verification' in a progress/debug log line and fixes a typo in a comment. There is no functional code change and no security impact.

This commit adds a simple helper function that asks the operating system how much total physical memory (RAM) the computer has. It supports Linux, macOS, and Windows, and returns no value on other platforms. It also adds a test to make sure the reported number looks reasonable. There is no security issue visible in this change.

This commit is a code-quality and performance cleanup, not a security fix. It changes many Bitcoin Core calls to the libsecp256k1 cryptography library so they use a shared, read-only 'static context' instead of a special signing context. The signing context is only needed for operations that actually multiply a secret key with a generator point, such as creating public keys or signing. Using the static context elsewhere is harmless and matches the library's documented recommendations. There is no indication this fixes an active vulnerability.

This change fixes a logic issue in Bitcoin Core's network handling. When a node operator configures special permissions (like bypassing connection limits or relay rules) for specific IP addresses, those permissions were mistakenly being granted to inbound connections arriving through a Tor hidden service. Because Tor hides the true IP address of the connecting peer, the node cannot verify that the peer actually belongs to the whitelisted address range. The patch ensures that whitelist permissions are not applied to Tor inbound connections, so only connections whose real network address is known can receive those privileges.

This is a small CMake build-system fix. A command that tells the build system to use the C programming language was moved from inside a function to the top of the file. The old placement could cause CMake configuration to fail or behave incorrectly when building the secp256k1 cryptographic library, but it does not change how the Bitcoin software itself runs or processes transactions.

This commit is a routine code cleanup that adjusts which header files are included in the cryptographic source files. It does not change any program logic, algorithms, or security behavior. The goal is to make the include lists match what the compiler actually needs, which helps maintainability and tooling but has no direct security impact.

This commit fixes a formatting bug in benchmark output. The SHA256AutoDetect function returns a string describing which CPU-accelerated SHA-256 implementations are active. That string previously used commas, which broke CSV-formatted benchmark reports because commas are the field separator. The patch swaps commas for semicolons so benchmark CSV files parse correctly. It is a data-formatting fix, not a security fix.

This commit fixes an integer overflow bug in Bitcoin Core's optional coin statistics index. The index keeps running totals of spent and created coins, and on long-running or high-activity networks these totals could exceed the range of the 64-bit 'CAmount' type, causing wrong statistics or node instability. The fix widens the at-risk totals to a 256-bit type and removes a redundant stored total that can be computed from other values. It also changes the index's database directory name so upgraded nodes do not reuse the old, buggy data, while leaving the old directory in place for users who might downgrade.

This commit is not a focused code patch. The supplied diff shows the addition of thousands of unrelated repository files (CI configs, templates, build files, documentation, source trees, etc.) under a commit title that only mentions a GCC/systemtap tracing workaround. The actual claimed change is not visible in the provided diff, so there is no basis to assess any security issue.

This commit fixes how Bitcoin Core reads network routing information from the Linux kernel. Previously, the code only made one request and could receive incomplete routing data on systems with large routing tables, or could hang waiting for a 'done' signal that never comes. The fix loops to collect all kernel response parts and only waits for the 'done' marker when the kernel says the response is multi-part. This is a reliability bug fix, not a direct money-stealing vulnerability, but incorrect routing data could affect how the node connects to peers.

This commit updates a regular expression in a seed-node generation script so it recognizes newer Bitcoin Core version numbers (28.2 and 29.0) when scanning network peers. It is a routine maintenance change to the list of acceptable user-agent strings and does not alter node consensus, wallet, or network security code.

This commit simply raises the minimum block-height thresholds used by a Bitcoin Core maintenance script that builds the list of hard-coded network seed nodes. It is a routine configuration update, not a code fix for a security vulnerability.

This commit simply refreshes Bitcoin Core's built-in list of 'fixed seeds'—the fallback network addresses new nodes use to find peers when DNS seeders are unavailable. It removes old seed entries and adds new ones. There is no code change, no bug fix, and no security patch in the diff itself. It is a routine network-address list update.

This commit updates the libmultiprocess subtree used by Bitcoin Core. The most notable change is a build-time guard that refuses to compile against specific old versions of the Cap'n Proto library because those versions contain a known memory-access vulnerability (CVE-2022-46149). The commit also adds CI testing for older Cap'n Proto versions and OpenBSD, fixes a C++20/Cap'n Proto 0.8 compatibility issue in the code generator, removes an obsolete linker flag, and adds a missing include. It is primarily a hardening and compatibility update, not a fix for a new vulnerability in Bitcoin Core itself.

This commit only changes Bitcoin Core's own test code and test framework. It fixes how the test suite encodes the 'code separator position' used in Taproot signature hashing, switching from a signed 32-bit integer to an unsigned 32-bit integer. It also adds two new test cases that check what happens when an invalid code-separator position is used. There is no change to the actual consensus or networking code that runs on the Bitcoin network, so this does not create or fix a live security vulnerability in Bitcoin Core itself. It is a test-coverage improvement.

This commit adds a new 'version' parameter to several Bitcoin Core RPCs so users can create version 3 transactions. It is a feature addition, not a bug fix. The code validates that the requested version is within the allowed standard range and applies sensible defaults, so it does not appear to introduce a security vulnerability.

This commit is a routine localization fix for Bitcoin Core's wallet. It makes the words '[default wallet]' in progress messages translatable, so non-English users see a fully translated message. There is no security impact.

This commit lowers Bitcoin Core's default minimum relay fee and replacement fee from 1000 satoshis per kilovbyte to 100 satoshis per kilovbyte. The stated goal is to make it cheaper for legitimate transactions to propagate while still keeping spam-based bandwidth attacks more expensive than renting commercial bandwidth. It is a deliberate policy change, not a code vulnerability, but it changes the economics of transaction relay and mempool replacement across the network.

This commit only adds user-facing log messages that announce when Bitcoin Core turns signature checking on or off during initial block download. It does not change whether signatures are checked, only how clearly the node tells the user about it. There is no security vulnerability here.