The default behavior for hex string parsing would allow the
last digit to be made from a single hexadecimal character,
which is correct, but we typically do not want that as it
gets confusing and easy to not spot wrong input size.
The tests for rejection of unmixable outputs in v2 are commented out,
as there are no unmixable outputs created anymore. This should be
restored at some point.
It sets the max number of threads to use for a parallel job.
This is different that the number of total threads, since monero
binaries typically start a lot of them.
It allows a simple get_transfers (with default 0 min_height and
max_height) to return all transactions, instead of the unexpected
set of txes in block 0, which is probably none at all.
We want to lock operations which access the blockchain in
wallet2. We also want the background refresh to happen again
when we cancel a foreground refresh. Wrap the locking setup
in a macro so it doesn't get copy/pasted/mangled, and use
a scope exit trick to ensure it's always properly restored.
This sends all outputs in a wallet to a given address, alleviating
the difficulty people have had trying to send all monero but
being left with some small amount left.
When reaching the tail emission phase, the amount of coins will
eventually go over MONEY_SUPPLY, overflowing 64 bits. There was
a check added to blockchain_storage, but this was not ported to
the blockchain DB version.
Reported by smooth.
When the send queue limit is reached, it is likely to not drain
any time soon. If we call close on the connection, it will stay
alive, waiting for the queue to drain before actually closing,
and will hit that check again and again. Since the queue size
limit is the reason we're closing in the first place, we call
shutdown directly.
If we reach the send queue size limit, we need to release the lock,
or we will deadlock and it will never drain.
If we reach that limit, it's likely there's another problem in the
first place though, so it will probably not drain in practice either,
unless some kind of transient network timeout.
^C when in RPC mode would not save the wallet while it was still
refreshing after starting up.
Also, save the wallet out of the signal handler. We don't want
to call complex stuff in a signal handler.
This can generate non decomposed outputs for very large block
rewards (or not so large ones if a miner decides to not quantize
the block rewards). Out of an abundance of caution, we refuse
to generate those. They are still accepted by the consensus code,
however.
This allows appropriate action to be taken, like displaying
the reason to the user.
Do just that in simplewallet, which should help a lot in
determining why users fail to send.
Also make it so a tx which is accepted but not relayed is
seen as a success rather than a failure.
With the change in mixin rules for v2, the "annoying" outputs are
slightly changed. There is high correlation between dust and
unmixable, but no equivalence.
This is a list of existing output amounts along with the number
of outputs of that amount in the blockchain.
The daemon command takes:
- no parameters: all outputs with at least 3 instances
- one parameter: all outputs with at least that many instances
- two parameters: all outputs within that many instances
The default starts at 3 to avoid massive spamming of all dust
outputs in the blockchain, and is the current minimum mixin
requirement.
An optional vector of amounts may be passed, to request
histogram only for those outputs.
This was meant to go in v2, but the miner tx slipped through
the cracks as it doesn't go through the main tx verification
since it doesn't get added to the pool.
It takes a filename containing JSON data to generate a wallet.
The following fields are valid:
version: integer, should be 1
filename: string, path/filename for the newly created wallet
scan_from_height: 64 bit unsigned integer, optional
password: string, optional
viewkey: string, hex representation
spendkey: string, hex representation
seed: string, optional, list of words separated by spaces
Either seed or private keys should be given. If using private
keys, the spend key may be omitted (the wallet will not be
able to spend, but will see incoming transactions).
If scan_from_height is given, blocks below this height will not
be checked for transactions as an optimization.
It would try to join the auto refresh thread, which would
only happen after it was done, which would take a long time
when doing so on a newly created wallet.
After the fork, normal transfer functions called via RPC
use the minimum mixin 2 if 0 or 1 is requested. While the
incoming transaction may be valid (eg, it has an unmixable
and at most a mixable input), it is a simple way to make
sure RPC users can't get a seemingly random accept/reject
behavior if they don't update their requested mixin.
moneromooo-monero