Transactions in the txpool are marked when another transaction
is seen double spending one or more of its inputs.
This is then exposed wherever appropriate.
Note that being marked with this "double spend seen" flag does
NOT mean this transaction IS a double spend and will never be
mined: it just means that the network has seen at least another
transaction spending at least one of the same inputs, so care
should be taken to wait for a few confirmations before acting
upon that transaction (ie, mostly of use for merchants wanting
to accept unconfirmed transactions).
They are actually wrong if the wallet is setup in a different
denomination, and it's incursion of extrinsic lingo where monero
fits perfectly in the first place.
792ba4f0 Log categories can now be added to and removed from (moneromooo-monero)
48f92eb6 easylogging++: add categories getter (moneromooo-monero)
f35afe62 epee: factor log level/categories setting (moneromooo-monero)
0aaaca29 tx_pool: set the "invalid input" bit when check_tx_inputs fails (moneromooo-monero)
9236823b simplewallet: print tx rejection reason where it was missing (moneromooo-monero)
3dee3301 core_rpc_server: print tx rejection reason at L0 too (moneromooo-monero)
e499ff33 simplewallet: factor out message_writer (moneromooo-monero)
7ed5ab47 scoped_message_writer: pause readline to match simplewallet (moneromooo-monero)
359517c7 wallet_rpc_server: fix possible privacy leak in on_import_key_images() (Jaquee)
20495b27 simplewallet: fix possible privacy leak in import_key_images() (Jaquee)
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)
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.
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).
7a44f38a Add support for the wallet to refresh pruned blocks (moneromooo-monero)
da18898f ringct: do not require range proof in decodeRct/decodeRctSimple (moneromooo-monero)
b49c6ab4 rpc: add a default category for daemon rpc (moneromooo-monero)
f113b92b core: add functions to serialize base tx info (moneromooo-monero)
6fd4b827 node_rpc_proxy: allow caching daemon RPC version (moneromooo-monero)
b5c74e40 wallet: invalidate node proxy cache when reconnecting (moneromooo-monero)
c02e1cb9 Updates to epee HTTP client 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 (Lee Clagett)
- 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
