Bitcoin Core

This commit is a straightforward internal code cleanup in Bitcoin Core's logging system. It renames a helper class and moves it inside another class, with no change to how log rate-limiting behaves. There is no security issue here.

This commit only changes Bitcoin Core's internal functional test code. It removes an old test helper flag called expect_disconnect that was used when sending invalid transactions during tests. The production Bitcoin node code that actually validates transactions and decides whether to disconnect peers is not changed at all. Therefore this commit does not fix or introduce any security issue in the live Bitcoin software.

This Bitcoin Core change removes a second, redundant check of transaction scripts when a transaction is rejected from the mempool. Previously, the software ran the expensive script check twice to decide whether a failure was a policy issue (like a non-standard signature) or a consensus issue (a rule everyone must agree on). Now it only checks once and reports a single mempool error. This is mainly a performance and code-simplification improvement; it does not change which transactions are accepted or rejected, only the exact error message returned and the internal work done.

This Bitcoin Core change removes the automatic disconnection and blacklisting of peers that send transactions considered invalid under network-wide consensus rules. Previously, sending certain consensus-invalid transactions would cause a peer to be 'misbehaved' and potentially disconnected. Now, such transactions are rejected but the peer stays connected. The stated goal is to avoid accidentally splitting the network if relay rules change, and because the protection was already ineffective against determined attackers.

This commit adds a warning for Bitcoin Core users on macOS who store their data or blocks directory on an exFAT-formatted drive. It does not fix a bug in Bitcoin Core itself, but warns users about a known filesystem reliability issue on macOS that has reportedly caused database corruption and data loss. There is no security vulnerability being exploited by an attacker.

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.

This commit changes how Bitcoin Core detects when a transaction's witness data has been stripped away. Previously, the software ran expensive script checks up to three times to figure out if a transaction failed only because its witness was missing. The new code detects the same condition with a cheaper check, but it may label some transactions as 'witness stripped' even when they are invalid for other reasons. The change is a performance and correctness refactor, not a fix for an active exploit, though the underlying behavior affects how the network handles invalid transactions.

This commit removes a special exception that let the bitcoin-util program skip a security hardening check. The check verifies that important memory-copying functions use a safer fortified version. The exception is no longer needed because bitcoin-util now includes those safer functions. This is a minor hardening improvement, not a fix for an active security flaw.

This commit is a routine update of the English translation source files used by the Bitcoin Core graphical user interface (GUI). It regenerates the list of user-visible strings so translators can keep localizations in sync with recent source-code changes. There are no code behavior changes, no bug fixes, and no security changes in this patch.

This commit only fixes grammar mistakes in user-facing error messages and log strings. No code behavior, logic, or security properties are changed.

This commit changes a single identifier in the Transifex translation service configuration file, switching the project slug from 'qt-translation-029x' to 'qt-translation-030x'. It has no effect on Bitcoin Core's code, network behavior, wallet operations, or security. It is purely a housekeeping update for the upcoming 30.x release branch's translation workflow.

This commit is a routine subtree update that imports the upstream Google CRC32C library into Bitcoin Core's source tree. It adds the entire CRC32C codebase (build files, headers, implementations, and tests) but makes no changes to Bitcoin Core's own logic. There is no indication of a security fix or vulnerability in the commit message or diff.

This commit simply updates the version of a link-checking tool (mlc) used in Bitcoin Core's automated CI linting from v0.19.0 to v1. There is no code change affecting Bitcoin Core itself, its consensus rules, networking, wallet, or any user-facing functionality. It is a routine dependency bump in a developer-only script.

This commit simply updates the version of a code-quality tool called ShellCheck used in Bitcoin Core's automated checks, from version 0.8.0 to version 0.11.0. It does not change any code that runs the Bitcoin network software itself, nor does it fix or introduce any security vulnerability in Bitcoin Core.

This commit fixes a single typo in a documentation file. It changes '5satvB' to '5sat/vB' in a comment explaining Bitcoin transaction fee policy. There is no code change and no security impact.

This commit fixes two spelling mistakes in code comments and test documentation. One changes 'possibile' to 'possible' and the other changes 'returned' to 'return'. There are no code behavior changes, no security fixes, and no functional modifications.

This commit is a simple typo fix in a test file. It renames a local variable from 'shuffled_indeces' to the correct spelling 'shuffled_indices'. There is no change to Bitcoin Core's actual network code, consensus rules, wallet handling, or any user-facing behavior. It only affects an internal variable name in a functional test.

This commit fixes a spelling mistake in a documentation file. It changes 'expensive_calulation' to 'expensive_calculation' in a code example within a markdown document. There is no code change that affects how the software runs, and no security risk is present.

This is a harmless build-system change. When the Bitcoin Core build configuration detects warnings, it now also prints an 'author warning' message. This does not change how the software runs, fix any bug, or introduce any security issue. It only affects how warning messages are displayed to developers during configuration.

This commit adds a new automated test file for Bitcoin Core. It does not change any production code, network rules, or wallet behavior. The test verifies that an internal caching optimization for signature hash calculations returns correct results and does not accidentally reuse values when inputs change. There is no security fix or vulnerability here.

This commit adds a new automated test (a fuzz test) that checks Bitcoin Core's signature hash calculation behaves identically whether or not a performance cache is used. It does not change production code, fix a bug, or introduce any user-facing behavior. It is purely a quality-assurance addition.

This commit adds a performance optimization to Bitcoin Core's transaction-signature checking. It caches an intermediate SHA256 hashing state so that repeated signature checks for the same transaction do not need to recompute as much. There is no indication in the commit or supplied references that this fixes a security bug; it is described purely as an optimization.

This commit is a code cleanup in Bitcoin Core's signature hashing function. It moves the invalid SIGHASH_SINGLE check earlier and consolidates the final hashing step so both code paths use the same HashWriter. There is no security bug being fixed here; it is preparation for a future performance improvement (a sighash midstate cache).

This commit only adds new test cases to Bitcoin Core's functional test suite for Taproot and legacy transactions. It does not change any production consensus, networking, or wallet code. The tests verify that 'sighash caching'—an optimization nodes use when computing transaction signatures—behaves correctly across OP_CODESEPARATOR positions and different signature hash types. There is no indication this commit fixes a live bug or introduces a vulnerability.