Bitcoin Core

This is a minor code cleanup in Bitcoin Core's network address handling. It replaces two separate calls that both retrieved the current time with a single shared call. There is no security-relevant change; the behavior is functionally identical.

This is a minor code cleanup that swaps one internal clock type for another equivalent one. It does not change what the program actually does, so it has no security relevance for users.

This commit changes only the internal test runner for Bitcoin Core. It forces Python's Global Interpreter Lock (GIL) to be enabled when running functional tests, because some optional Python libraries used during testing can misbehave or print warnings on newer 'free-threaded' Python builds where the GIL is disabled by default. There is no change to Bitcoin Core's production code, network behavior, wallet handling, or consensus logic.

This is a routine code cleanup: a missing standard library header is added to one central file, allowing nine other files to stop including it directly. It does not change program behavior or fix any security issue.

This commit fixes a bug in Bitcoin Core's transaction fee-bumping feature. When a user tried to increase the fee on a transaction that was tied to a very large cluster of unconfirmed transactions, the software could not calculate the required fee and returned an empty value. The old code then tried to use that empty value anyway, causing the program to crash (in the GUI) or throw an unhandled exception (in command-line tools). The fix simply checks for the empty value and returns a proper error message instead of crashing.

This commit renames a test-only constant from WAIT_TIMEOUT to TEST_WAIT_TIMEOUT because the old name conflicts with a Windows system macro. It is a build hygiene fix inside the test suite and does not change any production code or affect live Bitcoin network behavior.

This commit is a documentation-only change. It updates the help text for the importdescriptors command to show that error responses include a numeric 'code' and a text 'message', instead of a vague placeholder. No code behavior changed, and there is no security issue here.

This is a routine reliability improvement for Bitcoin Core's automated Windows build scripts. It adds a single retry with a short pause when a build-generation step fails, likely due to temporary network hiccups during CI runs. There is no security relevance.

This commit only changes a single test file. It removes a debug-log assertion and slightly simplifies how a test node is restarted during a reindex test. There is no change to production Bitcoin Core code, no security fix, and no vulnerability.

This is a tiny test-only code cleanup. It changes one argument name from verbose=0 to verbosity=0 inside a test helper function. It does not touch live Bitcoin network code, wallets, consensus rules, or any user-facing behavior. There is no security relevance.

This commit fixes a flaky test in Bitcoin Core's own test suite. It replaces a method that restarted a test node and relied on timing-sensitive behavior with a simpler helper that directly syncs blocks to a specific height. There is no change to production code, no security vulnerability, and no risk to real users.

This commit removes the `dsymutil` tool from Bitcoin Core's dependency build system. `dsymutil` is a macOS developer tool used to bundle debug symbols into a separate file. The change is a cleanup: the build system no longer looks for or configures this tool because it is reportedly no longer needed. There is no indication this fixes or introduces a security vulnerability.

This commit is a small internal cleanup in how Bitcoin Core notifies other parts of the program when a block is disconnected from the chain. It changes the notification so that ownership of the block data is transferred into the background scheduler thread, making the existing behavior more explicit. There is no indication this fixes a security vulnerability or introduces a new attack.

This commit is a small internal cleanup in how Bitcoin Core hands off newly connected blocks to background notification threads. It moves a block's shared ownership explicitly onto the scheduler thread so the heavy validation thread is not delayed by memory cleanup. There is no user-facing bug fix or security vulnerability being patched; it is a performance and clarity improvement.

This commit is a code cleanup in Bitcoin Core's validation notification system. It reduces unnecessary copying of data when block and transaction events are passed between internal components, and it changes how debug log messages are formatted. There is no direct security vulnerability being fixed here; it is preparation for later commits that clarify object ownership.

This is a routine build-system cleanup. The developers renamed how their CMake scripts refer to the SQLite database library so they use the current, non-deprecated target name. It does not change Bitcoin Core's behavior, fix a bug, or alter how wallets store data. There is no security relevance in the commit itself.

This commit only changes Bitcoin Core's continuous-integration (CI) test setup. It switches the compiler used during Valgrind memory-checking jobs from GCC to Clang, because a known bug in Valgrind makes it report false problems on GCC-optimized executables that use std::optional. No user-facing code, consensus rules, wallet, networking, or node behavior is changed. There is no security vulnerability being fixed or introduced here.

This is a documentation-only change to a continuous integration script. A developer replaced a vague 'TODO enable GUI' comment with a clearer explanation that the GUI is disabled in the valgrind CI task because it only passes with a special debug build. No code behavior changed, and there is no security fix or vulnerability here.

This commit simply adds a new read-only function to the Bitcoin Core kernel library that lets callers retrieve a transaction input's nSequence value. It is a straightforward API addition with no security implications.

This commit simply adds a new read-only function to the Bitcoin Core kernel library that lets callers retrieve a transaction's nLockTime value. nLockTime is a standard, public field in every Bitcoin transaction. The change does not alter how transactions are validated, stored, or relayed, and it introduces no security fix or vulnerability.

This commit only adds new test code for an existing Bitcoin Core wallet component. It expands a fuzzing harness to exercise more methods of the CCoinControl class, which is used to choose which coins are spent in transactions. There is no change to production wallet logic, no bug fix, and no security patch.

This commit only improves a fuzz test for the Bitcoin Core wallet's coin selection helper. It adds extra checks (assertions) inside the test to make sure the coin control object behaves as expected. It does not change any production wallet code, network code, or consensus rules, so it cannot introduce a security vulnerability in the running software.

This commit updates the version of the GNU C library (glibc) used in Bitcoin Core's reproducible build system (Guix) from one specific 2.31 snapshot to a newer 2.31 snapshot. It changes a commit hash and its corresponding cryptographic hash in a build manifest. There is no direct evidence in the commit that this fixes a specific security vulnerability; it appears to be a routine dependency refresh within the same glibc release branch.

This commit only adds a comment to an existing build-system patch file. It documents which future GCC versions will make this patch unnecessary. No code behavior is changed, and there is no security relevance.

This change removes a custom Guix package definition for osslsigncode (a Windows code-signing tool) and instead uses the version already maintained in upstream Guix. It is a build-system maintenance cleanup, not a security fix. The old custom package had a workaround for tests that would fail after the year 2025, but that workaround is being removed because the upstream Guix package presumably handles it. There is no direct evidence in the commit of a vulnerability or attack.