Bitcoin Core

This commit is a routine cleanup of Bitcoin Core's continuous integration (CI) scripts. It removes an unused environment variable called RUN_UNIT_TESTS_SEQUENTIAL and merges its behavior into the standard unit test path. There is no change to the Bitcoin software that users run, no security fix, and no vulnerability.

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 adds a small in-memory cache to Bitcoin Core's wallet so it can remember whether a transaction spends coins that belong to the wallet, instead of recalculating that fact every time it is needed. It is a performance and code-clarity change, not a fix for a known security bug. There is no evidence in the commit or supplied references that this addresses an active vulnerability.

This commit only adds a new automated test for Bitcoin Core's wallet behavior regarding 'anchor outputs'—a special zero-value or tiny output type used in some transaction protocols. It does not change any production wallet, node, or consensus code. The test verifies that the wallet can detect anchor outputs during a blockchain rescan but cannot spend them. There is no security vulnerability here.

This commit changes the Bitcoin Core wallet's 'sendall' RPC command so that instead of relying on an internal assumption that every coin's size is known, it explicitly checks whether the final transaction size can be calculated and throws a clear error if it cannot. Previously, the code used a non-fatal assertion that could be skipped in release builds, potentially allowing the command to proceed with an invalid or unknown transaction size when the wallet contained descriptors it could not fully solve.

This commit fixes a wallet accounting bug. Previously, Bitcoin Core's wallet decided whether a transaction came from the user by checking whether the total value of its inputs was greater than zero. That approach missed inputs that are worth exactly zero (so-called 'dust' outputs). After the change, the wallet checks each input individually to see if it is known to the wallet, so even zero-value outputs are correctly recognized as spent. This is mainly a correctness fix for tracking tiny outputs and could affect how transactions are labeled, but it does not appear to be a direct theft-of-funds vulnerability.

This commit adds a new automated test to Bitcoin Core's test suite. It checks that when a private key or descriptor is imported into a wallet, transactions already known to the wallet can change their 'from me' status, which affects whether the gettransaction RPC shows a 'fee' field and 'send' category. The commit itself is only a test file change and does not modify production wallet code.

This is a minor fix to Bitcoin Core's internal continuous integration (CI) test script. When a CMake build fails, the script prints diagnostic log files. The change ensures the script changes into the build directory first so the helper that lists log files can find them correctly. It does not change the Bitcoin software users run, does not touch networking or cryptography, and has no security relevance for end users.

This commit simply renames the macOS release ZIP file from 'Bitcoin-Core.zip' to 'bitcoin-macos-app.zip' before it gets its final distribution name. It is a build-system cleanup with no security relevance.

This is a small build-script cleanup for macOS packaging. It merges two command-line arguments into one so the script that creates the Bitcoin Core .zip file for Mac is slightly simpler. There is no security-relevant change.

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 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 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 is a cleanup of Bitcoin Core's internal functional test runner. It replaces a manual polling loop that repeatedly checked whether test subprocesses had finished with a standard Python thread-pool mechanism. There is no change to the Bitcoin network protocol, wallet handling, consensus rules, or any code that runs in production. It only affects how developers run tests locally and in CI.

This commit only updates documentation. It clarifies that a specific new type of Bitcoin transaction (TRUC transactions, defined in BIP-431) is allowed to have a lower fee than normally required, as long as the overall package of transactions meets the fee requirements. No code behavior was changed.

This commit adds a precomputed snapshot point for Bitcoin's testnet4 network at block height 90,000. This is a routine network configuration update that helps nodes start up faster by skipping historical validation up to that point. There is no indication of a security flaw or fix.

This commit adds a new precomputed snapshot point for Bitcoin's 'assumeutxo' feature at mainnet block height 910,000. This is a routine network-parameter update that helps new nodes sync faster; it does not change consensus rules, fix a bug, or introduce a security vulnerability.

This commit updates the internal tuning numbers used by Bitcoin Core's header synchronization feature. It pushes the expected network date forward by about six months and raises the minimum chain-work header count to reflect blockchain growth. There is no security vulnerability here; it is routine maintenance to keep the DoS-protection parameters aligned with the current and projected state of the network.

This commit updates routine network statistics in Bitcoin Core's chain parameters. It refreshes the recorded time, total transaction count, and transaction rate for mainnet, testnet, signet, and regtest networks based on recent blockchain data. There is no security issue here—this is normal maintenance data that helps the software estimate sync progress and blockchain size.

This commit updates two routine Bitcoin network parameters—'minimumChainWork' and 'assumevalid'—to point to newer, well-mined blocks on the main network, testnet, and signet. These values tell a freshly started Bitcoin node how much proof-of-work history it should require before trusting the chain it sees. The change is a standard, scheduled maintenance update and does not fix a software bug or introduce a known vulnerability. However, because these parameters influence which chain a node follows, setting them incorrectly could theoretically affect network behavior, so the commit touches a security-relevant part of the code.

This commit simply updates Bitcoin Core's built-in estimates of how much disk space the blockchain and chainstate database take up on mainnet, testnet, testnet4, and signet. These numbers are used to warn users if they don't have enough free space before downloading the chain. There is no security issue here.

This commit adds a safety check in Bitcoin Core's network message handling for a specific message type (GETBLOCKTXN). After reading the message, it verifies that a list of transaction indexes is strictly increasing. This is a defensive coding change: it does not fix a known exploit, but adds an assertion to catch invariant violations that could theoretically lead to incorrect behavior or crashes in compact block reconstruction. The change is small and uses the non-fatal Assume() macro, meaning a violation in release builds may not necessarily stop execution.

This commit adds a new automated fuzz test for a Bitcoin Core data-formatting helper called DifferenceFormatter. It does not change any production code, network behavior, or wallet logic. It only adds a test file and registers it in the build system. There is no security fix or vulnerability present in the diff.

This commit only updates the project's code-formatting configuration file (.clang-format) and a one-line clarification in the developer style guide. It changes how source code is automatically laid out (indentation, brace placement, line breaks) but does not change any program logic, network behavior, wallet handling, or cryptographic operations. There is no security relevance.

This commit simply deletes two helper shell scripts used by the project's continuous integration (CI) system for running code linting checks. There is no change to the Bitcoin software itself, its consensus rules, networking, wallet, or any user-facing functionality. It is a routine cleanup of unused CI files.