monzero-core.git/tests/functional_tests/transfer.py, branch v0.18.4.3Monzero core node, command-line wallet, consensus code, and release tooling.
https://code.monzero.org/monzero-core.git/atom?h=v0.18.4.32025-07-07T22:21:46Zwallet: refactor subaddress expansion & add to transfer test2025-07-07T22:21:46Zjeffro256jeffro256@tutanota.com2025-07-07T20:07:24Zurn:sha1:1da19dac545bb5c0521949a212af42a7f351776ewallet: background sync with just the view key2024-05-25T03:42:59Zj-bermanjustinberman@protonmail.com2022-10-14T01:33:33Zurn: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.
wallet: feature: transfer amount with fee included2024-02-20T23:08:42Zjeffro256jeffro256@tutanota.com2023-05-14T16:41:59Zurn: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.
wallet2: fix rescanning tx via scan_tx2023-03-13T19:57:43Zj-bermanjustinberman@protonmail.com2022-09-10T02:34:18Zurn: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.
Bump ring size to 16 for v15 & remove set default in wallet cli2022-04-18T21:36:28Zj-bermanjustinberman@protonmail.com2022-02-12T01:01:23Zurn:sha1:5d388eb74d8095b0757e77b47a0da53ec54eb972Merge pull request #81972022-04-06T04:08:53Zluigi1111luigi1111w@gmail.com2022-04-06T04:08:53Zurn:sha1:0eb1b570b65103ca11bdacb1f87a76a64763cfea
da9aa1f Copyright: Update to 2022 (mj-xmr)
Copyright: Update to 20222022-03-04T05:59:20Zmj-xmrmjxmr@protonmail.com2022-03-01T11:16:17Zurn:sha1:da9aa1f7f802552b9de459f331a2f39c84898009Balance includes unconfirmed transfers to self2022-01-31T12:52:38Zwoodserwoodser@protonmail.com2022-01-30T22:03:56Zurn:sha1:e5000a9f0c664a7c2b522c8a7eb712ed178923f6Integrate CLSAGs into monero2020-08-27T12:44:04Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2019-06-09T13:02:16Zurn:sha1:82ee01699c2b910e44fd7362bd47d3a1cc9c26af
They are allowed from v12, and MLSAGs are rejected from v13.
Update copyright year to 20202020-05-07T02:36:54ZSomaticFanaticafdlkajdlfkj@aldkfjf.com2020-05-07T02:36:54Zurn:sha1:5ef0607da6042df51a57703bd223c5c8024741f6
Update copyright year to 2020