Monzero core node, command-line wallet, consensus code, and release tooling. https://code.monzero.org/monzero-core.git/atom?h=main 2026-06-08T21:54:22Z 2026-06-08T21:54:22Z woodser 13068859+woodser@users.noreply.github.com 2026-06-08T21:53:36Z urn:sha1:ad72a6c25342bc1694a787ba583e44beebea75e9 2024-05-25T03:42:59Z j-berman justinberman@protonmail.com 2022-10-14T01:33:33Z urn:sha1:e44e8b164030cfbddb9ae8b39251c1ccf396e2b6 - When background syncing, the wallet wipes the spend key from memory and processes all new transactions. The wallet saves all receives, spends, and "plausible" spends of receives the wallet does not know key images for. - When background sync disabled, the wallet processes all background synced txs and then clears the background sync cache. - Adding "plausible" spends to the background sync cache ensures that the wallet does not need to query the daemon to see if any received outputs were spent while background sync was enabled. This would harm privacy especially for users of 3rd party daemons. - To enable the feature in the CLI wallet, the user can set background-sync to reuse-wallet-password or custom-background-password and the wallet automatically syncs in the background when the wallet locks, then processes all background synced txs when the wallet is unlocked. - The custom-background-password option enables the user to open a distinct background wallet that only has a view key saved and can be opened/closed/synced separately from the main wallet. When the main wallet opens, it processes the background wallet's cache. - To enable the feature in the RPC wallet, there is a new `/setup_background_sync` endpoint. - HW, multsig and view-only wallets cannot background sync. 2024-04-29T05:08:53Z jeffro256 jeffro256@tutanota.com 2024-02-04T03:59:58Z urn:sha1:dd47d03cf2b5b3dc59cd99aca247d1025679f83a Related to https://github.com/monero-project/research-lab/issues/78 Added a relay rule that enforces the `unlock_time` field is equal to 0 for non-coinbase transactions. UIs changed: * Removed `locked_transfer` and `locked_sweep_all` commands from `monero-wallet-cli` APIs changed: * Removed `unlock_time` parameters from `wallet2` transfer methods * Wallet RPC transfer endpoints send error codes when requested unlock time is not 0 * Removed `unlock_time` parameters from `construct_tx*` cryptonote core functions @tobtoht: undo rebase changes tx.dsts -> tx_dsts 2024-02-20T23:08:42Z jeffro256 jeffro256@tutanota.com 2023-05-14T16:41:59Z urn:sha1:51d7a6921c8d6a337773f261a04301ef75ee5e3b To transfer ~5 XMR to an address such that your balance drops by exactly 5 XMR, provide a `subtractfeefrom` flag to the `transfer` command. For example: transfer 76bDHojqFYiFCCYYtzTveJ8oFtmpNp3X1TgV2oKP7rHmZyFK1RvyE4r8vsJzf7SyNohMnbKT9wbcD3XUTgsZLX8LU5JBCfm 5 subtractfeefrom=all If my walet balance was exactly 30 XMR before this transaction, it will be exactly 25 XMR afterwards and the destination address will receive slightly less than 5 XMR. You can manually select which destinations fund the transaction fee and which ones do not by providing the destination index. For example: transfer 75sr8AAr... 3 74M7W4eg... 4 7AbWqDZ6... 5 subtractfeefrom=0,2 This will drop your balance by exactly 12 XMR including fees and will spread the fee cost proportionally (3:5 ratio) over destinations with addresses `75sr8AAr...` and `7AbWqDZ6...`, respectively. Disclaimer: This feature was paid for by @LocalMonero. 2023-03-13T19:57:43Z j-berman justinberman@protonmail.com 2022-09-10T02:34:18Z urn:sha1:65e13dbef1c3a4cc036919203eec2052a121f034 - Detach & re-process txs >= lowest scan height - ensures that if a user calls scan_tx(tx1) after scanning tx2, the wallet correctly processes tx1 and tx2 - if a user provides a tx with a height higher than the wallet's last scanned height, the wallet will scan starting from that tx's height - scan_tx requires trusted daemon iff need to re-process existing txs: in addition to querying a daemon for txids, if a user provides a txid of a tx with height *lower* than any *already* scanned txs in the wallet, then the wallet will also query the daemon for all the *higher* txs as well. This is likely unexpected behavior to a caller, and so to protect a caller from revealing txid's to an untrusted daemon in an unexpected way, require the daemon be trusted. 2022-09-13T03:23:08Z j-berman justinberman@protonmail.com 2022-08-26T23:13:19Z urn:sha1:864a78ee5f5db4619c093e0dfb26bd03735d9fb1 2022-03-04T05:59:20Z mj-xmr mjxmr@protonmail.com 2022-03-01T11:16:17Z urn:sha1:da9aa1f7f802552b9de459f331a2f39c84898009 2021-04-07T14:10:16Z Elliot Wirrick wirrickelliot@gmail.com 2021-04-06T10:29:06Z urn:sha1:c8ff1d4d2380a70cdd804ba2b70a2988ac726b84 2020-10-13T15:23:35Z xiphon xiphon@protonmail.com 2020-10-12T21:13:58Z urn:sha1:ec14e4b8cd5b78c8d3251bb205294810b29f880e 2020-05-07T02:36:54Z SomaticFanatic afdlkajdlfkj@aldkfjf.com 2020-05-07T02:36:54Z urn:sha1:5ef0607da6042df51a57703bd223c5c8024741f6 Update copyright year to 2020