Bitcoin Core

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.

This change refactors how Bitcoin Core creates a temporary wallet during the exportwatchonlywallet command. Previously, the temporary wallet was written to disk in the wallets directory and then deleted afterward. Now it is kept entirely in memory using SQLite's in-memory mode, so no temporary files are created on disk. This is a cleanup and hardening improvement, not a fix for an active exploit.

This commit only adds a new automated test. It checks that Bitcoin Core's in-memory SQLite wallet database correctly refuses to reopen after being closed, because reopening would silently create a fresh empty database and discard any previous wallet data. The actual protective change (making Open() throw) is already in the codebase; this commit just pins the behavior with a regression test so it cannot accidentally break in the future.

This patch fixes a bug in Bitcoin Core's SQLite wallet code where an in-memory test wallet could accidentally be reopened as a real on-disk database, or be lost entirely during error recovery. The fix stores the original database flags so reopening preserves them, and explicitly throws an error instead of trying to recover a connection to an in-memory database (which would lose all data). It appears to be a correctness/reliability fix rather than an active security vulnerability in normal production use.

This commit simply archives the written release notes for Bitcoin Core version 30.3. It adds a new documentation file listing what changed in that release, but does not change any program code, configuration, or build scripts. There is no security issue in this commit itself.

This commit only adds a release note documenting a prior behavior change: Bitcoin Core will now immediately drop remote clients blocked by the -rpcallowip setting, instead of sending them a '403 Forbidden' error page. The commit itself changes only documentation and contains no code.

This Bitcoin Core change moves the IP allow-list check for RPC connections so it happens immediately when a connection is accepted, rather than after the server has already started processing the HTTP request. Previously, a blocked client would receive a '403 Forbidden' response; now the connection is simply closed. This is a hardening improvement, not a fix for an active vulnerability, and it reduces the attack surface from disallowed IP addresses by cutting them off earlier.

This commit updates a library Bitcoin Core uses for inter-process communication (libmultiprocess). The main functional change is adding an optional 'max_connections' limit to the ListenConnections() function, so a server can stop accepting new IPC clients once a local cap is reached and resume only after an existing client disconnects. The change also adds tests and bumps the library version. There is no explicit vendor statement that this fixes a security vulnerability; it reads as a hardening/robustness improvement.

This commit fixes a bug in Bitcoin Core that only affects 32-bit computers. When the program calculated how much database cache to allocate, it multiplied a large default cache value by 10. On 32-bit systems that multiplication overflowed, producing a much smaller or incorrect number. The fix changes the internal type from size_t (32-bit on 32-bit systems) to uint64_t (always 64-bit) so the multiplication stays correct. On normal 64-bit computers the change is harmless and just a cleanup.

This commit adds a new public read-only API to the Bitcoin Core 'kernel' library so that outside programs can inspect the 'witness stack' of a transaction input. The witness stack is part of how modern Bitcoin transactions (SegWit/Taproot) carry signatures and scripts. There is no bug fix, behavior change, or security patch here—only a new way to read data that was already stored internally. The change is accompanied by new tests.

This commit adds a new public function to the Bitcoin Core 'bitcoinkernel' library that lets callers read the scriptSig data from a transaction input. A scriptSig is the part of a Bitcoin transaction input that typically contains a signature and public key proving ownership of the coins being spent. The change only exposes already-existing data through a new API; it does not alter validation rules, consensus logic, or memory handling in a way that would create a security vulnerability. It is a routine API completeness improvement with an accompanying test.