Bitcoin Core

This commit only changes Bitcoin Core's internal functional test scripts. It fixes log-message formatting, adjusts test thresholds and comments to match current fee-relay behavior, and adds one extra test case for a v3 transaction package. None of these changes affect the live Bitcoin node software, network protocol, consensus rules, or wallet code that users run.

This commit only updates documentation and code comments to match a previously merged change (PR 33106). It does not modify any executable network, consensus, wallet, or mempool code, so it has no security impact on its own.

This commit only adds new automated tests for Bitcoin Core wallet behavior with version-3 (TRUC) transactions. It does not change any production wallet, node, or consensus code. The tests verify that the wallet correctly handles TRUC size limits, version mixing rules, and mempool conflict tracking. There is no security fix or vulnerability introduced here.

This commit is a simple code cleanup in Bitcoin Core's test framework. It moves a helper function called bulk_vout from one test-only file to another so it can be reused by wallet tests. There is no change to the actual Bitcoin network code, consensus rules, or wallet logic that real users run.

This change adjusts how Bitcoin Core's wallet picks which unconfirmed coins it can spend. Specifically, when a new type of transaction called 'TRUC' (a v3 transaction) is involved, the wallet now only returns coins from one TRUC transaction at a time—the one with the highest total value—rather than returning coins from multiple unconfirmed TRUC transactions together. This is a defensive fix to avoid creating new transactions that would violate TRUC rules, which could otherwise cause the wallet's own follow-up transactions to be rejected by the network. It is more of a correctness/safety improvement than a direct theft or remote-exploitation bug.

This Bitcoin Core wallet patch prevents the wallet from trying to spend coins from an unconfirmed v3 (TRUC) transaction that already has a child transaction in the mempool. Because v3 transactions are only allowed a strict one-parent-one-child chain in the mempool, attempting to create a second child would be rejected by network policy. Without this fix, the wallet could waste time and fees building transactions that the network will never accept, and in some cases might temporarily lock up funds or produce confusing behavior. It is a correctness and usability fix rather than a theft or remote-code-execution vulnerability.

This Bitcoin Core wallet patch changes how the wallet selects unconfirmed coins to spend. It adds a filter so that when a user is building a transaction, unconfirmed ancestor or descendant coins are only used if their transaction version matches the version chosen for the new transaction. The commit title says these unconfirmed relatives are 'always TRUC' (a new v3 transaction version type). The change prevents mixing v3 (TRUC) and non-v3 unconfirmed coins in the same spend, which could otherwise cause the resulting transaction to violate network relay rules and get rejected.

This Bitcoin Core commit changes how transaction version numbers are handled when a user creates a transaction through the wallet. Previously, the version was optional and only set if the user explicitly provided one. Now it always defaults to the current standard transaction version. The commit message says this is needed so future code can rely on the version field when enforcing new 'TRUC' transaction rules. On its own, this is a small defensive cleanup, not a fix for an active exploit, but it prevents a class of future bugs where an unset version could lead to incorrect rule checks.

This Bitcoin Core wallet patch fixes how the wallet tracks conflicting transactions for a new type of transaction called TRUC (v3). TRUC rules allow only one unconfirmed child of a parent in the mempool at a time. The wallet now correctly marks other wallet transactions that spend from the same parent as 'mempool conflicts' when one TRUC child enters or leaves the mempool. Without this, the wallet could misreport whether these sibling transactions are spendable or likely to confirm, potentially leading users to make decisions based on stale or incorrect transaction state.

This Bitcoin Core commit tightens the wallet's coin-selection rules for a new type of transaction called 'v3' or 'TRUC' transactions. It makes sure the wallet does not accidentally build a transaction that is too heavy to be accepted by the network's memory pool. Without this change, a user could create a v3 transaction that the local node would reject, wasting fees or causing the wallet to produce an invalid transaction. It is a defensive correctness fix rather than an active exploit.

This Bitcoin Core wallet patch adds a safety check that stops users from accidentally mixing two different transaction formats (version 2 and the newer version 3, also called TRUC) in the same unconfirmed spend. Before this change, the wallet could let a user pre-select an unconfirmed input whose transaction version didn't match the version of the new transaction being built. That mismatch could produce an invalid or non-standard transaction, potentially causing the spend to be rejected by the network or by mempool rules. The fix makes the wallet detect the conflict early and return a clear error instead of silently building a problematic transaction.

This commit only adds a release note describing a new experimental mining interface and IPC-related build options. It contains no code changes, no bug fixes, and no security-related claims.

This commit is a pure code cleanup: it creates a single type name, script_verify_flags, and uses it everywhere script verification flags were previously written as uint32_t, unsigned int, or unsigned. The actual data type is still uint32_t, so behavior is unchanged. There is no security fix or vulnerability here.

This commit simply makes an internal helper function visible to other parts of the codebase. It does not change what the function does, what data it can access, or how Bitcoin validates blocks. There is no security issue here.

This commit is a code-quality refactor, not a security fix. It replaces a plain 32-bit integer type used for Bitcoin script verification flags with a dedicated C++ class that prevents accidental mixing with regular integers. The change makes the code safer to maintain but does not alter what the flags mean or how transactions are validated.

This commit is a straightforward code cleanup: it moves a helper that converts script verification flags into human-readable names from test files into a shared library location, and adds a small test for it. There is no change to how Bitcoin validates transactions or scripts, and no security fix.

This is a routine internal code cleanup in Bitcoin Core. It removes a redundant method called getActiveChainLocator and replaces its uses with an existing equivalent method, findBlock. There is no security fix here and no indication this change addresses any vulnerability.

This commit changes how Bitcoin Core's log rate-limiter is managed in memory. Previously, the scheduler held a raw pointer to the limiter, which could become invalid if the limiter was destroyed while a scheduled reset task was still pending. The fix makes the limiter a shared pointer and gives the scheduler only a weak reference, so the scheduled task safely does nothing if the limiter is gone. This is a defensive hardening change, not an active exploit fix.

This commit only changes a single functional test file. It explicitly sets the minimum relay transaction fee in the test setup so the test's assumptions about fees are clear. There is no change to production wallet, consensus, or networking code, and no security issue is present.

This commit removes shortcuts that let a new transaction ID type be silently treated as the older uint256 type. It is a code-cleanup change that makes type mismatches produce compile-time errors rather than compile silently. There is no direct evidence this fixes an exploitable vulnerability; it is a hardening/refactoring step.

This commit is a pure code reorganization: it moves a header file that defines transaction ID types (Txid, Wtxid) from one directory to another and updates all the places that include it. There are no functional changes to how Bitcoin Core behaves, and no security issue is present.

This is a code cleanup change that replaces generic 256-bit hash values with more specific transaction ID types (Txid and Wtxid) across many files. It does not change what the program computes or how it protects data; it only makes the type names more precise so developers can catch category mistakes at compile time. There is no indication this fixes a security bug.

This commit is a straightforward internal code cleanup in Bitcoin Core. It replaces the generic 256-bit hash type (uint256) with more specific transaction ID types (Txid and Wtxid) in the memory pool and related code. There is no change to network rules, consensus logic, or user-visible behavior, and no security vulnerability is introduced or fixed.

This commit is a code cleanup that replaces the generic uint256 type with a more specific Txid type when handling transaction identifiers in RPC commands and merkle block processing. It does not change program behavior, fix a bug, or introduce a security feature. It is a type-safety refactor intended to make the code clearer and harder to misuse in the future.

This commit adds a new internal helper function in Bitcoin Core that detects whether a transaction spends any Segregated Witness (Segwit) output, except for a special 'anchor' output type. It does not change network rules, user-visible behavior, or fix any bug by itself. It is a preparatory code change for future commits.