Monero

This commit changes how Monero's public RPC endpoint 'get_transaction_pool' reports the contents of the memory pool (pending transactions). Previously, the endpoint could be called in 'restricted' mode and would hide some sensitive timing fields but still return transaction data. Now the endpoint always returns full timing metadata, but the entire method is blocked when the RPC is running in restricted mode. In short, the patch trades more complete data for a smaller attack surface: only trusted callers can query the transaction pool at all.

This commit tweaks how Monero's built-in background miner decides how long to rest between attempts. Previously the miner was forced to sleep at least 5 milliseconds; now it can sleep zero milliseconds. This is a small behavior change in a non-default, local-only feature and does not appear to be a security fix or vulnerability on its own.

This commit mostly turns on extra compiler warnings and fixes the code that those warnings flagged. The one behavior change is in wallet signature verification: both 'SigV1' and 'SigV2' signatures are now parsed using the same 5-character header length. That is a minor logic simplification, not a clear security fix. The rest of the changes are cleanup to prevent compiler warnings about missing 'fallthrough' annotations and hidden base-class methods.

This change caps how much data Monero's blockchain code pre-loads into a temporary memory cache when processing incoming blocks. Before, the cache could grow very large if a batch contained many transaction offsets, increasing memory use and potentially causing nodes to slow down or run out of memory. The patch limits the cache to roughly 100 MB and falls back to reading from the database when the limit is reached. It is a hardening/resource-management fix, not a clear-cut exploit patch.

This commit simply deletes unused code, comments, and internal statistics counters from the Monero codebase. It does not change any active behavior, fix a bug, or alter how the software processes transactions, blocks, or keys. There is no security issue here.

This commit changes a single log message so that it prints at the less prominent 'Debug' level instead of 'Info' when a peer reports a blockchain height only one block different from the node's own height. It is purely a logging/verbosity tweak and does not alter any network behavior, validation logic, or security mechanism.

This commit is a routine maintenance update that refreshes Monero's built-in blockchain checkpoints to match the latest v0.18.5.3 release. It changes version strings in documentation and updates two hardcoded checkpoint records to newer block heights and hashes. There is no code logic change and no indication of a security fix or vulnerability.

This commit is a small performance and code-quality change. It changes several functions that return copies of fixed cryptographic 'generator' values so that they return constant references instead. This avoids making unnecessary copies of values that never change. There is no security issue visible in the diff itself.

This commit changes three special cryptographic constants—named T, U, and V—used in Monero's upcoming FCMP++ privacy protocol. These constants are like fixed 'reference points' on a mathematical curve that the protocol relies on to prove transactions are valid without revealing who sent what. The old values were apparently copied from an outdated source and were wrong; the new values match the updated reference implementation. If the wrong constants had gone live, Monero's privacy proofs could have been broken or forged, potentially allowing someone to create fake coins or trace transactions. The commit itself only updates the byte strings and their sanity-check first bytes; it does not explain how the error was discovered or whether any real funds were at risk.

This Monero commit adds an optional size check to transaction parsing functions so that oversized transaction blobs from untrusted network sources are rejected before being decoded. It is a defensive hardening change that consolidates existing size checks and extends them to more code paths, reducing the chance that a maliciously large blob could waste resources or trigger memory-related issues during parsing.

This commit changes the order in which Monero checks incoming transactions. Instead of running an expensive consensus check first, it now checks cheaper 'no-drop' rules (like whether the transaction pays a valid fee and isn't already known) before doing the heavy validation. This is a performance and resource-usage optimization, likely to reduce denial-of-service risk from spam transactions. A second small change makes the spent-key-image check skip non-standard input types instead of asserting they never occur. The commit message and diff do not describe this as a security fix, and no independent researcher is credited.

This patch fixes a bug in Monero's peer-to-peer networking code. Previously, when the software tried to connect to 'seed nodes' (hardcoded first-contact servers that help a node find the network), it ignored the cache of recently-failed addresses. That meant an unreachable or rejecting seed node could be retried over and over again, wasting resources and potentially delaying or preventing a node from successfully joining the Monero network. The fix makes seed-node connections respect a shorter 5-minute 'cooldown' before retrying a failed seed, while normal peer connections keep the existing 1-hour cooldown.

This commit refactors how Monero checks whether a new block's timestamp is valid. It splits one timestamp-check function into two: a general helper and one specifically for the main chain. The change also moves the 'future time' check (rejecting blocks stamped more than 2 hours ahead of local time) and the 'not enough blocks' check into the general helper, and it makes the median timestamp output optional. The commit appears to be a code-quality and consistency improvement rather than a clear-cut security fix, but it does tighten behavior when there are fewer than 60 prior blocks and removes a const qualifier from one function. Without a vendor statement, we cannot say it fixes a known vulnerability.

This commit only adds the C++ keyword `static` to a single function declaration in a header file. It does not change what the function does, what data it can access, or how users interact with the software. There is no visible security effect.

This commit strengthens Monero's built-in random number generator so that if an attacker later steals the generator's internal memory state, they cannot easily figure out what random numbers were generated in the past. It also locks that sensitive state in RAM so it cannot be swapped to disk. The change is a defensive hardening patch, not a fix for an active exploit, and the exact real-world attack it prevents is not described in the commit materials.

This commit fixes a privacy and security bug where Monero wallets ignored the user's --no-dns setting and still performed DNS lookups for OpenAlias addresses (human-readable names like donate.getmonero.org). Now, when DNS is disabled or the wallet is offline, the wallet will not make those DNS queries. This prevents accidental network leaks and reduces the chance that a malicious or monitored DNS server could manipulate address resolution.

This commit adds an early safety check to Monero's transaction parsing code. It rejects transactions that contain an impossibly large number of 'key offsets'—the references that identify which previous transaction outputs a transaction is spending from. The limit is based on the maximum allowed transaction size, so any transaction exceeding it cannot be valid anyway. The change is defensive and prevents malformed or oversized transaction data from being processed further.

This patch tightens up how Monero's transaction pool records when to next re-broadcast relayable transactions. Previously, a database transaction was held open while iterating over all candidate transactions; now the lock is taken only when there are actual timestamp updates to write, and each update is wrapped in its own try/catch so one failing update does not abort the whole batch. The commit title says it fixes a 'write abort' and improves locking. The change reduces the chance that a transient database error or a single bad metadata update rolls back every scheduled relay update, which could have caused transactions to be re-relayed too soon or too late and potentially leak timing information about Dandelion++ routing.

This Monero patch fixes how the node keeps track of other peers' blockchain heights and who gets to receive new transactions. Previously, a node might think a peer was behind and stop sending it transactions, even when the peer actually had the latest block. The patch updates the peer's height when a new block is validated and allows a small two-block tolerance when choosing transaction-relay peers. The main risk if this were buggy or absent is degraded network propagation: transactions or blocks might spread more slowly, which can hurt network health and potentially be exploited to gain timing advantages (for example, in mining or double-spend scenarios).

This commit fixes a display-only bug in Monero wallets. When a transaction is split into multiple parts, the wallet was showing the change address from the first transaction piece, even if that piece had no change. The fix makes it show the first piece that actually has change. The commit message says misleading display is the only effect because foreign change addresses are already rejected during signing, so no money could be sent to an attacker's address.

This commit fixes several issues flagged by static analysis tools. Most changes add missing virtual destructors to C++ interface/base classes and remove unused function declarations. Missing virtual destructors can cause subtle memory bugs when objects are deleted through a base-class pointer, but the commit does not show any active crash or exploit path. It is a cleanup/hardening patch rather than a fix for a known active vulnerability.

This commit removes several database checks that Monero performed before forwarding a newly received block to other peers. Previously, the node verified that it had all the block's transactions and that no blockchain reorganisation had happened. Now it relays the block immediately with fewer checks. The stated goal is performance, but the change could allow invalid or stale blocks to be relayed more easily, potentially contributing to network confusion or denial-of-service. There is no direct evidence in the commit that this fixes a known security bug or that it introduces an exploitable vulnerability.

This change fixes a logic bug in Monero's blockchain handling. Previously, when the software saw a block it already knew about, it would simply mark it as 'already exists' and move on, even if that block had previously been flagged as invalid. After the patch, if a known-invalid block is seen again, the verification is now correctly marked as failed. This prevents an invalid block from being treated as harmless on re-submission and could stop certain denial-of-service or chain-integrity attacks.

This change lets users of Ledger hardware wallets see their private view key in the Monero command-line wallet, something previously hidden with the message 'On device. Not available.' The key is already cached inside the wallet software for normal operation; the patch simply exposes it through the existing `viewkey` command when the user asks. It does not appear to leak the key to anyone else or bypass hardware protections for the spend key.

This change adds a safety check when a Monero wallet verifies a 'reserve proof'—a document that supposedly proves someone owns enough funds without revealing which coins they are. The fix rejects reserve proofs that contain a mathematically invalid 'key image' (the special value zero, or a point outside the allowed cryptographic subgroup). Without this check, a maliciously crafted proof might trick the wallet into accepting or behaving unexpectedly on data that violates the protocol's assumptions.