Bitcoin Core

This commit is a simple rename of three internal constants used by Bitcoin Core's socket-handling code. The old names (RECV, SEND, ERR) clashed with a macro named ERR on illumos-based operating systems, preventing the software from compiling. The new names (RecvEvent, SendEvent, ErrorEvent) avoid that clash. There is no change to program logic, behavior, or security.

This is a simple code cleanup change: a local constant named ERR inside one function was renamed to accept_error because it happened to have the same name as a class-level constant. The rename avoids confusion for programmers but does not change any program behavior or fix a security problem.

This is a routine Continuous Integration (CI) configuration update. It changes the version of the Linux container used for one automated test job and adds a compiler flag to work around a known build issue. There is no change to the Bitcoin Core software that users run, and no security vulnerability is being fixed or introduced.

This commit simply makes an existing command-line option, -logratelimit, visible in the normal help output. It does not change how the option works, what it protects against, or any code behavior. It is a documentation/usability change only.

This commit is a code-quality refactor, not a security fix. It replaces raw 4-byte fingerprint arrays with a named std::array type (KeyFingerprint) and adds helper methods to copy fingerprints safely. The behavior of fingerprint handling is unchanged; the change only makes the code easier to maintain and less prone to future mistakes.

This is a small bug fix in Bitcoin Core's internal benchmarking header (nanobench). The code intended to create three empty placeholder slots in some performance-counter buffers, but accidentally created a single slot containing the number 3. Under normal use this gets corrected before it matters, but a default-constructed object could read past the single element. It is a correctness/reliability fix in benchmark tooling, not a network-facing security vulnerability.

This commit adds a new automated test that starts the Bitcoin GUI in a headless mode and checks it can be shut down by a remote command. It also makes a small code change so the GUI does not try to load custom fonts when running in the minimal headless Qt platform. There is no security vulnerability here; it is purely a testing and robustness improvement.

This commit is a minor cleanup of the CMake build script used to locate the QR code encoding library. It removes an unnecessary helper function and simplifies how the library target is created. There is no indication this change fixes or introduces a security problem.

This is a minor cleanup change in Bitcoin Core's build system. It removes an unused 'pkgconfig' metadata directory left over after building the qrencode (QR code generation) dependency. There is no security issue here.

This commit removes an optional way CMake can locate the QR code library (libqrencode). Previously, the build system could use pkg-config to find the library's location and version. Now it will rely only on CMake's standard search paths. There is no security-relevant change here; it is a build-system simplification.

This commit is a documentation-only release note. It announces that two wallet commands, `send` and `sendall`, are no longer considered experimental. There is no code change, no bug fix, and no security issue in the commit itself.

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.