'outputs' option allows to specify the number of
separate outputs of smaller denomination that will
be created by sweep operation.
rebased by moneromooo
- 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
a54dbaee blockchain_blackball: add --force-chain-reaction-pass flag (moneromooo-monero)
44439c32 record blackballs as amount/offset, and add export ability (moneromooo-monero)
4bce935b blockchain_blackball: more optimizations (moneromooo-monero)
b66ba783 blockchain_blackball: do not process duplicate blockchains parts (moneromooo-monero)
639a3c01 blockchain_blackball: make it clear secondary passes are not incremental (moneromooo-monero)
eb8a51be blockchain_blackball: detect spent outputs by partial ring reuse (moneromooo-monero)
d6d276c6 blockchain_blackball: fix chain reaction phase in incremental mode (moneromooo-monero)
2b2a681b blockchain_blackball: avoid false positives for different amounts (moneromooo-monero)
80e4fef3 blockchain_blackball: set transaction looping txn to read only (moneromooo-monero)
4801d6b5 blockchain_blackball: add stats (moneromooo-monero)
846190fd blockchain_blackball: support pre-v2 databases (moneromooo-monero)
daa6cc7d blockchain_blackball: use LMDB for the cache (moneromooo-monero)
50cb370d ringdb: allow blackballing many outputs at once (moneromooo-monero)
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.
Many people are using this as a "let's see what this does" command
when something doesn't work as they thought it should, and thus
destroying info that they might still need.
This is based on how much an attacking miner stands to lose in block
rewardy by mining a private chain which double spends a payment.
This is not foolproof, since mining is based on luck, and breaks
down as the attacking miner nears 50% of the network hash rate,
and the estimation is based on a constant block reward.
8fc0cdb wallet2: lower default for subaddress lookahead when restoring with hardware (stoffu)
248310d Move parse_subaddress_lookahead() from simplewallet.cpp to util.cpp (stoffu)
46e90b7 Wallet API: add support for wallet creation from hardware device (stoffu)
8962f00 simplewallet: add optional trusted/untrusted argument to set_daemon (moneromooo-monero)
941a608 util: consider Tor/I2P addresses to be non local (moneromooo-monero)
2b3357e README: mention --untrusted-daemon (moneromooo-monero)
for privacy reasons, so an untrusted node can't easily track
wallets from IP address to IP address, etc. The granularity
is 1024 blocks, which is about a day and a half.
c77d2bfa Add the possibility to export private view key for fast scan. (cslashm)
100b7bc1 Change mutex lock model to avoid dead lock and ensure locks are always released. (cslashm)
641dfc99 Automatic height setup when creating/restoring hw device. (cslashm)
When creating/restoring wallet, if --restore-height option is not used the current estimate
height is used for starting the scan. In other words it is assume we are creating a new account.
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.
When #3303 was merged, a cyclic dependency chain was generated:
libdevice <- libcncrypto <- libringct <- libdevice
This was because libdevice needs access to a set of basic crypto operations
implemented in libringct such as scalarmultBase(), while libringct also needs
access to abstracted crypto operations implemented in libdevice such as
ecdhEncode(). To untangle this cyclic dependency chain, this patch splits libringct
into libringct_basic and libringct, where the basic crypto ops previously in
libringct are moved into libringct_basic. The cyclic dependency is now resolved
thanks to this separation:
libcncrypto <- libringct_basic <- libdevice <- libcryptonote_basic <- libringct
This eliminates the need for crypto_device.cpp and rctOps_device.cpp.
Also, many abstracted interfaces of hw::device such as encrypt_payment_id() and
get_subaddress_secret_key() were previously implemented in libcryptonote_basic
(cryptonote_format_utils.cpp) and were then called from hw::core::device_default,
which is odd because libdevice is supposed to be independent of libcryptonote_basic.
Therefore, those functions were moved to device_default.cpp.
Previously, a file containing the unencrypted Monero address was
created by default in the wallet's directory. This file might pose
as a privacy risk. The creation of this file is now opt-in and can
be enabled by providing
--create-address-file
- save the new keys file as FOO-watchonly.keys, not FOO.keys-watchonly
- catch any exception (eg, I/O errors) and error out
- print the new keys filename in simplewallet
0e7ad2e2 Wallet API: generalize 'bool testnet' to 'NetworkType nettype' (stoffu)
af773211 Stagenet (stoffu)
cc9a0bee command_line: allow args to depend on more than one args (stoffu)
55f8d917 command_line::get_arg: remove 'required' for dependent args as they're always optional (stoffu)
450306a0 command line: allow has_arg to handle arg_descriptor<bool,false,true> #3318 (stoffu)
9f9e095a Use `genesis_tx` parameter in `generate_genesis_block`. #3261 (Jean Pierre Dudey)
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.
