readline_buffer: fix start/stop threads being starved by process
process could run for quite some time re-acquiring the process
lock, leaving start/stop starving. Yielding after unlock in
process is much better but doesn't seem to be enough to reliably
yield, so we sleep for a millisecond, which should be transparent
for user input anyway.
Signed-off-by: Jethro Grassie <jtg@xtrabass.com>
If the refresh height is in the future, the current code will
loop till the actual height reaches this. Fix it by bailing out
if we receive only three hashes, which is what we set in the
call parameters.
The previous patch was based on a wrong premise (that the
daemon height was 0 because the daemon calling code wasn't
yet initialized). In fact, current height approximation
was not setup for testnet. Fix this.
Existing tests: block, transaction, signature, cold outputs,
cold transaction.
Data for these is in tests/data/fuzz.
A convenience shell script is in contrib/fuzz_testing/fuzz.sh, eg:
contrib/fuzz_testing/fuzz.sh signature
The fuzzer will run indefinitely, ^C to stop.
Fuzzing is currently supported for GCC only. I can't get CLANG
to build Monero here as it dies on some system headers, so if
someone wants to make it work on both, that'd be great.
In particular, the __AFL_LOOP construct should be made to work
so that a given run can fuzz multiple inputs, as the C++ load
time is substantial.
It'd eat up a core constantly, due to spending its time jumping
back and forth between userland and kernel. We now wait for up
to a millisecond in kernel, which will be transparent to the user
and drop to idle most of the time.
With the recent change to wallet creation code, the code was
calling to the daemon before the wallet's daemon address was
initialized, and thus failing. This was causing all new wallets
to refresh from 0 instead of just fetching early block hashes.
All code which was using ip and port now uses a new IPv4 object,
subclass of a new network_address class. This will allow easy
addition of I2P addresses later (and also IPv6, etc).
Both old style and new style peer lists are now sent in the P2P
protocol, which is inefficient but allows peers using both
codebases to talk to each other. This will be removed in the
future. No other subclasses than IPv4 exist yet.
It sweeps all outputs below the given threshold
This is available via the existing sweep_all RPC, by setting
amount_threshold the desired amount (in atomic units)
This avoids error spews from easylogging++ when we try to log
something before easylogging is initialized, which can happen
when errors happen at command line parsing time
It was wrongly refering to equiprobable distribution, which I think
I'd originally done, but forgot to update the comment after changing
to triangular
Reported by smooth on IRC
Two recent papers quantified the real usage bias for the
real output in a ring being the true one, and shows that
the current biasing is much too weak.
While we wait for a better solution, we increase the ratio
of recent-to-total fake outputs, as well as decrease the
time window for recent outputs, so that half the fake outs
are selected within the last 1.8 day. Value plucked from
figure 10, page 11 of An Empirical Analysis of Linkability
in the Monero Blockchain, 2017, Miller et al.
This is also arbitrary, of course, but serves as a stopgap
till a better selection algorithm is chosen.
If using a large input and many destinations, the code would
generate as many outputs as it could using that input, even if
it would bring the resulting tx above the max tx size.
They'd be rejected as suspicious as the change goes to more
than one destination. However, split transactions will most
likely include fake zero amount change to random addresses,
so we only consider change with non zero amount for this.
Because some people just won't even try to read what is written
and freak out because the word FATAL is in here, despite the
context making it clear it's not an error.
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.
The txid is not saved, and we want to make sure the transactions
have their txid cached while in the pool, since get_transactions
copies the transaction object, so any txid calculation on those
copies would not benefit any later caller, since the original tx
would be left without a cached txid.
Asking for a full histogram from a remote node (since it's
untrusted) is pretty slow, and spams the remote node, so
we replace it by only adding a second input if we have rct
ones, which are for all intents and purposes always mixable.
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).
If the blocks aren't being linked against a binary (such as
one of the blockchain utilities), the symbol will not be
NULL, but the size will be 0. This avoids a apurious warning
about the data hash.
