Bitcoin Core

This commit is a build-system cleanup. It replaces the use of the external 'sed' tool with built-in CMake commands when processing a translation file. There is no security-relevant change to Bitcoin's runtime behavior, networking, wallet handling, or consensus logic.

This commit is a routine build-system cleanup for Bitcoin Core's Qt GUI translation tooling. It moves the logic for finding translatable source files out of the CMake configuration step and into a separate script that runs only when developers explicitly build the 'translate' target. There is no change to how Bitcoin handles money, network messages, wallets, or private keys, and no security issue is evident.

This commit simply adds a new read-only field called 'blockmintxfee' to the output of the getmininginfo RPC command. It exposes an existing configuration setting through the API so users can query it remotely. There is no security issue here.

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 is a test-only change in Bitcoin Core. It clarifies comments and strengthens a functional test for Replace-By-Fee (RBF) behavior when the incremental relay feerate is set to zero. No production code, consensus rules, or network behavior were modified.

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 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 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 only adds documentation: a new release-notes file describing upcoming support for version 3 (TRUC) Bitcoin transactions in several RPCs and the wallet. No code behavior changes are present in the diff.

This commit adds a new 'version' parameter to several Bitcoin Core RPCs so users can create version 3 transactions. It is a feature addition, not a bug fix. The code validates that the requested version is within the allowed standard range and applies sensible defaults, so it does not appear to introduce a security vulnerability.

This commit is a small code cleanup in Bitcoin Core's transaction acceptance rules. It replaces a hard-coded minimum transaction version check (the number 1) with a named constant TX_MIN_STANDARD_VERSION, which is also set to 1. By itself, this change does not alter network behavior or fix a known security bug; it only makes the code easier to read and maintain.

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 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 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 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 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 only updates documentation files that explain how to build Bitcoin Core. It adds instructions for installing the Cap'n Proto library, which is needed for a new optional IPC (inter-process communication) feature, and notes that IPC can be disabled if the dependency is unavailable. There are no code changes, no bug fixes, and no security-related changes.

This commit changes a single CI (continuous integration) test configuration file for CentOS. It tells the test runner to use the 'bitcoin-node' binary with multiprocess mode enabled when running functional tests. This is a testing infrastructure change, not a change to the Bitcoin Core software that users run.

This commit changes Bitcoin Core's build system so that multiprocess/IPC support is built by default in the depends system, rather than requiring an explicit option. It renames the option from MULTIPROCESS=1 to NO_IPC=1 (to opt out), adds IPC binaries to maintenance targets, and disables IPC only on Windows. There is no direct security fix or vulnerability being patched in the code itself; it is a build configuration change that increases the default attack surface by including more binaries and dependencies in releases.

This commit only changes Bitcoin Core's continuous integration (CI) testing setup. It renames one test job from 'multiprocess, i686, DEBUG' to 'no IPC, i686, DEBUG' and switches the build to disable inter-process communication (IPC) multiprocess support. There is no change to the actual Bitcoin node code that users run, so this cannot directly affect network security or user funds.

This change turns on a build option called ENABLE_IPC by default on Unix-like systems and installs the required capnp library in CI environments. It only affects how Bitcoin Core is compiled and tested; it does not change how ordinary users run the software. The change is a build-system/CI configuration update, not a fix for a known security bug.

This commit only adds a release note describing a previous change to error message wording in Bitcoin Core. It does not change any code, behavior, or security properties. The error strings were renamed from 'mandatory/non-mandatory-script-verify-flag' to 'block-script-verify-flag-failed' and 'mempool-script-verify-flag-failed' to make their meaning clearer. There is no security issue in this commit itself.