22d30866 simplewallet: add missing inactivity-lock-timeout to set help blurb (moneromooo-monero)
9f57f0df simplewallet: do not mention inactivity if a lock was manual (moneromooo-monero)
b90c4bc3 rpc: error out from get_info if the proxied call errors out (moneromooo-monero)
fa16df99 make_test_signature: exit nicely on top level exception (moneromooo-monero)
054b2621 node_rpc_proxy: init some new rpc payment fields in invalidate (moneromooo-monero)
d0faae2a rpc: init a few missing client_info members (moneromooo-monero)
d56a483a rpc: do not propagate exceptions out of a dtor (moneromooo-monero)
3c849188 rpc: always set the update field in update on sucess (moneromooo-monero)
Nodes remember which connections have been sent which peer addresses
and won't send it again. This causes more addresses to be sent as
the connection lifetime grows, since there is no duplication anymore,
which increases the diffusion speed of peer addresses. The whole
white list is now considered for sending, not just the most recent
seen peers. This further hardens against topology discovery, though
it will more readily send peers that have been last seen earlier
than it otherwise would. While this does save a fair amount of net
bandwidth, it makes heavy use of std::set lookups, which does bring
network_address::less up the profile, though not too aggressively.
8231c7cd rpc: fix bootstrap RPC payment RPC being made in raw JSON, not JSON RPC (moneromooo-monero)
81c26589 rpc: don't auto fail RPC needing payment in bootstrap mode (moneromooo-monero)
The backward compatibility code was always setting it to 1
in modern wallets since store_tx_keys was not present and thus
assumed to be 1 by default.
Reported by SeventhAlpaca
Adding a new `amounts` field ot the output of `get_transfers` RPC
method. This field specifies individual payments made to a single
subaddress in a single transaction, e.g., made by this command:
transfer <addr1> <amount1> <addr1> <amount2>
The added condition "hshd.current_height >= target" guards against
reporting "synchronized" too early in the special situation that the
very first peer sending us data is synced to a lower height than
ourselves.
This is technically a record encrypted in two pieces,
so the iv needs to be different.
Some backward compatibility is added to read data written
by existing code, but new data is written with the new code.
