Bitcoin Core

This commit only changes a patch file used by the continuous-integration (CI) 'include what you use' (IWYU) linting tool. It tells the linter to recommend C++ standard headers (like <cstdio>) instead of C-style headers (like <stdio.h>) when reviewing Bitcoin Core source code. The change does not alter any compiled Bitcoin Core code, runtime behavior, or network protocol, so it has no direct security impact on users running Bitcoin Core.

This commit is a build-tooling change only. It adds a patch for the Include What You Use (IWYU) static-analysis tool used in Bitcoin Core's continuous integration (CI). The patch forces IWYU to suggest C++ #include statements using angle brackets (<...>) instead of quoted local paths ("..."). There is no change to Bitcoin Core's actual consensus, networking, wallet, or node code, and no security-relevant behavior is modified.

This commit changes Bitcoin Core's logging system so that when the optional -logsourcelocations setting is enabled, log lines show only the simple function name (e.g., 'ProcessMessage') instead of the full C++ function signature (e.g., 'void ProcessMessage(...)'). It introduces a small wrapper class around std::source_location to allow overriding the function name with the __func__ macro. There is no security fix here; it is a user-facing log-format cleanup.

This commit is a portability fix for compiler warnings about missing braces when initializing IPv6 address constants. It introduces platform-specific macros so the code compiles cleanly on illumos and Microsoft Visual C++ without changing behavior. There is no security issue here.

This commit is a documentation-only cleanup. It replaces an outdated example fuzz target name (address_deserialize_v2) with the current name (address_deserialize) in a user guide and a code comment. No executable code, logic, or security behavior is changed.

This commit simply moves a constant named MAX_BLOCK_TIME_GAP from one source file (src/chain.h) to another (src/qt/bitcoingui.cpp). The value and its meaning stay exactly the same. It is a code-cleanup change with no functional or security effect.

This is a tiny fix to a Bitcoin Core internal QA test script. A previous change tried to make a subprocess error message readable by enabling text mode, but Python still stores the output as bytes in TimeoutExpired exceptions. The patch adds an explicit .decode('utf-8') so the test's debug printout works instead of crashing with a bytes/string formatting error. It only affects test failure diagnostics, not live Bitcoin node code, wallets, consensus, or network behavior.

This is a small cleanup in Bitcoin Core's internal test helper code. It changes how an error message is re-raised so that Python no longer prints a confusing 'another exception occurred' chain when a test node fails to start. There is no change to the Bitcoin network protocol, wallet handling, consensus rules, or any production code.

This commit only adds a new automated test to Bitcoin Core's internal quality-assurance suite. It checks that a helper function used during testing raises exactly one exception when a node startup error does not occur within the expected timeout. There is no change to production code, no user-facing behavior change, and no security vulnerability being fixed.

This is a minor improvement to a Bitcoin Core test script. It adds clearer debug logging when a test child process produces the expected output, and it handles the edge case where a timeout occurs with no captured output. There is no change to the actual Bitcoin Core software that users run, and no security issue is present.

This is a small test-code cleanup that moves a helper for calculating RPC timeout into a reusable mixin. It does not change Bitcoin Core's production code, network behavior, or wallet security. There is no vulnerability here.

This commit only changes an error message in a test file so that when a test fails, it prints the HTTP reason phrase (like 'Not Found') alongside the status code. It does not change any production code, user-facing behavior, or security logic.

This commit only adds a new automated test to Bitcoin Core's REST interface test suite. It checks that the /blockpart/ endpoint correctly rejects unsupported request types with proper error messages. There is no code change to the actual REST server behavior, and no security vulnerability is being fixed.

This commit is a bulk update of copyright notice years in source-code comments. It changes phrases like '2012-2022 The Bitcoin Core developers' to '2012-present The Bitcoin Core developers' across 988 files. There are no changes to program logic, no bug fixes, and no security-related code changes.

This commit changes Bitcoin Core's GitHub Actions CI workflow so that when a Windows cross-build job runs, a separate job records the exact commit ID being built, and the follow-on native Windows test job checks out that same recorded commit. This prevents a race condition where a new commit pushed during the cross-build could cause the native tests to run against different source code than what was compiled. It is a CI reliability improvement, not a security fix.

This commit only adds documentation: a release note describing a previously merged privacy feature (PR #29415). It does not change any code, so it cannot introduce or fix a security vulnerability on its own. The feature it describes lets users optionally broadcast transactions only over Tor or I2P to hide their IP address and avoid linking separate transactions.

This commit only adds a new unit test file for an existing feature called private broadcast storage. It does not change any production code, so it cannot introduce a security vulnerability or fix one on its own.

This commit only adds a new automated test file for Bitcoin Core's existing 'private broadcast' feature. It does not change any production code, so it cannot introduce a security vulnerability or fix one. The test verifies that transactions submitted through the RPC are broadcast privately over Tor/I2P-style connections and checks related edge cases.

This commit updates the sendrawtransaction RPC command so that, when the optional -privatebroadcast setting is enabled, it broadcasts raw transactions over privacy-preserving networks (Tor/I2P) instead of sending them to all connected peers. It also adds a check that at least one of those networks is reachable, and updates the command's help text. There is no direct evidence in the commit of a security vulnerability being fixed; it appears to be a privacy feature enhancement.

This commit adds a retry mechanism for a new optional 'private transaction broadcast' feature in Bitcoin Core. If a transaction sent privately isn't seen back from the network within about a minute, the node schedules extra private outgoing connections to rebroadcast it. It is a feature-completion patch, not a fix for an active vulnerability, and it does not appear to introduce obvious security bugs on its own.

This Bitcoin Core change improves how the node stops privately re-broadcasting a transaction once it sees that same transaction come back from the network. It is a hardening/efficiency fix for the new private transaction broadcast feature, not a fix for a known remote exploit. The patch makes the node stop its private re-broadcast attempts when the exact transaction it sent is seen again, while still continuing to broadcast the original if a peer returns a malleated (altered-witness) version.

This commit adds a new 'private broadcast' feature in Bitcoin Core that lets users send transactions through short-lived, disguised peer connections to reduce the risk that someone watching the network can figure out which IP address originated a transaction. The patch also fixes a related privacy leak: without the change, a malicious peer could have tricked the node into revealing its real network address during one of these private broadcasts. The commit is defensive and improves privacy, but it is a new and complex network feature, so it deserves careful review.

This commit simply moves an internal consistency check (an `Assume()` assertion) to an earlier point in the code that handles a peer's VERACK message. The check itself and the surrounding logic are unchanged. The author explicitly states this is a non-functional change, meaning it does not alter program behavior in release builds or fix any active bug.

This is a straightforward code cleanup in Bitcoin Core's network handshake routine. It renames local variables, splits declarations from assignments, and merges two nearly identical log lines into one. The commit message explicitly calls it a non-functional change, and the diff shows no altered behavior, no new network data, and no changed security checks.

This commit simply moves a diagnostic log message that records receipt of a peer's VERSION message to an earlier point in the network processing code. It does not change any protocol behavior, validation logic, or security checks. The change only affects debug logging output, making it more likely the log line is printed even if the connection is interrupted shortly after receiving VERSION. There is no security issue here.