Bitcoin Core

This is a one-line change in Bitcoin Core's internal test framework. It only affects how error messages are displayed when a test RPC call times out, suppressing an extra Python traceback. It does not change any production code, network behavior, or security logic.

This commit fixes a subtle programming bug in Bitcoin Core's peer-to-peer networking code. A local network address score counter could, in theory, overflow when repeatedly incremented, which is 'undefined behavior' in C++ and could potentially cause the program to misbehave or crash. The fix makes the counter stop increasing once it reaches the maximum integer value, and adds tests to confirm that behavior.

This commit fixes a wallet migration bug in Bitcoin Core. When converting old-style wallets to modern descriptor wallets, the migration code could process the same BIP 32 seed more than once because it identified seeds by a 'seed ID' that changes depending on a technical detail (public-key compression) that does not actually affect the seed's value. The fix now detects duplicate seeds by comparing the derived master extended public key, preventing redundant or conflicting descriptors from being created during migration. There is no direct evidence this is exploitable as an attack; it appears to be a correctness and robustness fix.

This Bitcoin Core change narrows which version bits trigger live 'unknown soft fork' warnings from 29 bits down to 5, following the new BIP323 specification. It does not change how many bits exist in block headers or how test networks behave; it only reduces false or misleading upgrade alerts for bits that the network no longer treats as active deployment candidates.

This commit adds a safety check to Bitcoin Core's code that creates master cryptographic keys from a seed. The BIP32 standard says seeds must be 16 to 64 bytes long, but the function previously accepted any length, including empty seeds. The fix rejects out-of-range seeds with an internal assertion. It is a hardening change rather than a fix for an active exploit path, because callers in the current codebase already supply valid-length seeds.

This commit simply removes an unused helper function from a Guix build-attestation script. There is no change to how Bitcoin Core runs, no security fix, and no vulnerability introduced.

This change only adjusts Bitcoin Core's continuous integration (CI) test configuration. It tells the test runner to skip one specific test, feature_dbcrash.py, when running with certain command-line options because that test is extremely slow (about 47 minutes in one run). There is no code change that affects how Bitcoin nodes operate, and no security issue is present.

This commit only changes Bitcoin Core's own test code. It removes the obsolete -walletrbf startup option from two functional tests and adds a missing PSBT v2 field (fallback locktime) to a test helper that creates blank PSBTs. There is no change to production wallet or node code, so it does not affect real users' funds, transactions, or network security.

This change tightens two low-level math helper functions so they only accept whole-number (integer) types. Previously, a non-integer type could slip through and silently produce wrong min/max values because the generic fallback for numeric limits returns 0. The patch prevents that misuse at compile time rather than relying on an internal check.

This is a minor code cleanup in Bitcoin Core's test framework. It removes a lazy (deferred) import and replaces it with a normal import at the top of the file. There is no security issue here—it's purely a refactoring change to simplify the code after an earlier dependency cleanup.

This is a harmless internal code cleanup in Bitcoin Core's test suite. It moves a Python exception class named JSONRPCException from one test helper file (authproxy.py) to another (util.py) and updates the files that import it. There is no change to how Bitcoin nodes behave, no fix for a security bug, and no change that affects real users or live networks.

This commit is a routine infrastructure change for Bitcoin Core's continuous integration (CI) system. It switches the CI cache provider from Cirrus to GitHub's own cache service because Cirrus is being phased out and GitHub now offers more cache storage. The changes only affect how build artifacts and dependencies are stored between automated test runs; they do not modify the Bitcoin Core software that users run, nor do they introduce any known security vulnerability.

This commit refactors how Bitcoin Core's block builder (the miner) handles the maximum block weight setting. It replaces an older signed-size field with a new optional unsigned field and fixes a parsing quirk: a negative command-line value for -blockmaxweight is now treated as 0 before validation rejects it, instead of silently wrapping around to a huge positive number. The change is mostly a cleanup, but it removes a small overflow/underflow footgun in argument parsing.

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.

This commit only adds new regression tests for Bitcoin Core's PSBT (Partially Signed Bitcoin Transaction) combine/merge logic. It checks that custom 'proprietary' data fields are preserved when two PSBTs are merged at global, input, and output levels. There is no production code change, no bug fix, and no security patch in the diff itself.

This commit fixes a bug in Bitcoin Core's handling of PSBTs (Partially Signed Bitcoin Transactions). When two PSBTs were combined, the software correctly kept 'unknown' extra data but accidentally discarded 'proprietary' custom data fields added by wallets or tools. The patch makes sure proprietary fields are preserved during merging, preventing potential loss of transaction metadata that some wallets rely on.

This commit is a simple internal cleanup: it swaps the full logging header file for a smaller, more focused one in many source files. There is no change to program behavior, no bug fix, and no security relevance.

This commit tightens up error messages in Bitcoin Core's I2P (anonymous networking) code. Previously, error messages could accidentally include the full text of a SAM request that may carry the user's I2P private key, or the full raw reply from an I2P router. The patch keeps the error useful by still referencing the redacted request, but stops echoing the sensitive request body and unescaped router replies into logs. It is a defensive information-disclosure fix, not a change to network behavior.

This commit only adds a new test to Bitcoin Core's functional test suite. It runs each MuSig2 signing operation twice and checks that different nonces and partial signatures are produced each time. There is no change to wallet or consensus code, so it does not fix or introduce a vulnerability by itself. It is a defensive regression test aimed at catching nonce-reuse bugs in the future.

This commit is a pure code move: it takes the CreateMuSig2PartialSig function out of the CKey class in key.cpp/key.h and places it in the musig.cpp/musig.h module. The function's logic is unchanged, and the only caller is updated to use the new free-function name. There is no security fix or behavior change.

This is a minor test-only cleanup. It removes a TODO comment and two command-line flags that forced a specific address type in one of Bitcoin Core's automated functional tests. The change has no effect on production code, user wallets, or network behavior.

This commit is a defensive hardening change for Bitcoin Core's handling of BIP32 'chain codes'—secret-derived values used when creating child keys from a master key. Previously these values were stored as ordinary 256-bit numbers that could remain in memory after use. The change makes ChainCode a dedicated type that securely wipes its own memory when it goes out of scope, similar to how private keys are already handled. It is a preventive security improvement rather than a fix for an active exploit.

This change tweaks how Bitcoin Core's MuSig2 multi-signature code keeps track of active signing sessions. Previously, the session identifier was based only on the public keys and the transaction hash. Now it also includes each participant's public nonce. This matters because the same keys and transaction can legitimately be signed more than once, and without the nonce in the identifier the code could confuse two different signing sessions and risk reusing or misplacing secret nonce data. The commit itself is framed as a safety improvement, not a fix for a known active bug or exploit.

This commit fixes a bug in Bitcoin Core's descriptorprocesspsbt RPC command. Previously, the command could mark a partially-signed Bitcoin transaction (PSBT) as 'complete' and return a finalized transaction hex even when one of the signatures was actually invalid. The fix makes the command verify signatures cryptographically, not just check that signature data is present. The new test deliberately corrupts a signature and confirms the command now correctly reports the PSBT as incomplete.

This commit is a defensive hardening patch for Bitcoin Core's HMAC code. It wipes two temporary memory buffers that previously held sensitive key-derived data after the HMAC operation finishes. The change reduces the risk that leftover key material could leak through memory dumps, core dumps, or side-channel attacks, but it does not fix an active bug or known exploit.