Monero

This commit tightens how Monero's network code reassembles split-up network messages. Previously, when fragments were stitched back together, the code trusted the size written in the message header without checking whether the actual reassembled buffer was at least that large. That could let a malformed message cause the code to read past the end of its buffer. The patch adds a size check and trims the buffer to exactly the claimed size before further processing. A new test confirms the handler now rejects a case where the header claims more data than the fragments actually provide.

This commit adds SOCKS5 proxy support to the Monero daemon and wallet, expanding the older SOCKS4/SOCKS4a support. It introduces new URI parsing for proxy strings, optional username/password authentication, IPv6 support, and new command-line options. The change is a feature addition, not a documented security fix. The code does include some security-relevant notes (for example, warning that proxy credentials may appear in the process list), but nothing in the commit message or diff states that a vulnerability is being patched.

This commit fixes a bug in how Monero builds the 'extra nonce' field inside transaction metadata. Previously, the code always reserved only 2 bytes for the length header, which is wrong for larger nonces because the protocol uses a variable-length integer (varint) that can take more than 1 byte. The patch now correctly calculates how many bytes the length needs and writes it as a proper varint. The bug could corrupt transaction extra data or cause parsing failures when nonces larger than 127 bytes are used, but the maximum allowed nonce size (255 bytes) limits the damage. There is no public statement from the Monero Project calling this a security issue, and no independent researcher is credited.

This commit removes the Boost serialization code for a Monero internal data structure called tx_source_entry. It deletes about 20 lines of code that described how this structure is converted to/from a serialized format. The change appears to be a cleanup or hardening step, not a fix for an active vulnerability. There is no direct evidence in the commit that this change addresses a security bug, and no public references were provided.

This commit changes the Monero build system (Makefile) to fix problems when running builds in parallel. It explicitly tells CMake to generate Unix Makefiles and uses the standard $(MAKE) command instead of cmake --build. There is no security relevance in the diff itself.

This commit renames and rewrites a Monero function used to compute a 'zero-commitment' Pedersen commitment (a cryptographic value that hides transaction amounts). The new implementation uses a precomputed table and a vartime (variable-time) bit-by-bit addition to make the calculation about six times faster. The commit does not claim to fix any security bug, and the diff itself shows no signs of a vulnerability. The main risk is that the new code must produce exactly the same results as the old code, otherwise consensus between nodes could break.

This commit replaces older Boost timer types with newer, more robust standard-library-based timers throughout Monero's networking code. It is primarily a modernization and maintainability change. There is no direct evidence in the commit that it fixes an active security vulnerability, though using the newer timer API can help avoid subtle timing bugs in the long run.

This commit is a routine maintenance update that adds a new blockchain checkpoint and updates version references in documentation. Checkpoints are like agreed-upon 'milestones' in the blockchain that help nodes sync faster and resist certain attacks. There is no indication of a security fix or vulnerability in this change.

This is a routine maintenance patch that makes Monero compile cleanly on the upcoming Clang 21 compiler. The most notable change is replacing the aggressive '-Ofast' optimization flag with '-O3 -ffast-math -fno-semantic-interposition', which removes a compiler option that could theoretically allow unsafe floating-point and memory optimizations. The rest of the patch removes dead code, unused variables, and compiler warnings. There is no direct evidence this fixes an active security vulnerability, but the compiler-flag change is a sensible hardening step.

This Monero commit changes how many future blocks a node asks peers for during initial sync. Previously the node would always download up to 1,000 blocks ahead regardless of conditions. Now it calculates a dynamic limit based on recent download speed and a user-configurable 'span-limit' (default 2 minutes of blocks). The change also tightens the logic so the node only proceeds to request more blocks when it actually needs the next block or when queue limits allow. It is primarily a performance and robustness improvement, not a clear security fix, though the old behavior could have made nodes easier to overload with excessive download requests.

This commit is a massive merge of pull request #9494 titled 'dynamic block sync size' into the Monero repository. The supplied diff only shows the addition of repository boilerplate files (git attributes, GitHub Actions CI workflows, gitignore, gitmodules, CMakeLists.txt, Dockerfile, Doxyfile, etc.) and does not include the actual code changes related to 'dynamic block sync size'. There is no security-relevant code change visible in the provided materials.

This commit adds more detailed information about where transaction inputs come from to a wallet RPC command called describe_transfer. It is a feature enhancement that exposes source details (amount, global index, ring signature type, public key) to RPC callers. There is no indication in the commit that this fixes a security vulnerability or introduces a dangerous capability.

This commit swaps out one Monero project domain ending in .no for one ending in .co in three places: software update checks, a DNS debugging tool, and a peer network blocklist. It is a routine infrastructure/domain-list change. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be domain housekeeping, possibly because the .no domain was lost, expired, or no longer controlled by the project.

This commit is a performance optimization for a Monero daemon RPC endpoint called /is_key_image_spent. It speeds up wallet rescan operations by reading on-chain key images in a single database transaction and by querying the memory pool more efficiently. The change is framed as a fix for severe daemon slowdowns during stress testing, not as a security vulnerability. There is no direct evidence in the commit of a security flaw, but the prior behavior could be abused to cause denial of service by sending many expensive queries.

This change makes two wallet RPC commands, `get_transfers` and `get_transfer_by_txid`, usable in 'restricted' mode, which previously blocked them entirely. In restricted mode, these commands can now read confirmed and historical wallet transaction data, but they still cannot refresh the mempool/pool state. The change is described by the project as an intentional relaxation of restrictions, not as a security fix. It may expose more wallet history to anyone who can reach a restricted wallet RPC, but it does not by itself bypass authentication or steal funds.

This commit is a performance refactor of how Monero nodes cache expensive ring-signature verification results for transactions sitting in the memory pool (mempool). It replaces an in-memory cache limited to 8,192 entries with a persistent verification ID stored in each mempool transaction's metadata. The change is described by the author as improving block propagation and reorg handling, not as a security fix. The main risk is that if the verification ID is ever set incorrectly or reused with the wrong mix-ring data, a node could skip cryptographic checks on a bad transaction, which would be a consensus bug. The diff includes careful checks and unit tests, but it is a large, complex change touching core consensus code.

This commit updates Monero's built-in blockchain checkpoints to match the latest software release (v0.18.4.5). Checkpoints are hardcoded reference points that help nodes quickly verify they are following the correct chain and protect against certain types of attacks. The change is routine maintenance: it adds one new checkpoint at block height 3576000, updates a hash that verifies the checkpoint data file, and updates the recommended minimum version in documentation. There is no indication this fixes an active security vulnerability.

This patch fixes a bookkeeping bug in the Monero wallet. When a transaction temporarily disappears from the network's pending pool and is later re-broadcast, the wallet could wrongly treat the coins it spends as still available. That could let the wallet try to spend the same coins twice, producing a conflict that prevents any of those follow-up transactions from confirming until the wallet state is manually repaired.

This patch fixes a timing bug in Monero's peer-to-peer syncing. Previously, a node could read its own blockchain height, then a new block could be added in another thread, and then the node would ask a peer for older blocks using an out-of-date height. This mismatch could cause the node to think the peer's first returned block was wrong and drop the connection, making sync slower or less reliable. The fix reads the height and the list of block hashes together under the same lock so they cannot get out of step.

This is a tiny C++ code cleanup. The function `cn_variant1_check` was marked `constexpr` (a hint that it can be evaluated at compile time), but because it contains a runtime-only check (`if (variant == 1 && length < 43)` followed by an error path), that marking is invalid in newer C++ standards. The patch simply removes the `constexpr` keyword so the code compiles correctly. There is no change to what the function actually does, no security behavior change, and no bug fix beyond compiler compliance.

This commit fixes a minor user-experience issue in Monero's command-line wallet. Previously, when you ran the export_transfers command, the wallet would always say the CSV file was exported successfully even if the file could not actually be written (for example, because of missing permissions or a full disk). Now it checks whether the file opened and whether writing succeeded, and reports a clear failure message instead of falsely claiming success.

This commit simply adds the USB product ID for a new Ledger hardware wallet model (Nano generation 5) to Monero's list of supported Ledger devices. It is a one-line addition to a device identification table and does not change any security logic, cryptography, or transaction handling.

This commit changes a default setting for how many threads Monero uses when preparing block hashes. Previously it was hardcoded to 4 threads; now it uses the number of CPU cores the computer reports (falling back to 4 if that number can't be determined). This is a performance tuning change, not a security fix. There is no direct evidence in the commit that it addresses a vulnerability.

This commit changes only a single word in the help text of the Monero command-line wallet's 'transfer' command. It swaps the order of two placeholders in the description from 'Transfer <amount> to <address>' to 'Transfer <address> <amount>' so the wording matches the actual command syntax. There is no code change, no security fix, and no behavior change.

This commit is a performance optimization for Monero's transaction memory pool. When one node asks another for transactions it is missing, the old code compared every requested hash against every pool transaction one-by-one, which becomes extremely slow when the pool is large (tens of thousands of transactions). The new code sorts the requested hashes once and uses binary search, cutting the work by roughly 99.8%. The main security-relevant angle is that the old code could be abused to make a node waste CPU time, potentially contributing to a denial-of-service condition.