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.
3b599d2b wallet2: get current height from the daemon on creation (moneromooo-monero)
d3bb72ff wallet2: fix infinite loop on future refresh height (moneromooo-monero)
32754784 wallet: fix refresh_from_height setting on new wallet (moneromooo-monero)
76043b17 monero-wallet-cli: hang on exit in readline code (#2117) (moneromooo-monero)
a73a42a6 monero-wallet-cli: hang on exit in readline code (#2117) (moneromooo-monero)
be9d4f04 Fix multiline wallet cli output with readline (Jethro Grassie)
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.
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.
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)
0ee018b4 wallet2: do not go over the target tx size if many destinations (moneromooo-monero)
9ae566d0 simplewallet: fix cold signing of split transactions (moneromooo-monero)
aae14a10 simplewallet: allow setting confirm-missing-payment-id in watch wallets (moneromooo-monero)
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.
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.
