Bitcoin Core

This commit only updates documentation. It moves the pkgconf/pkg-config package from the 'always required' dependency list to the 'only needed if you enable ZMQ' list, because ZMQ packages sometimes need it to be found by the build system. There is no code change and no security issue.

This commit simply removes the word 'EXPERIMENTAL' from the help text of two wallet commands, 'send' and 'sendall'. It does not change how those commands work, what data they accept, or how secure they are. It is a documentation-only cleanup marking these RPCs as no longer experimental.

This is a routine cleanup of the continuous integration (CI) build script for a Chimera Linux test job. It removes a few unused build packages (ninja, xz, pkgconf) because the job no longer compiles the Qt graphical wallet interface. There is no change to the Bitcoin Core software users run, no bug fix, and no security relevance.

This commit simply adds a new automated testing job to Bitcoin Core's GitHub Actions CI configuration. It runs a build test for a RISC-V 32-bit bare-metal target using a static libbitcoin_consensus library. There is no code change to Bitcoin Core itself, no user-facing behavior change, and no security fix or vulnerability introduced.

This commit adds a new continuous-integration (CI) build job that compiles a small, non-runnable test binary for a RISC-V bare-metal target. It does not change any production wallet, node, or consensus code, and it does not introduce a security vulnerability.

This commit adds a new build option for Bitcoin Core that lets developers compile for 'bare metal' environments (systems without a full operating system). It only changes build configuration files to skip features like threads, atomics, and certain crypto components when the special CMAKE_SYSTEM_NAME=Generic setting is used. There is no change to the actual Bitcoin protocol code or to how normal builds work, and nothing in the commit suggests a security vulnerability or fix.

This commit only changes a test file. It adds code to generate extra blocks during a wallet rescan test so the rescanning process takes longer. There is no change to production Bitcoin Core code, no security fix, and no vulnerability.

This commit only adds documentation: a new release-notes file describing a previously merged RPC improvement. No code changes are present, and there is no security issue in the commit itself.

This commit is a routine internal cleanup in Bitcoin Core's wallet code. It removes an old string-to-string metadata map called mapValue from wallet transactions and replaces it with direct typed fields. The change keeps the same data on disk and in RPC output, just organized differently. There is no indication this fixes a security bug or introduces a new vulnerability.

This Bitcoin Core wallet patch makes the wallet stricter when reading old transaction metadata. Previously, unknown entries in a wallet's internal 'mapValue' data store were silently ignored. Now the wallet will refuse to load if it sees an entry it does not recognize, and it also removes two obsolete fields ('fromaccount' and 'spent') before checking. The goal is to prevent accidental loss of user data when older wallet formats are loaded in newer software, not to fix an active remote attack.

This commit is a small internal cleanup in Bitcoin Core's wallet code. It moves two pieces of transaction metadata—'replaces_txid' and 'replaced_by_txid'—from a loose string-based key/value map into properly typed member variables of the CWalletTx class. The values are still saved to and loaded from the wallet database in the same way, so there is no user-visible behavior change. It is a refactoring change, not a security fix.

This commit is a straightforward internal cleanup in Bitcoin Core's wallet code. It moves two optional user-provided text fields, 'comment' and 'to', out of a generic key/value map and into explicit named member variables on the wallet transaction object. The change does not alter what data is stored or how users interact with it; it only makes the code clearer and less error-prone. There is no indication this fixes a security vulnerability.

This is a small code cleanup in Bitcoin Core's wallet. It moves two very old, rarely-used pieces of transaction metadata—'from' and 'message'—out of a generic key/value map and into explicit named fields. The change preserves the same data and behavior, just makes the code clearer. It is not a security fix and does not appear to introduce a meaningful vulnerability.

This is a routine internal code cleanup in Bitcoin Core's wallet. It changes how optional user comments (like a note on a payment) are passed through the code, moving them from a generic key-value map to explicit function parameters. The actual behavior—storing the comments with the transaction—remains the same. There is no security issue visible in this change.

This is a routine internal code cleanup in Bitcoin Core's wallet. It removes an old way of passing extra transaction details (called mapValue) and replaces it with explicit named parameters. The change does not alter what the wallet records or how transactions are broadcast; it only makes the code easier to maintain. There is no indication of a security bug being fixed.

This is a small internal code cleanup in Bitcoin Core's wallet. It changes how a transaction ID is passed when a user bumps a transaction fee, moving the value from a general metadata map into a dedicated function parameter. There is no security bug being fixed here and no user-facing behavior change.

This commit is a small code-quality refactor in Bitcoin Core. It changes several UTXO-statistics helpers so they take a database view by reference instead of by pointer. That removes the possibility of passing a null pointer and makes the code's contract clearer, but it does not by itself fix any reported bug or vulnerability.

This is a small cleanup change in Bitcoin Core that removes leftover null checks after a previous refactor made database cursors always return a valid object. There is no security issue in the diff itself.

This commit is a routine code cleanup. It removes an unused cursor-iteration method from the base coin-view interface and its empty/forwarding/throwing implementations, keeping the method only on the concrete database class that actually supports iteration. It also removes a fuzz test that only checked the now-deleted unsupported-throw path. There is no security-relevant change.

This is a small internal code cleanup in Bitcoin Core. It changes several functions that compute UTXO (unspent transaction output) statistics so they accept a more specific database-view pointer instead of a generic one, because only the concrete database view actually supports cursor iteration. There is no user-visible behavior change and no security fix.

This commit is a routine cleanup after Bitcoin Core replaced its old HTTP server (libevent). It removes the 'libevent' logging category from help text, RPC output, and internal code. Users who still try to use it will get a deprecation warning instead of the category actually being enabled. There is no security issue here.

This commit only adds a new test operation to an existing fuzzing target. It exercises a database compaction function (CompactFullAsync) during automated fuzz testing, with no changes to production code or user-facing behavior. There is no indication of a security fix or vulnerability.

This commit is a simple rename of an internal function from CompactFull() to CompactFullAsync(). It does not change what the code does, only its name, to make it clearer that the operation runs in the background rather than blocking. There is no security issue here.

This change only affects Bitcoin Core's internal fuzz testing code. It makes several test mock sockets share a single fake clock instead of each having their own, so timing behaves more realistically during automated fuzz testing. There is no change to the live Bitcoin network code, wallets, consensus rules, or anything end users run.

This commit is a cleanup of a Bitcoin Core test file. It replaces a hard-coded list of test keys with a helper that generates fresh random keys during the test. There is no change to the actual Bitcoin node software, no fix for a vulnerability, and no security-relevant behavior change.