Bitcoin Core

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.

This commit removes a fallback code path in Bitcoin Core's address manager that the authors say can never be reached under current rules. It replaces that fallback with internal consistency checks (assertions). The change is a code-cleanup and hardening patch, not a fix for a known exploitable bug.

This commit simply archives the release notes for Bitcoin Core version 29.4. It adds a documentation file summarizing bug fixes and improvements from other already-merged changes. No code was changed, and there is no new security issue introduced by this commit itself.

This commit only adds a new data structure for wallet error reporting. It does not change any behavior, fix a bug, or alter how funds or keys are handled. There is no security issue here.

This commit only changes a style guide in the project documentation. It removes 'ALL_CAPS' as an acceptable naming style for enum class constants and explains that this avoids clashing with macros. No code, build scripts, or security behavior is changed.

This commit simply removes one person (Pieter Wuille) from the list of security contacts in the project's SECURITY.md file. It is an administrative change to the documented contact list and does not alter any code, fix any bug, or change any security process.

This commit changes the warning threshold that tells Bitcoin Core users when their database cache setting (-dbcache) is too large for their computer's RAM. Previously, the threshold jumped sharply at exactly 2 GiB of total RAM. The new formula removes that jump by reserving 2 GiB of RAM for non-cache use and applying the 75% rule only to the remaining memory. It is a user-experience and performance tuning change, not a security fix.

A Bitcoin Core developer removed their own DNS seed (seed.bitcoin.sipa.be, run by Pieter Wuille) from the list of hardcoded network seeds that help new Bitcoin nodes find peers when they first start up. This is a routine operational/maintenance change, not a code vulnerability fix. It slightly reduces the number of default seed options available to users.

This commit fixes a minor bookkeeping bug in Bitcoin Core. When flushing state to disk during a block disconnection, the code was incorrectly reporting the current chain tip (the block being disconnected) as the flushed block, instead of the last block actually written to disk. This could mislead indexers or other listeners tracking the chain's flushed state, but it does not directly allow theft, double-spending, or consensus failure.

This is a small internal cleanup change in Bitcoin Core. A helper function called Commit() previously returned true or false to indicate success or failure, but nothing in the code was actually checking that result. The change removes the unused return value so the function now returns nothing. There is no security-relevant behavior change: the same error is still logged when commit fails, and callers still proceed the same way as before.

This commit adds internal bookkeeping so Bitcoin Core can remember the last block whose state was safely written to disk. It does not, by itself, change any security boundary or fix a known bug; it is a small infrastructure change meant to support future work that keeps database indexes from getting ahead of the main chain state.

This commit fixes a corruption risk in Bitcoin Core's optional indexes (notably coinstatsindex). Previously, an index could save its progress to disk even though the main chainstate database had not yet flushed that far. If the node then crashed and restarted, the index would be ahead of data it needed to roll back to during a reorganization, leaving the index corrupted. The fix makes the index skip saving until the chainstate has flushed at least as far as the index tip. It also corrects outdated documentation and updates a test to match the new behavior.

This commit only adds a new automated test to Bitcoin Core. It does not change any production code, so it cannot by itself introduce a vulnerability or fix one. The test checks that an internal database index does not save progress beyond the last point the main chain data was safely written to disk, which helps prevent corruption after an unexpected shutdown.

This is a minor fix to a unit test file. A test variable was being assigned a negative value in an unsigned container, which caused a silent underflow and made the test assertion technically incorrect. The patch changes the test to check the negative result directly without storing it in the wrong type. It does not change any production code or affect real Bitcoin Core behavior.

This commit adds an empty placeholder for NetBSD linker flags in the build system. It is a one-line build configuration change with no functional or security effect visible in the diff.

This commit adds a new automated build test for Bitcoin Core that compiles the software for NetBSD (a lesser-used operating system) from an Ubuntu machine. It does not change any Bitcoin code, wallet logic, network behavior, or security settings. It only adds continuous-integration (CI) configuration files and a script to download the NetBSD system headers/libraries needed for cross-compilation.