Transactions in the txpool are marked when another transaction
is seen double spending one or more of its inputs.
This is then exposed wherever appropriate.
Note that being marked with this "double spend seen" flag does
NOT mean this transaction IS a double spend and will never be
mined: it just means that the network has seen at least another
transaction spending at least one of the same inputs, so care
should be taken to wait for a few confirmations before acting
upon that transaction (ie, mostly of use for merchants wanting
to accept unconfirmed transactions).
d0463312 fix libwallet api test after api change (Jaquee)
a46c1eed Wallet2: Don't throw when subaddress label doesn't exist (Jaquee)
086b7db2 Wallet API: default values for account and subaddr index (Jaquee)
Lack of it results in `m_refresh_from_block_height` being < 0 (18446744...) on low heights, which blocks `process_new_blockchain_entry` and never process coins on heights less than blocks_per_month.
Follow-up to #2258
a15e8583 wallet2: guard against daemon sending txes in the wrong order (moneromooo-monero)
8fe5f609 rpc: order transactions in the order they were requested (moneromooo-monero)
d58700e0 WalletAPI: only allow trusted daemon when importing key images (Jaquee)
8a9bbd26 WalletAPI: copy wallet data when creating a view only wallet (Jaquee)
d27fe32e wallet2: export/import wallet data functions (Jaquee)
225a25f3 import_key_images - allow importing without being connected to daemon (Jaquee)
b7d6ec83 simplewallet: add (out of sync) or (no daemon) markers in the prompt (moneromooo-monero)
fa23a500 wallet2: add a is_synced function (moneromooo-monero)
f1307bbd node_rpc_proxy: add a proxy for target height (moneromooo-monero)
When scanning the txpool without having first updated the
blockchain, the tx would be seen as neither in the txpool
nor the chain, and removed, so it'd only reappear once the
chain is refreshed, and the tx seen in a block.
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.
e2529347 Correct spelling of 'get_upper_transaction_size_limit' (Nano Akron)
3029d0ef Remove the 1.25x multiplier in max transaction size in just the wallet (Nano Akron)
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)
a6d5bb75 wallet2: refer to triangular distribution for recent zone in comment (moneromooo-monero)
ac1aba90 wallet2: bias fake outs more towards recent outputs (moneromooo-monero)
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.
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.
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.
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).
This reverts commit d47dac9a88.
Callers actually expect the key to be payment id, so this
needs a lot more changes (like storing payment ids in the
structure, and possibly also to other existing structures
which do the same thing).
A relatedness check was meant to be done in the case of adding
an extra output if just one was enough. This was mistakenly
added to the "preferred output" case.
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)
If a rct transaction can be made with just one input, a second
output will be added. This output will be the smallest amount
output available. However, if this output is a non rct output
with less available fake outs than requested, the transaction
will be rejected. We now check the histogram to only consider
outputs with enough available fake outs in the first place.
These warnings were emitted by clang++, and they are real bugs.
src/rpc/core_rpc_server.cpp:208:58: warning: adding 'uint64_t'
(aka 'unsigned long') to a string does not append to the string
[-Wstring-plus-int]
res.status = "Error retrieving block at height " + height;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
The obvious intent is achieved by using std::to_string().
- 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
This would have tried to send a second output to make the tx
look like the 2/2 ideal, but it would not fail to find one
because picking an output from preferred_inputs priority list
did not remove it from the unused tranfer/dust outputs, so
it would try to send the same output twice.
While there, I also added a check to avoid sending a second
input if it's related to the first. Better 1/2 than linking
inputs, I think.
This avoids indirectly leaking the real output to the daemon,
and is faster.
This will still happen for more complex cases, especially
when cancelling a tx and "re-rolling" it.
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
If we'd make a rct tx with just one input, we try to add
a second one to match the 2/2 ideal. This means more txes
use that template (and are thus using a larger anonymity
set), and it coalesces outputs "for free". We use the
smallest amount outputs in priority for this, so we can
"clean" the wallet at the same time.
