Bitcoin Core

This commit simply adds a new documentation file containing the release notes for Bitcoin Core version 30.2. It does not change any program code, configuration, or build scripts. There is no security-relevant change in the diff itself.

This commit only changes Bitcoin Core's internal test framework. It switches test-only SOCKS5 proxy and P2P mock servers to use dynamic port allocation (port=0) so automated tests are less likely to fail with 'address already in use' errors. There is no change to production Bitcoin node code, no user-facing behavior change, and no security vulnerability being fixed.

This commit adds an exception list to Bitcoin Core's commit-verification tool. Normally the tool rejects commits whose verification uses the older SHA-1 algorithm. The change lets one specific commit (aeaa67a9eac0decb89c60a67f9755ca10cbcc1d9) skip that SHA-1 check. It is a maintenance/operational tweak rather than a fix for a runtime vulnerability in Bitcoin itself, but it weakens a security control for that one commit.

This is a minor fix to a Bitcoin Core functional test, not to the main Bitcoin software. It moves an 'import random' statement to the top of the test file and changes one test helper to use a wallet-provided output script instead of a hardcoded one. There is no security issue in the production code and no vulnerability being patched.

This is a small internal code cleanup in Bitcoin Core's transaction acceptance logic. It moves a check so that a package-replacement-specific validation routine is only called when actually processing a package RBF (replace-by-fee), rather than having that routine itself decide to return early when there is no conflict. The change does not alter the overall validation outcome and is described by the author as a refactor.

This commit removes a single internal safety check (an 'Assume' assertion) in Bitcoin Core's wallet code. The assertion could incorrectly fail during a blockchain reorganization, causing the wallet process to abort unexpectedly. Removing it prevents a potential crash, but does not by itself fix any underlying logic bug in how transactions are handled.

This commit only changes a test file. It renames a test method and adds explicit checks that a wallet finishes rescanning after restarting pruned Bitcoin nodes. There is no change to production code, no fix for a live bug, and no security-relevant behavior change in the software users run.

This commit only changes a test file. It refactors an existing test for failed wallet migration and adds more test cases for wallets with relative and absolute paths. There is no change to production wallet code, so it does not introduce or fix a security issue in the software users run.

This commit fixes a minor behavior bug: if a user interrupted Bitcoin Core while it was starting up, the program would wrongly report that it had failed (non-zero exit code). The change makes an interrupted startup return a normal success exit code, matching how an interrupt is treated after startup is complete. It also updates the graphical (GUI) startup path to recognize when the user asked for shutdown during initialization.

This commit simply adds a new trusted PGP key to the list used by Bitcoin Core's commit verification script. It is an administrative change, not a code fix or vulnerability patch. There is no indication of a security issue being addressed.

This commit fixes an internal consistency check in Bitcoin Core's mini-miner, a testing and block-template simulation tool. Previously, the code assumed that a transaction's total fees including ancestors were always at least as large as the transaction's own fee. That assumption can be false when a user uses the prioritisetransaction feature to assign a negative fee to a transaction. The old assumption could cause debug builds to abort (via Assume) or mask incorrect accounting, though this appears limited to the mini-miner and not consensus-critical mining code.

This change adds a safety check to a Bitcoin Core fuzz test (an automated testing harness, not production wallet code). It rejects fuzz inputs that would create descriptor strings with unusually long 'leaf' segments before feeding them to the wallet's descriptor parser. The goal is to prevent the fuzzer from wasting time or hitting limits on pathologically large inputs, not to fix a user-facing security bug.

This is a small change to a Bitcoin Core fuzz test (a developer testing tool that feeds random data to code to find bugs). It makes the test skip more kinds of unusually complex descriptor strings so the fuzzer spends time on realistic inputs instead of wasting compute on pathological ones. It does not change any production wallet or network code, so it has no direct effect on real users' funds or node security.

This commit fixes a build-time test failure in the software packaging process. The osslsigncode tool's own test suite started failing because it contains a hardcoded check that expires after 2025. The fix makes the tests run as if the date were January 1, 2025, so they pass again. This is a build/test maintenance change, not a security fix for Bitcoin Core itself.

This is a small code cleanup in Bitcoin Core's internal fuzz-testing utilities. It swaps one type name for another that behaves identically and removes some unnecessary 'const' keywords. There is no change to how the software runs or any security fix.

This is a fix to a Bitcoin Core functional test, not to production wallet code. The test was predicting a backup filename based on a cached mock time, but the helper it called also changed mock time internally, which could make the predicted filename wrong and cause the test to fail. The fix calls the migration RPC directly and copies a wallet file explicitly. There is no security issue in the Bitcoin Core software itself.

This commit only adds a new test case to Bitcoin Core's functional test suite. It checks that the wallet's listdescriptors command, when asked to include private keys, still works correctly even when some descriptors were imported with only public keys (missing private keys). There is no change to production wallet code, no bug fix, and no security patch.

This commit tightens a Bitcoin Core wallet RPC command so that watch-only wallets (which intentionally never store private keys) can no longer be asked to export private-key versions of their descriptors. Previously, the command would attempt to produce a private descriptor string and fail with a generic error; now it rejects the request up front with a clear message. It also replaces an error-handling path with an internal consistency check. The change is defensive and reduces the chance of misleading behavior or future bugs, but it does not appear to expose funds on its own.

This Bitcoin Core change alters how wallet descriptors are printed when some (but not all) private keys are present. Previously, exporting a private descriptor would fail entirely if any single key was missing. Now it succeeds and exports the private keys it does have, falling back to public keys for the rest. The commit message and code comments frame this as a usability improvement for multi-key descriptors such as taproot (tr()). There is no direct evidence in the commit of a security vulnerability being fixed; it appears to be a behavior change that could affect information disclosure expectations.

This commit refactors how Bitcoin Core's descriptor code turns key information into text when private keys are requested but not available. Previously, if any private key was missing, the whole private-string output could be dropped or partially empty. Now the code falls back to including the public version of the missing key instead, and reports whether any private keys were actually included. It is a behavior change in output formatting, not a fix for an active exploit, and the commit message explicitly calls it setup for a later change.

This is a small internal refactoring change in Bitcoin Core's wallet migration code. It swaps one method for another when deciding whether a wallet descriptor should be treated as watch-only during migration. The commit message says this is to keep the current pull request focused on RPC behavior and that a follow-up change may refine the logic later. There is no direct evidence in the commit of a security bug being fixed.

This commit adds a new helper function called HavePrivateKeys() to Bitcoin Core's descriptor system. It is a preparatory refactor: it gives the code a clearer way to check whether a wallet descriptor is 'watch-only' (has no private keys) before an upcoming change to ToPrivateString(). The commit itself does not change user-visible behavior; it only introduces the new check and updates tests to use it. There is no direct evidence in the commit that this fixes an active security bug, but it is clearly related to correctly identifying whether private keys are present, which can affect wallet security logic.

This patch fixes a cleanup routine in Bitcoin Core's wallet tool. Previously, when creating a wallet from a dump file failed, the tool used a broad 'delete everything in this directory' command. The change makes it delete only the specific files that belong to the wallet it just created, reducing the risk of accidentally wiping unrelated files or directories.

This commit only adds new test code. It introduces test vectors for BIP 328 (a Bitcoin improvement proposal related to the MuSig2 multi-signature scheme) to verify that public-key aggregation and synthetic extended-public-key generation produce expected outputs. No production code is changed, so it cannot directly introduce a runtime security vulnerability.

This commit fixes a naming bug during Bitcoin Core wallet migration. When a user migrates the default wallet (which has no name), the newly created watch-only and solvables wallets were being given names like '_watchonly' and '_solvables' instead of 'default_wallet_watchonly' and 'default_wallet_solvables'. The fix applies the same 'default_wallet' prefix already used for backup files. This is primarily a correctness and usability fix, not a security vulnerability, though the resulting name collision could theoretically cause migration failures or confusion.