| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
unless --long-payment-id-support is used
|
|
5e10dee3 simplewallet: fix show_transfers colouring, and add red for failed (moneromooo-monero)
|
|
60b35c91 Add --restore-date param (Howard Chu)
|
|
|
|
Also add the type back, as it was somehow weirdly split into
two different fields, one being a union...
|
|
Estimate restore height from given date
Check date format early, error out early if invalid
|
|
|
|
When doing a first refresh on HW-token based wallet KI sync is required if money were received. Received money may indicate wallet was already used before the restore I.e., some transaction could have been already sent from the wallet. The spent UTXO would not be detected as spent which could lead to double spending errors on submitting a new transaction.
Thus if the wallet is HW-token based with the cold signing protocol and the first refresh detected received money the user is asked to perform the key image sync.
|
|
- simple device callback object added. Device can request passphrase/PIN entry via the callback or notify user some action is required
- callback is routed to wallet2, which routes the callback to i_wallet_callback so CLI or GUI wallets can support passphrase entry for HW tokens
- wallet: device open needs wallet callback first - passphrase protected device needs wallet callback so user can enter passphrase
|
|
|
|
f26ce08c wallet: add a non destructive blockchain rescan (moneromooo-monero)
|
|
|
|
|
|
* support in wallet2
* support in monero-wallet-cli
* support in monero-wallet-rpc
* support in wallet api
* support in monero-gen-trusted-multisig
* unit tests for multisig wallets creation
|
|
05edc969 simplewallet: remove obsolete transfer_original command (moneromooo-monero)
|
|
|
|
- device name is a new wallet property
- full device name is now a bit more structured so we can address particular device vendor + device path. Example: 'Ledger', 'Trezor:udp', 'Trezor:udp:127.0.0.1:21324', 'Trezor:bridge:usb01'. The part before ':' identifies HW device implementation, the optional part after ':' is device path to look for.
- new --hw-device parameter added to the wallet, can name the hardware device
- device reconnect added
|
|
|
|
The secret spend key is kept encrypted in memory, and
decrypted on the fly when needed.
Both spend and view secret keys are kept encrypted in a JSON
field in the keys file. This avoids leaving the keys in
memory due to being manipulated by the JSON I/O API.
|
|
|
|
f13c7a8 simplewallet: make sure wallet config is stored right after creation (stoffu)
|
|
a3fe1c5 simplewallet: add set_tx_key for importing tx keys from 3rd party wallets (stoffu)
|
|
|
|
|
|
|
|
|
|
3f5fb6f simplewallet: add --untrusted-daemon option (moneromooo-monero)
|
|
|
|
|
|
8ea3c4d5 simplewallet: new --use-english-language-names flag (moneromooo-monero)
|
|
On some Windows systems, displaying language names in their own
languages freezes the display.
|
|
via user setting first, then DNS TXT record, hardcoded fallback
|
|
lookahead in order to avoid
so looooong time of set-up when creating a HW based wallet.
|
|
This is so one can set rings for spent key images in case the
attackers don't merge the ring matching patch set.
|
|
|
|
If a pre-fork output is spent on both Monero and attack chain,
any post-fork output can be deduced to be a fake output, thereby
decreasing the effective ring size.
The segregate-per-fork-outputs option, on by default, allows
selecting only pre-fork outputs in this case, so that the same
ring can be used when spending it on the other side, which does
not decrease the effective ring size.
This is intended to be SET when intending to spend Monero on the
attack fork, and to be UNSET if not intending to spend Monero
on the attack fork (since it leaks the fact that the output being
spent is pre-fork).
If the user is not certain yet whether they will spend pre-fork
outputs on a key reusing fork, the key-reuse-mitigation2 option
should be SET instead.
If you use this option and intend to spend Monero on both forks,
then spend real Monero first.
|
|
This maps key images to rings, so that different forks can reuse
the rings by key image. This avoids revealing the real inputs like
would happen if two forks spent the same outputs with different
rings. This database is meant to be shared with all Monero forks
which don't bother making a new chain, putting users' privacy at
risk in the process. It is placed in a shared data directory by
default ($HOME/.shared-ringdb on UNIX like systems). You may
use --shared-ringdb-dir to override this location, and should
then do so for all Monero forks for them to share the database.
|
|
calls to wallet2
|
|
The basic approach it to delegate all sensitive data (master key, secret
ephemeral key, key derivation, ....) and related operations to the device.
As device has low memory, it does not keep itself the values
(except for view/spend keys) but once computed there are encrypted (with AES
are equivalent) and return back to monero-wallet-cli. When they need to be
manipulated by the device, they are decrypted on receive.
Moreover, using the client for storing the value in encrypted form limits
the modification in the client code. Those values are transfered from one
C-structure to another one as previously.
The code modification has been done with the wishes to be open to any
other hardware wallet. To achieve that a C++ class hw::Device has been
introduced. Two initial implementations are provided: the "default", which
remaps all calls to initial Monero code, and the "Ledger", which delegates
all calls to Ledger device.
|
|
fbc0a6dd Bugfix : Missing i18n import in simplewallet (Neozaru)
|
|
not full)
|
|
ca336c62 simplewallet: check file overwrite when exporting stuff (stoffu)
|
|
|
|
|
|
|
|
9ffa97fe Factor the monero donation address (Maxithi)
|
|
|
|
Signed-off-by: Maxithi <34792056+Maxithi@users.noreply.github.com>
|
|
5cbcf0aa wallet: support for multisig seeds (moneromooo-monero)
|
|
They are hex rather than words, because they are a lot longer
than "normal" seeds, as they have to embed a lot more information
|
|
|
|
It exports raw transactions, so they may be used by other tools,
for instance to be relayed to the network externally.
|
|
|
|
Scheme by luigi1111:
Multisig for RingCT on Monero
2 of 2
User A (coordinator):
Spendkey b,B
Viewkey a,A (shared)
User B:
Spendkey c,C
Viewkey a,A (shared)
Public Address: C+B, A
Both have their own watch only wallet via C+B, a
A will coordinate spending process (though B could easily as well, coordinator is more needed for more participants)
A and B watch for incoming outputs
B creates "half" key images for discovered output D:
I2_D = (Hs(aR)+c) * Hp(D)
B also creates 1.5 random keypairs (one scalar and 2 pubkeys; one on base G and one on base Hp(D)) for each output, storing the scalar(k) (linked to D),
and sending the pubkeys with I2_D.
A also creates "half" key images:
I1_D = (Hs(aR)+b) * Hp(D)
Then I_D = I1_D + I2_D
Having I_D allows A to check spent status of course, but more importantly allows A to actually build a transaction prefix (and thus transaction).
A builds the transaction until most of the way through MLSAG_Gen, adding the 2 pubkeys (per input) provided with I2_D
to his own generated ones where they are needed (secret row L, R).
At this point, A has a mostly completed transaction (but with an invalid/incomplete signature). A sends over the tx and includes r,
which allows B (with the recipient's address) to verify the destination and amount (by reconstructing the stealth address and decoding ecdhInfo).
B then finishes the signature by computing ss[secret_index][0] = ss[secret_index][0] + k - cc[secret_index]*c (secret indices need to be passed as well).
B can then broadcast the tx, or send it back to A for broadcasting. Once B has completed the signing (and verified the tx to be valid), he can add the full I_D
to his cache, allowing him to verify spent status as well.
NOTE:
A and B *must* present key A and B to each other with a valid signature proving they know a and b respectively.
Otherwise, trickery like the following becomes possible:
A creates viewkey a,A, spendkey b,B, and sends a,A,B to B.
B creates a fake key C = zG - B. B sends C back to A.
The combined spendkey C+B then equals zG, allowing B to spend funds at any time!
The signature fixes this, because B does not know a c corresponding to C (and thus can't produce a signature).
2 of 3
User A (coordinator)
Shared viewkey a,A
"spendkey" j,J
User B
"spendkey" k,K
User C
"spendkey" m,M
A collects K and M from B and C
B collects J and M from A and C
C collects J and K from A and B
A computes N = nG, n = Hs(jK)
A computes O = oG, o = Hs(jM)
B anc C compute P = pG, p = Hs(kM) || Hs(mK)
B and C can also compute N and O respectively if they wish to be able to coordinate
Address: N+O+P, A
The rest follows as above. The coordinator possesses 2 of 3 needed keys; he can get the other
needed part of the signature/key images from either of the other two.
Alternatively, if secure communication exists between parties:
A gives j to B
B gives k to C
C gives m to A
Address: J+K+M, A
3 of 3
Identical to 2 of 2, except the coordinator must collect the key images from both of the others.
The transaction must also be passed an additional hop: A -> B -> C (or A -> C -> B), who can then broadcast it
or send it back to A.
N-1 of N
Generally the same as 2 of 3, except participants need to be arranged in a ring to pass their keys around
(using either the secure or insecure method).
For example (ignoring viewkey so letters line up):
[4 of 5]
User: spendkey
A: a
B: b
C: c
D: d
E: e
a -> B, b -> C, c -> D, d -> E, e -> A
Order of signing does not matter, it just must reach n-1 users. A "remaining keys" list must be passed around with
the transaction so the signers know if they should use 1 or both keys.
Collecting key image parts becomes a little messy, but basically every wallet sends over both of their parts with a tag for each.
Thia way the coordinating wallet can keep track of which images have been added and which wallet they come from. Reasoning:
1. The key images must be added only once (coordinator will get key images for key a from both A and B, he must add only one to get the proper key actual key image)
2. The coordinator must keep track of which helper pubkeys came from which wallet (discussed in 2 of 2 section). The coordinator
must choose only one set to use, then include his choice in the "remaining keys" list so the other wallets know which of their keys to use.
You can generalize it further to N-2 of N or even M of N, but I'm not sure there's legitimate demand to justify the complexity. It might
also be straightforward enough to support with minimal changes from N-1 format.
You basically just give each user additional keys for each additional "-1" you desire. N-2 would be 3 keys per user, N-3 4 keys, etc.
The process is somewhat cumbersome:
To create a N/N multisig wallet:
- each participant creates a normal wallet
- each participant runs "prepare_multisig", and sends the resulting string to every other participant
- each participant runs "make_multisig N A B C D...", with N being the threshold and A B C D... being the strings received from other participants (the threshold must currently equal N)
As txes are received, participants' wallets will need to synchronize so that those new outputs may be spent:
- each participant runs "export_multisig FILENAME", and sends the FILENAME file to every other participant
- each participant runs "import_multisig A B C D...", with A B C D... being the filenames received from other participants
Then, a transaction may be initiated:
- one of the participants runs "transfer ADDRESS AMOUNT"
- this partly signed transaction will be written to the "multisig_monero_tx" file
- the initiator sends this file to another participant
- that other participant runs "sign_multisig multisig_monero_tx"
- the resulting transaction is written to the "multisig_monero_tx" file again
- if the threshold was not reached, the file must be sent to another participant, until enough have signed
- the last participant to sign runs "submit_multisig multisig_monero_tx" to relay the transaction to the Monero network
|
|
Scheme by luigi1111
|
|
|
|
|
|
|
|
- refactoring: proof generation/checking code was moved from simplewallet.cpp to wallet2.cpp
- allow an arbitrary message to be signed together with txid
- introduce two types (outbound & inbound) of tx proofs; with the same syntax, inbound is selected when <address> belongs to this wallet, outbound otherwise. see GitHub thread for more discussion
- wallet RPC: added get_tx_key, check_tx_key, get_tx_proof, check_tx_proof
- wallet API: moved WalletManagerImpl::checkPayment to Wallet::checkTxKey, added Wallet::getTxProof/checkTxProof
- get_tx_key/check_tx_key: handle additional tx keys by concatenating them into a single string
|
|
|
|
|
|
|
|
4090e8c6 simplewallet: add get/set for refresh-from-height (moneromooo-monero)
|
|
7b8d3ec6 wallet-cli: add --do-not-relay option (stoffu)
|
|
|
|
|
|
|
|
|
|
651baaec wallet: add encrypted seed functionality (moneromooo-monero)
|
|
840aed1c monero-wallet-cli: New command 'wallet_info' improved (rbrunner7)
9bdd985c monero-wallet-cli: New command 'wallet_info' (rbrunner7)
|
|
This uses luigi1111's CN_Add method.
See https://xmr.llcoins.net for details.
|
|
|
|
including expected transaction backlog at different priorities
|
|
|
|
dee41efa simplewallet: mnemonic language command-line arg (Eugene Otto)
|
|
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)
|
|
Add `--mnemonic-language` command-line arg so it's possible to generate a wallet
without interacting with the CLI.
|
|
|
|
Should help people who don't realize why they haven't seen their
monero yet.
|
|
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.
|
|
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.
|
|
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)
|
|
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.
|
|
2c468dd4 allow user I/O in millinero, micronero, nanonero, piconero (moneromooo-monero)
|
|
|
|
|
|
|
|
ce7fcbb4 Add server auth to monerod, and client auth to wallet-cli and wallet-rpc (Lee Clagett)
|
|
|
|
|
|
f97526e6 simplewallet: option to always ask password for any crytical operations (kenshi84)
|
|
|
|
|
|
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.
|
|
db56a03f Wallet2 + API: Callbacks for unconfirmed transfers (Jaquee)
|
|
|
|
|
|
c2135082 simplewallet: add a show_transfer <txid> command (moneromooo-monero)
19c4041d wallet_rpc_server: new RPC call to get a transfer by txid (moneromooo-monero)
|
|
adee1644 wallet cli: print unspent outputs with histogram (kenshi84)
|
|
38f00d07 wallet cli: viewing and editing address book (kenshi84)
|
|
|
|
|
|
tools::dns_utils; support integrated address with dns lookup
|
|
|
|
|
|
|
|
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.
|
|
|
|
bb560dd wallet: new import_outputs/export_outputs commands (moneromooo-monero)
|
|
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.
|
|
714ee99 Fix description for locked_transfer (Oyvind Kvanes)
71538f3 Rename to lockblocks and add max value (Oyvind Kvanes)
68ac060 Fix locked_transfer (Oyvind Kvanes)
7d020bd Add locked_transfer (Oyvind Kvanes)
d5f918a Revert transfer_main in simplewallet (Oyvind Kvanes)
3451963 Add motifications to test out locked_transfer (Oyvind Kvanes)
e5e6d88 Add more information to transaction in wallet (Oyvind Kvanes)
9b8a062 Make a small test change (Oyvind Kvanes)
|
|
80b4da3 wallet: wallet option to confirm transfers with no payment id (moneromooo-monero)
|
|
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'.
|
|
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.
|
|
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.
|
|
709c724 Better fix (#4) (hyc)
d2644c1 fix restore-deterministic height (luigi1111)
|
|
da1007f simplewallet: make the refresh thread into more generic idle thread (moneromooo-monero)
|
|
|
|
|
|
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.
|
|
014f3a0 Add a daemon RPC version, and make simplewallet check it (moneromooo-monero)
|
|
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.
|
|
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".
|
|
It matches the daemon, and should allow people who're suspicious
of the background refresh to know they're synced.
|
|
|
|
4b1c0d6 simplewallet: some background refresh threading fixes (moneromooo-monero)
|
|
b0850a9 wallet: add a new sweep_all command and RPC command (moneromooo-monero)
|
|
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.
|
|
For specifying the block height from which to start a restore
|
|
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.
|
|
and all other associated IPC
|
|
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.
|
|
Some of it uses hardcoded height, which will need some thinking
for next (voted upon) fork.
|
|
|
|
|
|
Blockchain hashes and key images are flushed, and blocks are
pulled anew from the daemon.
The console command is shortened to match bc_height.
This should make it a lot easier on users who are currently
told to remove this particular cache file but keep the keys
one, etc, etc.
|
|
instead of a command line setting. It makes sense that is is
a long lived setting.
|
|
^C while in manual refresh will cancel the refresh, since that's
often an annoying thing to have to wait for. Also, a manual refresh
command will interrupt any running background refresh and take
over, rather than wait for the background refresh to be done, and
look to be hanging.
|
|
The daemon will be polled every 90 seconds for new blocks.
It is enabled by default, and can be turned on/off with
set auto-refresh 1 and set auto-refresh 0 in the wallet.
|
|
Take the opportunity to add a no-coinbase case too, for even faster
sync when an address is known to never have mined to.
|
|
With backward compatibility
|
|
Height seemed to be flying all over the place on a rescan here.
Logging to a file shows the heights are actually correct, and
this is some kind of screen refresh artifact. Flush after \r
and update less often to reduce this effect a lot.
|
|
It's a user friendly display of incoming and outgoing transfers,
listed by height, within an optional height range.
|
|
The default default mixin is 4. It can now be changed per wallet.
|
|
It allows one to check the amount of monero sent to a particular
address in a particular transaction, given that transaction's tx key
|
|
It allows enabling the rescan_spent command only for trusted
daemon
|
|
To enable storing tx keys in the (now encrypted) wallet cache.
|
|
They are also stored in the cache file, to be retrieved using
a new get_tx_key command.
|
|
This obsoletes the need for a lengthy blockchain rescan when
a transaction doesn't end up in the chain after being accepted
by the daemon, or any other reason why the wallet's idea of
spent and unspent outputs gets out of sync from the blockchain's.
|
|
It should avoid a lot of the issues sending more than half the
wallet's contents due to change.
Actual output selection is still random. Changing this would
improve the matching of transaction amounts to output sizes,
but may have non obvious effects on blockchain analysis.
Mapped to the new transfer_new command in simplewallet, and
transfer uses the existing algorithm.
To use in RPC, add "new_algorithm: true" in the transfer_split
JSON command. It is not used in the transfer command.
|
|
|
|
This can be useful if you want to be given a veto over the tx fee,
or if you want to see what a tx fee would be without actually sending.
|
|
The system is mostly the Qt system, but we don't use Qt to avoid
the dependencies.
See README.i18n for details.
|
|
The needed information is supplied via a triple:
--generate-from-view-key address:viewkey:filename
|
|
|
|
The new save_watch_only saves a copy of the keys file without the
spend key. It can then be given away to be used as a normal keys
file, but with no spend ability.
|
|
Sends all the dust to your own wallet. May fail (if the fee required
is more than the dust total). May end up paying most of the dust in fees.
Unlocked dust total is now also displayed in "balance".
|
|
|
|
|
|
Add simple_wallet::set_variable method to provide top-level "set"
command and support "set seed language" command.
|
|
|
|
|
|
|
|
|
|
Source: cryptonotefoundation
|
|
|
|
not yet password protected
|
|
|
|
wallet RPC now uses wallet2::create_transactions and wallet2::commit_tx instead
of wallet2::transfer. This made it possible to add the RPC call /transfer_split, which
will split transactions automatically if they are too large. The old call to
/transfer will return an error stating to use /transfer_split if multiple
transactions are needed to fulfill the request.
|
|
|
|
|
|
|
|
--generate-new-wallet and --wallet-file are now properly mutually-exclusive.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
