With the change from the original transfer method to the new
algorithm, payments to the same destination were merged. It
seemed like a good idea, optimizing space. However, it is a
useful tool for people who want to split large outputs into
several smaller ones (ie, service providers making frequent
payments, and who do not like a large chunk of their balance
being locked for 10 blocks after each payment).
Default to off, which is a change from the previous behavior.
When a single input is enough to satisfy a transfer, the code would
previously try to add a second input, to match the "canonical" makeup
of a transaction with two inputs and two outputs. This would cause
wallets to slowly merge outputs till all the monero ends up in a
single output, which causes trouble when making two transactions
one after the other, since change is locked for 10 blocks, and an
increasing portion of the remaining balance would end up locked on
each transaction.
There are two new settings (min-output-count and min-output-value)
which can control when to stop adding such unneeded second outputs.
The idea is that small "dust" outputs will still get added, but
larger ones will not.
Enable with, eg:
set min-output-count 10
set min-output-value 30
to avoid using an unneeded second output of 30 monero or more, if
there would be less than 10 such outputs left.
This does not invalidate any other reason why such outputs would
be used (ie, when they're really needed to satisfy a transfer, or
when randomly picked in the normal course of selection). This may
be improved in the future.
New pull request because I couldn't figure out how to change the previous one.
1. For clarity, I want to focus the help text for the 'transfer' command on the most typical use case (a single payment).
2. New users will prefer to use 'transfer', so the older method 'transfer_original' should refer to 'transfer' rather than the other way around.
This would otherwise be a silent noop, which is confusing.
This can happen if the daemon is started, but not yet ready
to service all requests, and this is a safe catch all.
Minimum mixin 4 and enforced ringct is moved from v5 to v6.
v5 is now used for an increased minimum block size (from 60000
to 300000) to cater for larger typical/minimum transaction size.
The fee algorithm is also changed to decrease the base per kB
fee, and add a cheap tier for those transactions which we do
not care if they get delayed (or even included in a block).
7a44f38a Add support for the wallet to refresh pruned blocks (moneromooo-monero)
da18898f ringct: do not require range proof in decodeRct/decodeRctSimple (moneromooo-monero)
b49c6ab4 rpc: add a default category for daemon rpc (moneromooo-monero)
f113b92b core: add functions to serialize base tx info (moneromooo-monero)
6fd4b827 node_rpc_proxy: allow caching daemon RPC version (moneromooo-monero)
b5c74e40 wallet: invalidate node proxy cache when reconnecting (moneromooo-monero)
c02e1cb9 Updates to epee HTTP client code - http_simple_client now uses std::chrono for timeouts - http_simple_client accepts timeouts per connect / invoke call - shortened names of epee http invoke functions - invoke command functions only take relative path, connection is not automatically performed (Lee Clagett)
- http_simple_client now uses std::chrono for timeouts
- http_simple_client accepts timeouts per connect / invoke call
- shortened names of epee http invoke functions
- invoke command functions only take relative path, connection
is not automatically performed
