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.
Read more about k-anonymity [here](https://en.wikipedia.org/wiki/K-anonymity). We implement this feature in the monero daemon for transactions
by providing a "Txid Template", which is simply a txid with all but `num_matching_bits` bits zeroed out, and the number `num_matching_bits`. We add an operation to `BlockchainLMDB` called
`get_txids_loose` which takes a txid template and returns all txids in the database (chain and mempool) that satisfy that template. Thus, a client can
ask about a specific transaction from a daemon without revealing the exact transaction they are inquiring about. The client can control the statistical
chance that other TXIDs (besides the one in question) match the txid template sent to the daemon up to a power of 2. For example, if a client sets their `num_matching_bits`
to 5, then statistically any txid has a 1/(2^5) chance to match. With `num_matching_bits`=10, there is a 1/(2^10) chance, so on and so forth.
Co-authored-by: ACK-J <60232273+ACK-J@users.noreply.github.com>
- 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.
Before this change, if a multisig peer asked you to sign a transaction with a frozen enote, the wallet will do it without any error or warning. This change makes it
so that wallets will refuse to sign multisig transactions with frozen enotes.
Disclaimer: This PR was generously funded by @LocalMonero.
959a3e6 wallet2: ensure imported outputs subaddresses are created (moneromooo-monero)
a098504 wallet2: better test on whether to allow output import (moneromooo-monero)
c5579ac allow exporting outputs in chunks (moneromooo-monero)
1e912ec wallet2: fixes for export/import output flow (j-berman)
692f1d4 wallet2: do not assume imported outputs must be non empty (moneromooo-monero)
67b6d6a wallet2: prevent importing outputs in a hot wallet (moneromooo-monero)
d9fc666 wallet2: fix missing subaddress indices in 'light' exported outputs (moneromooo-monero)
600de07 wallet_rpc_server: longer timeout for stop_mining (moneromooo-monero)
ac6db92 functional_tests: silence the cpu power test program (moneromooo-monero)
Being offline is not a good enough heuristic, so we keep track
of whether the wallet ever refreshed from a daemon, which is a
lot better, and probably the best we can do without manual user
designation (which would break existing cold wallet setups till
the user designates those wallets)
There are vulnerabilities in multisig protocol if the parties do not
trust each other, and while there is a patch for it, it has not been
throroughly reviewed yet, so it is felt safer to disable multisig by
default for now.
If all parties in a multisig setup trust each other, then it is safe
to enable multisig.
The integrated address functional test fails in the workflows due
to an assertion for missing payment id that is no longer needed.
Remove the assertion and update the assertion count.
Fixes 7dcfccb: ("wallet_rpc_server: fix make_integrated_address with no payment id")
There are quite a few variables in the code that are no longer
(or perhaps never were) in use. These were discovered by enabling
compiler warnings for unused variables and cleaning them up.
In most cases where the unused variables were the result
of a function call the call was left but the variable
assignment removed, unless it was obvious that it was
a simple getter with no side effects.
8a282f6 Add RELINK_TARGETS, monero_add_target_no_relink and use monero_add_executable/monero_add_library where possible (mj-xmr) Add monero_add_minimal_executable and use in tests (mj-xmr)
Add monero_add_minimal_executable and use in tests
This is done in order not to have to relink targets, when just an .so changed, but not its interface.
d20ff4f64 functional_tests: add a large (many randomx epochs) p2p reorg test (moneromooo-monero)
6a0b3b1f8 functional_tests: add randomx tests (moneromooo-monero)
9d42649d5 core: fix mining from a block that's not the current top (moneromooo-monero)
jeffro256