0349347e ringdb: use a different iv for key and data in rings table (moneromooo-monero)
7b882087 simplewallet: reword mixin in user message in terms of ring size (moneromooo-monero)
f507a43a wallet2: do not remove known rings when a tx fails (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)
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>
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.
If more than one thread wants to make sure of the spend secret key,
then we decrypt on the first caller and reencrypt on the last caller,
otherwise we could use an invalid secret key.
If the hashes received would move the current blockchain past the
stop point, the short history would not be updated, since we do
not expect another loop, but the daemon might return earlier hashes,
causing the end index to not be enough to reach the threshold and
this require another loop, which will download the same hashes and
cause an infinite loop.
Refreshing sets cached height, which is otherwise got by calling
get_info. Since get_info is called upon needing to display a prompt
after a command has finished, it can be used to determine how much
time a given command took to run if the cache timeout lapses while
the command runs. Refreshing caches the height as a side effect, so
get_info will never be called as a result of displaying a prompt
after refreshing (and potentially leaking how much time it took to
process a set of transactions, therefore leaking whether we got
some monero in them).
xiphon