Monero

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

This commit changes how a Monero node announces a newly found block to peers. Previously, the node would fetch and attach the actual transaction data to the announcement. After the change, it sends an 'empty fluffy block' announcement that contains only the block header and a list of transaction hashes, leaving peers to request missing transactions themselves. This is a network-efficiency optimization, but it removes a local consistency check and shifts responsibility for transaction availability to peers.

This fix corrects a bookkeeping bug in Monero's transaction memory pool. The pool tracks its total weight (size) and prunes transactions when it thinks it is too full. Because the same transaction could be counted twice—once when relayed privately and again when received from another peer—the pool could believe it was over its weight limit and remove transactions prematurely. This could make the node behave differently from honest nodes, potentially affecting transaction relay and network consistency, but it does not directly steal funds or break cryptography.

This change hardens how the Monero wallet software talks to a Ledger hardware wallet. Previously, if the user rejected exporting the secret view key from the Ledger, the software silently accepted a fake placeholder key and continued with reduced functionality. Now the software throws a clear error and stops. This prevents a scenario where the wallet might proceed in a confused state after the user explicitly denied key export.

This patch fixes a deadlock bug in Monero's logging system. A deadlock is a situation where two or more parts of the program get stuck waiting on each other forever, which can freeze the software. The fix changes how log messages are built so that user-provided code (which might itself use locks) is evaluated before the logger takes its own internal lock, preventing the logger's lock and user locks from being held at the same time in a way that could cause a freeze. The commit includes a new test that reproduces the deadlock scenario.

This patch fixes a bookkeeping bug in how Monero decides which blockchain blocks to request next from peers. Previously, when two requested block ranges overlapped, the node could incorrectly think it already had a block it did not have, causing it to skip asking for that block. That could stall synchronization or leave a node stuck on an older chain. The fix correctly merges overlapping or adjacent ranges when calculating the next missing height.

This commit is a routine maintenance update that adds a new blockchain checkpoint and updates version references in documentation. Checkpoints are a normal mechanism that help Monero nodes agree on the correct chain history and speed up initial synchronization. There is no indication of a security fix, vulnerability, or malicious change in the diff.

This change makes Monero's blockchain rewind operation stop early if the user sends an interrupt signal (Ctrl-C). Previously, the code would keep popping blocks even after being told to cancel, which could leave the blockchain database in an inconsistent or poorly defined state. The fix is a one-line check of a cancellation flag inside the loop that removes blocks.

This commit is titled 'rpc: remove COMMAND_RPC_SUBMIT_RAW_TX', but the actual diff supplied is not an RPC removal. It is a massive initial import or re-import of the entire Monero repository (693,211 added lines across 1,360 files). No security-relevant code change is visible in the provided diff, and the diff does not show the removal of any RPC command. The supplied materials are inconsistent with the commit title.

This Monero commit changes how payment IDs are handled when the wallet receives money. Previously, the user-facing wallet interface (simplewallet) decrypted the payment ID itself from transaction data. Now, the core wallet engine (wallet2) decrypts or extracts the payment ID earlier in processing and passes the already-decrypted value to the interface. This is mostly a code cleanup and consistency improvement. It does not appear to be a security fix on its own, but it touches privacy-sensitive payment ID handling and removes duplicated decryption logic.

This is a small code cleanup, not a security fix. A database function had a 'skip coinbase' option that was always turned on and didn't actually work when turned off. The patch removes the broken, unused option entirely. The only caller kept using the same behavior, so nothing changes for users.

This commit adds a new optional flag to the Monero daemon's binary RPC for fetching blocks. When enabled, the daemon skips sending the one block the client already knows about, reducing bandwidth. The change is backward-compatible (default is the old behavior) and appears to be a routine protocol optimization, not a security fix.

This commit removes a redundant safety check in Monero's transaction validation code. The commit message argues the check was unnecessary because other rules already enforce the same limits: no bulletproofs before protocol version 8, and only one bulletproof covering all outputs from version 8 onward. The change is presented as cleanup, not a security fix.

This commit is a large repository initialization or merge that adds the entire Monero codebase, build files, documentation, tests, and GitHub CI configuration. The only functional code change explicitly described in the merge message is a governance rule for the Code of Conduct: only GitHub Administrators are allowed to merge changes to it. There is no indication of a security bug fix or vulnerability patch in the supplied materials.