Bitcoin Core

This change only adjusts compiler warning settings for the Bitcoin Core kernel build. It adds a new warning flag for newer Clang compilers to detect duplicated symbols between the kernel library and downstream users. There is no functional code change, no bug fix, and no security vulnerability being addressed.

This commit adds a new read-only helper called PeekCoin() to Bitcoin Core's coin-cache system. Unlike the existing GetCoin(), PeekCoin() looks up a coin through layers of cache without writing the result into parent caches. The stated purpose is to avoid polluting the main UTXO cache when validating blocks that might turn out to be invalid. It is a defensive, non-breaking code-quality change with no direct vulnerability fix described.

This Bitcoin Core change fixes how the coin cache behaves when a new block fails validation. Previously, the same cache used for the main chain was temporarily used during block validation, which could leave behind entries from invalid blocks. Now a separate overlay view is used, so failed blocks don't pollute the main cache. The commit adds a test proving that an invalid block no longer leaves its inputs in the cache. This is a correctness and denial-of-service hardening fix rather than a direct theft bug.

This commit is a test-only code cleanup. It moves a block of verification code from the middle to the end of a fuzz-testing function so that a future test can check that the underlying coin database is not modified before a specific write operation. No production code, network behavior, or wallet logic is changed, and there is no security fix.

This commit adds a new read-only overlay for Bitcoin Core's coin cache system. It lets the software look up transaction inputs during block validation without writing those lookups into the main in-memory cache. The goal is to avoid polluting the cache with data from blocks that might turn out to be invalid, and to prepare for future multi-threaded input fetching where worker threads should not change shared state. The change itself is defensive infrastructure, not a fix for an active bug or vulnerability.

This commit adds a new automated fuzz test for a Bitcoin Core component called CoinsViewOverlay. Fuzz tests feed random or semi-random inputs to code to catch bugs early. The change only touches test code and does not alter the behavior of the main Bitcoin node software. There is no indication it fixes a live security issue or introduces a vulnerability.

This commit is a minor code cleanup in Bitcoin Core's internal fuzz testing code. It changes how a test helper function receives a temporary data cache, moving the cache creation from inside the helper to the callers. The commit message explicitly calls this a non-functional change, and the diff shows only a straightforward parameter refactor with no logic changes to how Bitcoin handles transactions, networking, or wallets.

This commit only updates release note documentation for an upcoming Bitcoin Core release. It deletes one release-notes file and adds another describing changes to the mining IPC (inter-process communication) interface. There are no code changes, no bug fixes, and no security-sensitive behavior altered in the commit itself.

This is a small build-system fix for Bitcoin Core on NetBSD. It narrows an existing workaround so it only applies when Boost is installed under /usr/pkg (the standard NetBSD pkgsrc location). Previously, the workaround could set incorrect include paths on NetBSD systems where Boost was installed elsewhere, potentially breaking compilation. There is no indication this affects runtime security or allows attacks.

This commit fixes timing-related flakiness in a single Bitcoin Core functional test file. It does not change any production node code, network rules, or wallet behavior. There is no security issue in the software itself—only a more reliable way of running an existing test.

This is a planned compatibility break for an experimental inter-process communication (IPC) mining feature in Bitcoin Core. The developers moved the current mining method to a new slot and made the old slot return a clear error message, so outdated clients can no longer connect. It is not a security vulnerability; it is an intentional API cleanup with a test that verifies the old interface now fails gracefully.

This commit is a small, non-functional refactor. It declares new named constants for default values used in Bitcoin's mining inter-process communication (IPC) protocol and block template creation, and adds compile-time checks that those constants match existing values. No behavior changes; no security issue.

This is a test-only change in Bitcoin Core. It adds a temporary workaround in an automated test so the test can keep running even when a known bug in a supporting library (libmultiprocess) causes the tested program to crash. The change does not alter normal Bitcoin node behavior, wallet handling, consensus rules, or network protocol handling, so it is not a security vulnerability in Bitcoin Core itself.

This is a Bitcoin Core internal-only commit that changes the inter-process communication (IPC) schema used between the main node and external mining components. It adds a missing 'context' parameter to two mining methods so they run in their own thread and don't block other calls. The commit itself explicitly warns it is an intermediate, review-only change that should not be distributed, because it makes incompatible schema changes without bumping the version number, which could cause mismatched binaries to exchange garbage data instead of clean errors. The actual security risk is low and self-contained: it is a known, temporary incompatibility during development, not a vulnerability in shipped code.

This is a small internal code cleanup in Bitcoin Core's mining RPC. It replaces a deprecated helper method with a direct read of the coinbase transaction data. The commit message explicitly says there should be no change in behavior, and the diff shows equivalent logic: it still returns the same witness commitment value under the same JSON key when present.

This is a Bitcoin Core internal commit that adds default values to an inter-process communication (IPC) schema used by experimental mining interfaces. The commit itself warns it is an intermediate, review-only change that should not be used in production because it makes an incompatible schema change without bumping the version number. If someone ignored that warning and ran mismatched binaries, the two sides could misunderstand each other's messages and exchange garbage data instead of clean errors. There is no direct evidence this is exploitable as a security vulnerability; the risk is primarily operational and self-disclosed by the developers.

This is a Bitcoin Core internal cleanup commit that removes old, deprecated methods from the inter-process communication (IPC) mining interface. The commit itself is explicitly marked as an incomplete, review-only change that should not be used in production. The main risk is that, because the interface version number was not bumped in this intermediate commit, two differently-versioned programs could talk to each other using mismatched method numbers and exchange meaningless data instead of getting a clean error. That mismatch is a protocol-handling bug, not a cryptographic or funds-theft vulnerability, and the commit message says the next commit in the series will fix it by bumping the version.

This commit changes Bitcoin Core's internal testing helper code. It makes two test-only quality-of-life improvements: an expected error message can now be a regular expression pattern instead of only a fixed string, and an expected program exit code can now be a list of acceptable values instead of a single value. These changes only affect how tests validate results; they do not change the behavior of the Bitcoin Core software that users run.

This commit only adds new test code to Bitcoin Core. It does not change any production wallet, networking, or consensus code. The test verifies that a new RPC command, abortprivatebroadcast, correctly removes a transaction from the private-broadcast queue and returns an error for a non-existent transaction. There is no security-relevant change to end-user behavior.

This commit is a documentation-only update to the release notes. It simply tells users about two new commands (RPCs) that let them check or stop private transaction broadcasts. No code behavior changed, and there is no security issue in the commit itself.

This commit adds a new Bitcoin Core RPC command called abortprivatebroadcast. It lets a node operator stop a transaction that is currently being sent out privately (a privacy feature) and remove it from the outgoing queue. The change is purely additive: it exposes a way to cancel an in-progress private broadcast, but does not by itself create or fix a security vulnerability. It is a user-facing control feature, not a security patch.

This commit only adds new test code to Bitcoin Core. It extends an existing functional test to check that an RPC command called getprivatebroadcastinfo correctly reports private transaction broadcasts. There is no change to production code, no bug fix, and no security-relevant behavior change.

This commit adds a new read-only RPC command called getprivatebroadcastinfo to Bitcoin Core. It lets users inspect transactions currently being broadcast privately, including their IDs, raw data, and which peers they were sent to and when. There is no code change that modifies how transactions are broadcast or how peers are chosen; it only exposes existing internal state through the RPC interface.

This commit adds a new read-only method, GetBroadcastInfo(), to Bitcoin Core's PrivateBroadcast class. It simply returns statistics about which transactions are being privately broadcast and to which peers. There is no change to network behavior, no new permissions, and no bug fix. It is a routine code addition with no security relevance.

This commit only renames variables and updates comments in Bitcoin Core's coin selection code. It changes names like 'descendants' to 'cluster_count' to make the code match what it actually does, with no change in behavior. There is no security issue here.