| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
including expected transaction backlog at different priorities
|
|
|
|
Suspend readline when refreshing
|
|
|
|
Add `--mnemonic-language` command-line arg so it's possible to generate a wallet
without interacting with the CLI.
|
|
|
|
|
|
|
|
It's annoying and pointless (especially as it's the only thing
where the user is asked twice)
|
|
Previously, the wallet just asked for "Spend key" and "View key" but
now it specifies that these should be the secret versions of these
keys.
|
|
Integrated addresses are shown when an encrypted payment id is used
|
|
Should help people who don't realize why they haven't seen their
monero yet.
|
|
also show it in simplewallet's show_transfer
|
|
|
|
Asks user for all the data required to merge secret keys from multisig wallets into one master wallet, which then gets full control of the multisig wallet. The resulting wallet will be the same as any other regular wallet.
|
|
Library code should definitely not ask for console input unless
it's clearly an input function. Delegating the user interaction
part to the caller means it can now be used by a GUI, or have a
decision algorithm better adapted to a particular caller.
|
|
"Payment successfully sent" can be misleading if the TX isn't confirmed and drops from TX-pool.
|
|
- Add missing unbind key
- Fix colored messages
- Add command completion
- Preserve last command input
- Fix cursor position issues
- Fix trailing whitespace in commands
- Synchronize set_prompt
|
|
This ensures the chain and related structures can't change
while we're using them
|
|
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.
|
|
monero-wallet-cli commands which have multine output sometimes causes
issues with the readline support. This patch fixes show_transfers,
payments and incoming_transfers.
|
|
|
|
|
|
|
|
not the actual tx secret key
|
|
This is trivial, but often requested, and possibly hard to do
in Windows. That makes it more user friendly.
|
|
Add fail-fast paths that reduce frustration around the misuse of
--wallet-file combined with --restore-deterministic-wallet. Flow now
gives more descriptive errors and avoids having users type in their
whole seed before the failure condition is noticed.
|
|
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.
|
|
fix a cmakelist
|
|
|
|
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)
|
|
People are likely to enter it in three lines as it is how it
is displayed at creation time
|
|
|
|
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.
|
|
These can create transactions, even though they cannot sign them.
|
|
Allows priority argument default/unimportant/normal/elevated/priority to
be used per transaction in CLI wallet's transfer command. Resolves #1913.
|
|
|
|
|
|
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.
|
|
|
|
Those can create unsigned transactions
|
|
|
|
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).
|
|
Also tweak wallet2 password code to verify password without
saying it's a new wallet, because it's assuming things.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remove empty static function which was refactored, as well as
leftover exception testing 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
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
#1498
|
|
Not 100$ sure this is the right fix, nor whether address book entries from URL should be stored as addresses or URLs (or both with a check for change on payment).
|
|
|
|
|
|
|
|
tools::dns_utils; support integrated address with dns lookup
|
|
|
|
The serialization format changed, and while there is code
to load the older serialization format, an older monerod
will not be able to load a file saved by a new monerod,
even though both share the same version. This is not good,
and we prefer a version bump.
|
|
|
|
|
|
reported by nioc
|
|
Resolves -Wreturn-type
References #1447 #1451
|
|
Closes #1447
References #1451
|
|
|
|
|
|
Possibly other pedantry. Pedants are people too.
|
|
|
|
Daemon RPC version is now composed of a major and minor number,
so that incompatible changes bump the major version, while
compatible changes can still bump the minor version without
causing clients to unnecessarily complain.
|
|
|
|
|
|
When passing around unsigned and signed transactions, outputs
and key images are passed along (outputs are passed along unsigned
transactions from the hot wallet to the cold wallet, key images
are passed along with signed transations from the cold wallet
to the hot wallet), to allow more user friendly syncing between
hot and cold wallets.
|
|
Prints pubkey and key image as well
|
|
Also catch change to multiple addresses, this is unexpected
|
|
|
|
|
|
|
|
|
|
This key is available to both cold and hot wallet.
Authenticated encryption will guard against interception and/or
modification of the file.
|
|
m_amount_out was sometimes getting initialized with the sum of
an transaction's outputs, and sometimes with the sum of outputs
that were not change. This caused confusion and bugs. We now
always set it to the sum of outputs. This reverts an earlier
fix for bad amounts as this used the other semantics. The wallet
data should be converted automatically in a percentage of cases
that I'm hesitant to estimate. In any case, restoring from seed
or keys or rebuilding the cache will get it right.
|
|
The intended use is to export outputs from a hot wallet, which
can scan incoming transfers from the network, and import them
in the cold wallet, which can't. The cold wallet can then compute
key images for those outputs, which can then be exported with
export_key_images, etc.
|
|
This is on the potentially compromised wallet, but still guards
against stupid mistakes.
|
|
This will happen when sending to another address, after removing
the fee.
|
|
Not as trustworthy as this is in the view wallet, the one
that's considered compromised.
|
|
Re-creating the transaction on the cold wallet was not splitting
the change, causing the transaction to be rejected by the network.
This worked on testnet since amounts do not have to be split.
Also add selected_transfers, which can now be saved since they're
size_t rather than iterators. This allows the view wallet to
properly set the sent outputs as spent and update balance.
Bump transfer file version numbers to match.
|
|
Factor locked_transfer into transfer_main, which brings various
improvements for free (multiple addresses, proper detection of
multiple payment ids, obeying the prompt settings).
Also fix a few things, such as using uint64_t instead of int
for block heights, actually checking whether getting blockchain
height succeeded, etc.
|
|
|
|
RingCT outputs will be 0 in the vin, so we need to get the actual
amount from elsewhere.
|
|
|
|
|
|
|
|
|
|
|
|
Changed the wording from "from 0 to maximum available" to "from 2 to maximum available".
May I also suggest putting in a number rather than "maximum available" and also clarifying that mixin = 0 is still allowed if the user has unmixable outputs (dust), which he wants to "undust" using sweep_unmixable (comment from dEBRUYNE-1 ).
|
|
set confirm-missing-payment-id 0|1
Defaults to true.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This change adds the ability to create a new unsigned transaction
from a watch only wallet, and save it to a file. This file can
then be moved to another computer/VM where a cold wallet may load
it, sign it, and save it. That cold wallet does not need to have
a blockchain nor daemon. The signed transaction file can then be
moved back to the watch only wallet, which can load it and send
it to the daemon.
Two new simplewallet commands to use it:
sign_transfer (on the cold wallet)
submit_transfer (on the watch only wallet)
The transfer command used on a watch only wallet now writes an
unsigned transaction set in a file called 'unsigned_monero_tx'
instead of submitting the tx to the daemon as a normal wallet does.
The signed tx file is called 'signed_monero_tx'.
|
|
|
|
|
|
|
|
|
|
Keep the immediate direct deps at the library that depends on them,
declare deps as PUBLIC so that targets that link against that library
get the library's deps as transitive deps.
Break dep cycle between blockchain_db <-> crytonote_core.
No code refactoring, just hide cycle from cmake so that
it doesn't complain (cycles are allowed only between
static libs, not shared libs).
This is in preparation for supproting BUILD_SHARED_LIBS cmake
built-in option for building internal libs as shared.
|
|
They're confusing, as people think it reports their balance.
|
|
Change was not taken into consideration
|
|
We keep 1, 2, 3 multipliers till the fee decrase from 0.01/kB
to 0.002/kB, where we start using 1, 20, 166 multipliers.
This ensures the higher multiplier will compensate for the
block reward penalty when pushing past 100% of the past median.
The fee-multiplier wallet setting is now rename to priority,
since it keeps its [0..3] range, but maps to different multiplier
values.
|
|
This adds [snap](https://snapcraft.io) packaging to the project. See the
link for more information on snaps. Snap packages install on all Linux
distributions. On Ubuntu, snap confinement with apparmor and seccomp
provide an additional layer of security.
This snap sets up monerod as a systemd service, which should start
immediately on install. To access the wallet CLI, simply run `monero`
(/snap/bin/monero). I think it's a really quick & easy way to get
started with monero.
I've made some opinionated decisions in the packaging just to kick this
off, but I'm happy to iterate on this stuff.
|
|
|
|
|
|
This ensures it's hard to mix files up
|
|
Saves on space, and on some pointless hex conversions
|
|
The compiler can't always work out the _found booleans are
set iff the value is initialized.
|
|
This allows the key to be not the same for two outputs sent to
the same address (eg, if you pay yourself, and also get change
back). Also remove the key amounts lists and return parameters
since we don't actually generate random ones, so we don't need
to save them as we can recalculate them when needed if we have
the correct keys.
|
|
Saves some substantial space.
Also avoid calculating tx hashes we don't need.
|
|
Print number of confirmations if the tx is in the blockchain,
or a warning if it's in the pool.
|
|
Scheme design from luigi1114.
|
|
|
|
The "transfer" simplewallet command is renamed to "transfer_original".
"transfer_new" is renamed "transfer", "transfer_rct" is removed,
and the new "transfer" now selects rct or non rct transactions
based on the current block height.
|
|
It is not yet constrained to a fork, so don't use on the real network
or you'll be orphaned or rejected.
|
|
|
|
A suspected bug in pthread/kernel, though might be that
I messed something up too...
This might rope in more platforms though.
|
|
|
|
This plugs a privacy leak from the wallet to the daemon,
as the daemon could previously see what input is included
as a transaction input, which the daemon hadn't previously
supplied. Now, the wallet requests a particular set of
outputs, including the real one.
This can result in transactions that can't be accepted if
the wallet happens to select too many outputs with non standard
unlock times. The daemon could know this and select another
output, but the wallet is blind to it. It's currently very
unlikely since I don't think anything uses non default
unlock times. The wallet requests more outputs than necessary
so it can use spares if any of the returns outputs are still
locked. If there are not enough spares to reach the desired
mixin, the transaction will fail.
|
|
|
|
Simplewallet improperly skipped the restore from height code if
restoring a deterministic wallet AND not specifying a wallet file in the
command line. The other generate options require a wallet file as an
argument, which prevents "ask_wallet_create_if_needed()" from being
called, which in turn causes "m_generate_new" to remain unset.
Specifying a wallet file at launch with --restore-deterministic emulated
this behavior.
|
|
|
|
Squashed commit of the following:
commit 9af9e4223b58bbb65a3519af2c2bfc273cbd23d6
fixed some formatting
commit c7920e1cf88ff46eb9294101344d9a567f22e2da
Merge: 97eb28b 1da1c68
fix#864 fix using boolean
commit 97eb28ba5dd49ddde8c8785f39b24d955e5de31c
Fix #864 boolean value used to verify on new wallet
commit 1da1c68bd3a9a373c70482b6e6e95251096149f1
fix #864 changed to boolean to prompt for verify
commit 5bee96652434762d2c91ce31a1b1c9f169446ddc
fix 864; made variable names easier for understanding branching.
commit 45715960d30293f781b2ff9e5e647c2ec893f4a3
fix #864; allow password to be entered twice for new wallets for verification.
fix #864 password entry verification; ammended boolean
fix #864 ; default constructor for password_container should set verify=true
|
|
They are used to export a signed set of key images from a wallet
with a private spend key, so an auditor with the matching view key
may see which of those are spent, and which are not.
|
|
|
|
Shown in show_transfers simplewallet command, and get_transfers
RPC command, if req.pool is true.
|
|
Background refresh is confusing to users at startup.
|
|
Signing is done using the spend key, since the view key may
be shared. This could be extended later, to let the user choose
which key (even a per tx key).
simplewallet's sign/verify API uses a file. The RPC uses a
string (simplewallet can't easily do strings since commands
receive a tokenized set of arguments).
|
|
If the version is different, simplewallet will refuse to use that
daemon, unless --allow-mismatched-daemon-version is used.
|
|
|
|
It should be less confusing for people who're used to the foreground
refresh from earlier versions.
|
|
Fee can now be multiplied by 2 or 3, if users want to give
priority to their transactions. There are only three levels
to avoid too much fingerprinting. Default is 1 (minimum fee).
The default multiplier can be set by "set fee-multiplier X".
|
|
gmtime_r is not available in Windows, use gmtime_s instead. Also change shorthand codes (also not working in Windows).
|
|
It matches the daemon, and should allow people who're suspicious
of the background refresh to know they're synced.
|
|
|
|
Do it before the generate() call so the value actually gets stored.
|
|
|
|
Don't prompt for restore-height on generate-new-wallet
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
modified: src/wallet/wallet2.cpp
modified: src/wallet/wallet2.h
Update to fix unconfirmed balance and give a slightly more verbose and informative confirmation message for transfers
|
|
For specifying the block height from which to start a restore
|
|
Use the current blockchain height as the refresh_from_block_height.
|
|
^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.
|
|
|
|
|
|
When present, it can be used to validate the keys, as well
as deduce the spend key, if it is absent (watch wallet).
|
|
This now requests the set of outputs that can be mixed first,
to avoid trying non dust but unmixable outputs, which we know
will fail.
|
|
|
|
|
|
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.
|
|
|
|
This will be slower, though more private.
New trusted_daemon parameter to the matching RPC call, false by default.
|
|
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.
|
|
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.
|
|
Ain't nobody got time for link/cmake skullduggery.
This reverts commit fff238ec94ac6d45fc18c315d7bc590ddfaad63d.
|
|
|
|
Useful for debugging users' logs
|
|
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.
|
|
Because obviously it doesn't work as other POSIX platforms.
Reported and tested by luigi1111.
|
|
and all other associated IPC
|
|
instead of supplying them on the command line. It's more
unwieldy, but better protects against information leaks.
|
|
It is similar in use to --restore-from-view-key, but also expects
a spend private key.
Requested by luigi1112, and useful to restore MyMonero wallets.
|
|
This avoids the need to define that variable in every program
which uses epee.
|
|
|
