Bitcoin Core

This commit is a minor style cleanup inside a fuzz test (a test that feeds random data to software to find bugs). It replaces a loop that reads a number from fuzz input with a standard helper that reads a single true/false byte each iteration. There is no change to production Bitcoin Core code, no user-facing behavior change, and no security fix.

This commit updates a helper library (libmultiprocess) used by Bitcoin Core. The only code change replaces a raw memory copy with a safer standard-library copy in a routine that converts byte arrays for inter-process communication. The rest is version bookkeeping and new test coverage. There is no indication this fixes an active security vulnerability; it is a defensive cleanup to silence an undefined-behavior sanitizer warning.

This commit updates the version of a Python packaging tool called 'uv' used inside Bitcoin Core's automated code-checking container image, from version 0.10 to version 0.11. It is a routine dependency bump in the continuous-integration (CI) setup and does not change any Bitcoin protocol, wallet, or network code.

This commit simply updates the version of Ubuntu used by Bitcoin Core's automated linting (code style checking) container from 24.04 to 26.04. It is a routine CI/infrastructure maintenance change with no security relevance visible in the commit.

This commit simply updates the version of mypy, a Python type-checking tool used in the project's continuous integration (CI) linting pipeline, from 1.19.1 to 2.3.0. There is no indication of a security fix or vulnerability in the code itself.

This commit changes a single CI (continuous integration) configuration file for an OpenBSD cross-compilation test job. It disables building the Qt GUI library in that specific test job because the build tool llvm-ranlib does not support the '-t' option used by the build system. This is a build/test infrastructure workaround, not a change to Bitcoin Core's runtime code, consensus logic, wallet handling, or network behavior. It has no direct security relevance for users running Bitcoin Core.

This is a one-line build-system fix for a Bitcoin Core fuzz-testing target. It changes a CMake target name so the correct header paths are found when libmultiprocess is built externally instead of bundled. It does not change runtime behavior, consensus rules, or network code, and there is no security vulnerability being patched.

This commit simply updates the version of a build dependency (Cap'n Proto, a data serialization library used during compilation) from 1.4.0 to 1.5.0 in Bitcoin Core's dependency system. It changes only a version number and the corresponding cryptographic hash used to verify the downloaded source. There is no indication in the commit itself of any security bug, vulnerability, or malicious change.

This commit is a small internal cleanup in Bitcoin Core's benchmark code. It swaps a test-only mock wallet database helper for a real in-memory SQLite database helper in five benchmark files. There is no change to production wallet code, no change to how real user wallets are stored, and no security fix or vulnerability introduced.

This Bitcoin Core commit refactors how transactions are selected and sorted before being announced to network peers. It replaces an older in-place heap sort with a new mempool function that picks the best transactions by mining fee score while respecting dependency order. The change is a code-quality and performance improvement; there is no direct evidence in the commit or supplied references that it fixes a security vulnerability.

This commit introduces a brand-new, generic token-bucket utility class and a full set of unit tests for it. A token bucket is a common algorithm for rate limiting (controlling how often an action can happen). There is no change to existing network, wallet, consensus, or RPC behavior, and the commit message and diff do not describe any security fix or vulnerability.

This commit adds a new debug-only command-line option called -txsendrate that lets node operators change how many transaction announcements per second Bitcoin Core sends to inbound peers. The default behavior stays the same (14 transactions per second), and the setting is clamped between 1 and 1000. It is intended for testing and low-risk tuning, not for normal user operation.

This commit adds new read-only information fields to Bitcoin Core's getnetworkinfo RPC command. It exposes the configured transaction send rate and internal token-bucket statistics used to pace transaction announcements to peers. There is no code change that modifies behavior, permissions, or network processing; it only reports existing internal state to authorized RPC callers.

This commit only adds a new automated test file and registers it in the test runner. It does not change any production code in Bitcoin Core. The test verifies that transaction relay rate limiting (a feature controlled by the -txsendrate option) works as expected, including that replaced transactions are cleaned from the backlog. There is no security vulnerability or fix here.

This commit only adds a release note describing a previously made network change. It does not change any code, configuration defaults, or behavior. There is no security issue in this documentation patch itself.

This is a small code cleanup change in Bitcoin Core's network transaction broadcasting. It removes an unused transaction ID argument from an internal function called InitiateTxBroadcastToAll, leaving only the witness transaction ID. The function's behavior is unchanged; only its signature and call sites are simplified.

This commit adds a global rate limiter to how many transaction announcements (INV messages) a Bitcoin node sends out. Before, each peer had its own queue, so a node could receive one transaction and announce it to over 100 peers, acting like an amplifier for spam and wasting bandwidth and CPU. The new code caps both the number of transactions announced per second and the total bytes announced, with higher limits for outbound peers. It also changes transaction broadcast to use a single shared backlog sorted by mempool quality, rather than per-peer queues. This is a defensive hardening change, not an active vulnerability fix, and the commit message explicitly frames it as mitigating transaction-spam amplification.

This commit removes an unused helper function called CompareMiningScoreWithTopology from Bitcoin Core's transaction memory pool code. It also updates an internal consistency check to use a different, already-existing comparison method. There is no security issue here—this is ordinary code cleanup after a replacement function was introduced.

This commit adds a periodic debug log message that prints statistics about Bitcoin's inventory backlog. It is purely an observability/monitoring change and does not alter network behavior, consensus rules, or security boundaries.

This commit adds a new internal mempool helper function that takes a list of transaction IDs, looks them up in the memory pool, removes duplicates and missing entries, and returns the best-priority ones according to Bitcoin's mining-score/topology ordering. It is a straightforward, additive code change with no obvious security bug.

This Bitcoin Core change removes a per-peer speed limit on how many transaction announcements (INV messages) a node sends out at once. Previously a peer would only announce up to about 1,000 transactions per batch, with a dynamic cap. Now the node empties the whole outgoing queue every time, so a single INV message can grow as large as the protocol allows (about 50,000 items). The commit message says this avoids storage/compute costs and past severe bugs tied to per-peer rate limiting, but it also increases the maximum announcement burst a peer can receive.

This change makes a Bitcoin node's mempool announcement logic more explicit and reliable. When a node announces the contents of its memory pool to a peer (a BIP35 'mempool' request), it now directly records the latest mempool version. Previously it relied on a side effect of the normal inventory announcement path. The fix reduces the risk that a peer's follow-up requests for those announced transactions would be ignored or mishandled, which could cause a peer to receive inconsistent or incomplete mempool data.

This is a test-only cleanup change. It removes a dedicated helper file used to simulate external programs during testing and instead makes the main test program act as that helper when a special environment variable is set. There is no change to the Bitcoin Core software that users run, and no security issue is introduced or fixed.

This is a routine test-only change. It adjusts an existing unit test to better exercise how Bitcoin Core's coin cache behaves when memory reserved for the mempool is not actually being used by the mempool. No production code was changed, so there is no direct security risk from this commit itself.

This commit only adds a new automated test to Bitcoin Core. It verifies that when a node connects to a 'private broadcast' peer which signals it does not relay transactions (relay=false), the node disconnects that peer. There is no change to production code, no bug fix, and no security vulnerability introduced or patched.