a28950da setThreadName moved in new version of easylogging++ (moneromooo-monero)
ea359b50 Fixup choice of easylogging++ vs libunwind stack trace code (moneromooo-monero)
1e6d8757 easylogging++: do not disable DEBUG level based on _DEBUG/NDEBUG (moneromooo-monero)
7a56fd6c easylogging++: detect DragonFly BSD as a UNIX (moneromooo-monero)
2c8b23e3 easylogging++: fix logging with static const header only data members (moneromooo-monero)
72663f4b easylogging++: allow clipping a common filename prefix (moneromooo-monero)
5bab0449 easylogging++: add file-only logs (moneromooo-monero)
db9dc7c2 eayslogging++: Fix bad memory access before opening any files (moneromooo-monero)
14620ca0 easylogging++: avoid creating directory/filename for the builtin default log file (moneromooo-monero)
0c1ad0ff easylogging++: Print thread ID in a nicer way (moneromooo-monero)
e7fabbd4 easylogging++: add categories (moneromooo-monero)
a8ac4f0a update easylogging++ to latest upstream (moneromooo-monero)
Pass relevant information to the base class instead of overwriting
default values later, use objects instead of pointers to objects
to avoid having to new objects unnecessarily.
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.
