Bitcoin Core

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.

This commit adds a new automated fuzz test for Bitcoin Core's private transaction broadcast feature. It is purely a testing/quality-assurance change and does not modify any production networking or consensus code. There is no security vulnerability here.

This commit only adds a new test case to Bitcoin Core's script test suite. It verifies that a special edge-case number ('negative zero') is treated as plain zero by the CHECKSEQUENCEVERIFY opcode and therefore fails with the expected 'unsatisfied locktime' error rather than a 'negative number' error. There is no change to production code, no bug fix, and no security patch.

This commit only adds new test cases to a JSON test file for the Bitcoin Core test suite. It exercises ways the CHECKLOCKTIMEVERIFY (CLTV) script operation can fail, but does not change any production code, consensus rules, or network behavior. It is a test-only addition with no direct security impact on running software.

This commit only adds release notes describing a prior code change (PR #32800). It documents that several RPC calls now expose two separate virtual-size fields and that the old `vsize` field is deprecated. There is no code change here, only documentation.

This commit adds a new read-only field called vsize_adjusted to the getrawtransaction RPC output, but only when the transaction is currently in the memory pool. It exposes information the node already calculates for mempool policy, so it does not change behavior, fix a bug, or introduce a vulnerability. It is a transparency/feature improvement for RPC users.

This Bitcoin Core change fixes a labeling problem in several RPC (remote procedure call) responses. The old 'vsize' field was actually reporting a sigop-adjusted size, not the plain BIP 141 virtual size its documentation claimed. The patch keeps the old 'vsize' value for backward compatibility but marks it deprecated, and adds two new clearly-named fields: 'vsize_bip141' for the true BIP 141 virtual size and 'vsize_adjusted' for the sigop-adjusted size. It is an API clarity/documentation correction, not a consensus or mempool rule change.

This commit is a straightforward internal code reorganization: it moves the LoadGenesisBlock function from the Chainstate class to the ChainstateManager class, marks its return value as important to check, and slightly rewords two rare error log messages. There is no change to how Bitcoin Core validates blocks, handles transactions, or protects against attacks. It does not fix a security bug or introduce a known vulnerability.

This is a tiny change to a single unit test in Bitcoin Core. It swaps which test transaction is used in one assertion so the test matches the scenario described in the comment above it. There is no change to production code, no security fix, and no vulnerability.

This is a trivial code-cleanup commit. It removes a duplicate [[nodiscard]] marker from a function definition in a source file, because the same marker is already present on the function's declaration in the header file. The duplicate had no effect on program behavior or security.

This commit changes the error code returned when Bitcoin Core's private broadcast transaction queue is full. Previously, the node reported an 'out of memory' error (-7), which was misleading because the server is not actually running out of memory. The new error code (-37, RPC_LIMIT_EXCEEDED) more accurately tells the caller that a configured capacity limit has been reached. This is a correctness and clarity improvement, not a security fix for a vulnerability.

This commit only changes test code. It swaps generic true/false checks for equality checks on an enum and adds a helper so that if a test fails, the output shows the actual enum value (e.g., 'QueueFull') instead of just 'false'. There is no change to production code, no bug fix, and no security relevance.

This commit fixes a crash bug in Bitcoin Core's wallet coin selection. When the wallet tried to estimate fees for spending unconfirmed coins, it took two separate snapshots of the mempool. If the mempool changed between those snapshots—such as when someone artificially lowered a transaction's fee priority—the second fee could be higher than the first. That produced a negative 'discount' value, which then triggered an internal assertion that the value must be zero or positive, causing the wallet process to crash. The fix simply skips applying the discount when it would be negative.

This commit only adds a new automated test to Bitcoin Core. It checks that a user-configured onion address still gets advertised even when the node is told to only use IPv4. There is no code change to the actual Bitcoin node behavior, so this commit does not introduce or fix a security vulnerability on its own.

This commit only adds a new automated test to Bitcoin Core. It checks that the -externalip command-line option can bypass the -onlynet restriction when a user explicitly configures an external address, while normal local-address registration still respects network reachability rules. There is no change to production code, no bug fix, and no security vulnerability being patched.

This commit fixes a configuration bug in Bitcoin Core. Previously, if a user told their node to only use one network type (for example, only IPv4) and also manually set an external address on a different network (for example, a Tor onion address), the node would silently ignore the manually configured address. The change makes the node honor the user's explicit -externalip setting even when it belongs to a network otherwise excluded by -onlynet. It is a usability/configuration fix, not a vulnerability that allows attackers to take over nodes or steal funds.