Monero

This commit updates Monero's built-in blockchain checkpoints to match the v0.18.5.0 release. Checkpoints are hardcoded trusted block hashes that help nodes quickly verify they are following the correct chain and protect against certain attacks. The change is routine release housekeeping: it advances the latest checkpoint from block 3,609,000 to block 3,661,900, updates the binary checkpoint data file, refreshes the expected hash of that file, and updates the README's recommended version table. There is no code logic change and no indication of a security vulnerability being fixed.

This small Monero patch fixes a notification bug in the transaction pool. When a privacy-protecting 'stem' transaction is later re-broadcast as a normal 'fluff' transaction, the code now correctly reports the updated relay method to external listeners (such as the ZMQ event stream). Previously, the notification used the original relay method, which could mislead external tools about how the transaction was actually being relayed. There is no direct evidence this enables theft or remote code execution, but it could confuse monitoring systems or weaken privacy-related analytics.

This patch fixes a bug in how Monero announces new mempool transactions over its ZeroMQ publish (ZMQ-PUB) interface. Before the fix, transactions that first arrived in a privacy-preserving 'stem' phase were incorrectly announced as if they were ordinary public mempool transactions, potentially leaking information about transaction timing or origin. The fix now only sends the ZMQ notification when the transaction is genuinely being broadcast publicly for the first time.

This commit adds a safety check when building Monero transactions to make sure any 'change' output (leftover funds returned to the sender) actually belongs to the sender's wallet. Before this change, a wallet or tool could accidentally specify a change address it did not control, sending leftover funds to a stranger or attacker. The fix re-derives the change address from the wallet's keys and rejects the transaction if it does not match. It is a defensive hardening measure rather than a fix for an active remote exploit.

This commit fixes command-line handling in Monero's blockchain utility programs. It makes sure the --data-dir option works correctly with the newer --regtest network mode, and centralizes the logic that decides which network type (mainnet, testnet, stagenet, or regtest) is being used. It is a code-quality and correctness fix rather than a security patch for an exploitable vulnerability.

This change refactors how a Monero node cleans up after receiving blocks. Previously, every early-exit path had to remember to call a cleanup routine and remove a queued block span; now a single scope-exit handler does it automatically. The main risk is that any path that used to skip cleanup now runs it, or that the new handler runs in a different order with surrounding code. The patch appears intended to prevent resource leaks or stuck block queues when a peer misbehaves or the node is shutting down.

This small code change converts a function that computes a pruned transaction hash from one that throws exceptions on failure to one that returns a success/failure boolean. Callers now check that boolean and stop processing if the hash could not be calculated. The main practical effect is to prevent malformed or version-1 pruned transactions from causing unhandled exceptions or being processed with an unset hash, which could lead to denial-of-service or incorrect wallet/node behavior.

This commit adds exception handling around two network callback functions and changes one block-queue function to log errors instead of throwing exceptions. It appears aimed at preventing unhandled exceptions from crashing or destabilizing network connections during message processing. The change is defensive and does not obviously introduce a security vulnerability, but it is only a partial hardening patch.

This change only modifies a test script for Monero's automated functional tests. It replaces one way of setting up test blockchain state (mining through a wallet) with another (generating a block directly via the daemon and rescanning the wallet). It also makes two test assertions more explicit about expecting a connection to be rejected. There is no change to the actual Monero node, wallet, or RPC authentication code that users run, and nothing here suggests a security vulnerability or fix in production software.

This patch fixes a configuration bug where Monero's regression-test mode (regtest) was accidentally sharing its data folder and peer list with the real main network. Before the fix, someone running a local test chain could read or overwrite the same on-disk peer state used by mainnet. The patch makes regtest use its own separate 'fake' subdirectory and ensures regtest nodes do not try to contact mainnet seed nodes. It is a hardening fix for test/mainnet isolation, not a remote exploit.

This is a small cleanup in Monero's test code. It removes a custom helper called addressof that was used only in unit tests and replaces it with the standard C++ std::addressof. The change also adds a compile-time check that the tested types have a single, unambiguous memory layout. There is no direct evidence this fixes an active security bug in production code, but it removes a potentially risky custom overload near secret key handling and makes the test stricter.

This commit fixes low-level memory handling bugs in Monero's ChaCha encryption code. The old code read and wrote 32-bit numbers by directly casting byte pointers, which can break strict-aliasing compiler rules and crash or misbehave on processors that require aligned memory access. The fix copies bytes through memory-safe helper functions instead. This is a defensive correctness fix in cryptographic code; the commit message calls it an 'aliasing and alignment' fix but does not describe a specific exploit.

This commit changes a low-level cryptographic helper function in Monero that checks whether a secret scalar number is valid. The original code used direct left bit-shifts on signed integers, which is officially undefined behavior in standard C when the value is negative. The patch replaces those shifts with a helper that either relies on GCC's well-defined behavior or multiplies by a power of two instead. The concern is that undefined behavior in cryptographic code could, in theory, lead to incorrect validation of secret keys, but the commit itself does not describe a concrete exploit or security incident.

This change wraps a blockchain preparation step in a safety net so that if something unexpectedly throws an error, the node still runs cleanup code instead of leaving locks or state in an inconsistent condition. It is a defensive hardening patch rather than a clear fix for a known exploitable bug.

This commit tightens how Monero's built-in HTTP client handles password-based authentication (HTTP Digest). It removes support for an older, weaker mode that did not use a client nonce ('cnonce'), and now always generates a random cnonce using OpenSSL's secure random generator. This makes replay and certain man-in-the-middle attacks against the HTTP client harder. The change also updates the tests to expect the new, stricter behavior.

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 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 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 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 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.