Monero

This commit simplifies how Monero's simplewallet decides whether a payment ID is a real encrypted ID or a dummy placeholder. Previously, the wallet checked both the payment ID value and whether any destination was an integrated address, and it would abort with an error if those two signals disagreed. Now it trusts only the actual payment ID value (a zero/empty value means dummy). The change removes a safety check that could reject otherwise-valid transactions, which could matter if the old check was too strict or could be triggered by unusual wallet/address combinations.

This small change removes a consistency check in Monero's command-line wallet when loading a saved transaction. Previously, the wallet verified that a 'dummy' payment ID label matched a special zero-value payment ID. Now it labels the payment ID as dummy based only on the zero value, without checking whether any destination is an integrated address. This could let a crafted saved transaction file display a misleading payment ID label, but it does not by itself steal funds or break cryptography.

This commit updates Monero's built-in blockchain checkpoints to match the v0.18.5.3 release. Checkpoints are hard-coded reference points that help nodes quickly verify they are following the correct chain and resist certain attacks. The change only updates data values (block heights and hashes) and version references in documentation; it does not introduce new code logic or fix a known vulnerability.

This commit adds two new read-only options to the wallet's remote procedure call (RPC) interface so users can request their public view key and public spend key. Public keys are meant to be shared openly and are not secrets, so exposing them through an existing authenticated API is not a security issue. The change also includes tests verifying the new behavior.

This commit only updates a submodule pointer for the external polyseed library from one commit hash to another. The actual code changes inside the submodule are not shown in the diff, and no public references were supplied. There is no visible security issue in the commit itself.

This commit adds cleanup of three additional memory buffers in Monero's seed-phrase key-stretching code. Before the change, leftover copies of intermediate secrets could remain in stack memory after the function finished. An attacker who could read process memory (for example, through another vulnerability or a memory dump) might recover parts of a wallet's seed-phrase secret. The patch wipes those buffers before returning, reducing that exposure.

This Monero update hardens how public keys and transaction pubkeys are handled. It moves a low-level 'torsion clearing' routine into the core crypto library, adds checks that wallet/destination addresses are valid points on the main subgroup of the curve, and normalizes transaction public keys before they are used for payment-ID decryption, transaction proofs, and hardware-wallet communication. The changes reduce the risk that malformed or small-subgroup public keys could be used to confuse wallet logic, leak information, or cause inconsistent behavior. The commit message frames it as a fix for 'inconsistent tx pubkey handling' and a crypto cleanup, not as an active-exploit patch.

This Monero update makes the network layer clean up leftover block download records when a peer connection fails or is rejected. Previously, rejected or disconnected peers could leave stale block spans in a queue, which might cause the node to skip fetching those blocks from other peers and potentially stall synchronization. The fix flushes those stale spans so the node can re-request the blocks elsewhere.

This change upgrades the Monero RPC server's HTTP Digest Authentication to support SHA-256 and adds a command-line flag to disable the older MD5 algorithm. MD5 is considered weak by modern security standards, so this gives node operators a way to enforce stronger authentication hashing. By default, both MD5 and SHA-256 are still offered, so the change is backwards-compatible and does not by itself remove the weaker option.

This Monero update tightens how the network handles trimmed-down (pruned) transaction data shared between nodes. Before, a node could accept extra junk bytes tacked onto the end of a pruned transaction blob. Now it rejects such blobs. This closes a potential avenue for malformed data to be accepted or processed unexpectedly, which could lead to inconsistent node state or denial-of-service issues.

This Monero update improves how nodes download and queue blocks during blockchain synchronization. It changes the way pruned block sizes are counted, adds a check that pruned block weights match known values, and switches the download queue limit from a fixed number of spans to a dynamic number of blocks based on download speed. The changes are defensive: they reduce the chance that a misbehaving peer can feed incorrect block-size data that would make a node request too much or too little data, and they fix arithmetic overflow/underflow risks in the sync-size calculations. There is no direct evidence in the commit that these flaws were exploited or that the project calls this a security fix.

This change removes the 'strip unassigned code points' option from two Unicode text normalization functions used when handling Polyseed mnemonic seed phrases. Previously, characters that Unicode has not officially assigned any meaning to were silently removed during normalization. Now they are preserved. The practical effect is that a seed phrase containing such rare characters would normalize differently before and after this patch, which could in theory change the wallet key derived from the phrase. The commit message does not call this a security fix; it is described as a correctness fix for normalization.

This Monero commit changes how sensitive random-number and hash-key setup is performed. Previously, some initialization code could run automatically during program startup in a way that wasn't guaranteed to be thread-safe, and the secret SipHash key was directly accessible as a global variable. The patch makes initialization happen on first use using platform-native 'run once' primitives, splits the SipHash key initialization into its own guarded routine, and hides the key behind an accessor function. These are defensive hardening improvements; the commit message does not frame them as fixing an active vulnerability.

This commit only fixes spelling mistakes in code comments and documentation strings. No actual program logic, math formulas, or executable code was changed. It cannot affect security in any way.

This commit adds a safety check in Monero's hardware wallet USB communication code. Before reading another chunk of data from a Ledger/Trezor-like device, it now verifies that the next chunk will fit inside the fixed-size memory buffer. Without this check, a malicious or malfunctioning USB device could trick the software into writing past the end of the buffer, potentially crashing the wallet or corrupting memory. The fix is a straightforward bounds check, but it is only one of several reads in the same loop, so it may be a partial hardening rather than a complete fix for every overflow path.

This change fixes a bug in how Monero nodes reserve chunks ('spans') of blocks to download from peers. Previously, two different peers could be assigned the same starting block height with different expected block hashes, causing confusion about which blocks to request and potentially wasting bandwidth or delaying sync. The fix makes the reservation step check for conflicts before committing, and returns failure if the same height is already reserved by another peer. There is no direct evidence in the commit message that this was publicly disclosed as a security vulnerability.

This change adds a safety check when a Monero node packages a block for relay to other nodes. Before this patch, if a block somehow contained the same transaction hash twice, the node would not notice and could produce an invalid or malformed block package. The fix detects duplicate transaction hashes and throws an error instead of silently continuing. The commit message does not describe this as a security fix, so its security relevance is uncertain, but duplicate-hash bugs in consensus-related code can sometimes be exploited to cause network disruption or inconsistent state.

This Monero update tightens validation around multisig key images and imported multisig data. Multisig wallets require several participants to combine pieces (partial key images and signing nonces) to spend funds. The patch makes the wallet reject incomplete or duplicate pieces before it accepts them, instead of silently building a broken key image. It also fixes an incorrect count check used when importing multisig data. The changes are defensive hardening; they do not by themselves show that money could be stolen, but they close paths where malformed or inconsistent data could cause incorrect key images, failed transactions, or potential misuse.

This Monero update fixes two related bugs in how the node downloads and processes batches of blocks from peers. First, it ensures every block in an incoming batch is fully parsed even when some blocks are already known, so the node does not accidentally skip validation steps. Second, it prevents the node from asking different peers for the same block ranges twice at the same time, which could waste bandwidth and potentially confuse the sync logic. The commit does not describe these changes as security fixes, but they touch on consensus-critical code paths.

This patch tightens validation of Monero 'key images'—the special values that prevent the same coin from being spent twice. Before the change, a malformed key image that was either the identity point or had a small-order/torsion component could potentially slip through ring-signature verification. The fix rejects the identity key image outright and multiplies the key image by the curve order to confirm it lies on the proper subgroup, returning false if it does not. This closes a path that could let an attacker craft a signature that looks valid but does not actually mark a real coin as spent, which in Monero can translate to a double-spend or balance-inflation risk.

This change fixes a privacy leak in Monero's restricted RPC mode. When a node operator enabled restricted RPC (used for public RPC endpoints), the get_block_template RPC call could still include sensitive transactions—specifically Dandelion++ stem transactions that are not yet meant to be publicly broadcast. A remote user could request a block template from a restricted RPC node and learn about transactions that ordinary network participants should not yet see, weakening transaction privacy. The patch adds an include_sensitive flag that defaults to true for normal callers but is set to false when the request comes through a restricted RPC context, so those transactions are excluded from the returned template.

This patch changes the order in which two internal locks are acquired in a Monero blockchain-checking function. In multi-threaded software, taking locks in the wrong order can cause a 'deadlock,' where two parts of the program wait forever for each other and the node can freeze. The change makes the lock order consistent with the rest of the codebase, which is a defensive fix. There is no direct evidence in the commit that an attacker can trigger the deadlock on demand, but lock-order bugs are a classic source of denial-of-service problems in network-facing daemons.

This commit hardens a Monero blockchain lookup function so it returns a clean failure instead of letting an internal 'transaction does not exist' exception bubble up. The change makes the node more robust when asked about outputs for a transaction that is missing from the database, which could previously crash or abort the calling code path.

This change adds a safety check in Monero's core code that rejects a block if it contains the same transaction hash more than once, before looking those transactions up in the memory pool. Duplicate transaction hashes in a single block could cause inconsistent behavior or be exploited to manipulate how transactions are fetched and included. The fix is small and defensive, but the commit message does not describe a specific attack or security impact.

This commit adds support for a new type of wallet backup phrase called Polyseed to the Monero wallet software. It touches many wallet components (CLI, RPC, library API) so users can create, restore, and display Polyseed backups alongside the older 25-word legacy seeds. The change also stores a new Polyseed field in encrypted wallet files and handles passphrases/seed offsets in a specific way. There is no direct evidence in the commit that this fixes an active security bug; it reads as a large feature addition. However, because it changes how secret key material is serialized, encrypted, and derived from seed words, any mistakes in this area could affect wallet security or recoverability.