Bitcoin Core

This is a small fix inside Bitcoin Core's internal fuzz-testing harness. Fuzz testing feeds the program many random inputs in sequence; the harness is supposed to reset global state between inputs so each test starts clean. The reset code already cleared the regular mock clock but forgot to clear a separate 'steady' mock clock. That meant one fuzz input could leave a fake time value behind, polluting later inputs and making fuzz results less reliable. The patch adds one line to clear that steady mock clock too. It is a test-infrastructure bug, not a vulnerability in live Bitcoin node code.

This commit adds support for a new Bitcoin peer-to-peer message type called FEATURE, defined in BIP 434. It is infrastructure for negotiating optional protocol features during the initial handshake, not a finished feature itself. The code bumps the protocol version to 70017, registers the new message, and adds basic rules: FEATURE messages must appear between VERSION and VERACK, the peer must have negotiated the new version, and the payload must contain a feature ID of at least 4 characters plus up to 512 bytes of feature data. Unknown feature IDs are ignored. There is no immediate security issue visible in the diff, but the change touches network message handling and version negotiation, which are sensitive parts of the node.

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 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 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 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 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.

This commit fixes a memory safety bug in Bitcoin Core's block validation. When checking a new block, the program creates a queue of script checks that may run on multiple threads in the background. It also precomputes some transaction data used by those checks. Previously, the precomputed data was destroyed before the background check queue finished, so the workers could read memory that had already been freed. An attacker could craft a malicious block to trigger this, potentially causing crashes, memory corruption, or worse. The fix simply moves the precomputed data variable so it is created before the queue and destroyed after it, guaranteeing the data stays alive as long as the checks need it.

This commit changes a Bitcoin Core internal helper function so that it can now report failure when a PSBT (Partially Signed Bitcoin Transaction) is internally inconsistent. Previously, the helper would build transaction precomputation data without checking whether the underlying unsigned transaction could actually be constructed. Now it returns an optional value that callers must check, and they reject or abort the operation if the transaction cannot be valid. This is a defensive hardening change that prevents the code from continuing with malformed PSBTs.

This commit is a straightforward internal code cleanup in Bitcoin Core. It moves a helper function that looks up the previous transaction output (UTXO) for a PSBT input from the whole-transaction object (PartiallySignedTransaction) into the input object itself (PSBTInput). The behavior is unchanged; only the code organization is simplified.

This commit updates the Bitcoin Core 'decodepsbt' RPC command so it can display the newer PSBT version 2 format. It only changes what information is shown to the user; it does not change how transactions are validated, signed, or broadcast. There is no indication this is a security fix.