81c5943 Remove temporary std::string creation in some hex->bin calls (vtnerd)
5fcc23a Move hex->bin conversion to monero copyright files and with less includes (vtnerd)
3387f0e Reduce template bloat in hex->bin for ZMQ json (vtnerd)
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)
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>
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.
Target height would be appropriate for the daemon, which syncs
off other daemons, but the wallet syncs off the daemon it's
connected to, and its target is the daemon's current height.
We get new pool txes before processing any tx, pool or not.
This ensures that if we're asked for a password, this does not
cause a measurable delay in the txpool query after the last
block query.
The "everything refreshed" state was detected when a refresh call did
not return any new blocks. This can be detected without that extra
"empty" call by comparing the claimed node height to the height of
the last block retrieved. Doing this avoids that last call, saves
some bandwidth, and makes the common refresh case use only one call
rather than two.
As a side effect, it prevents an information leak reported by
Tramèr et al: if the wallet retrieves a set of blocks which includes
an output sent to the refreshing wallet, the wallet will prompt the
user for the password to decode the amount and calculate the key
image for the new output, and this will delay subsequent calls to
getblocks.bin, allowing a passive adversary to note the delay and
deduce when the wallet receives at least one output.
This can still happen if the wallet downloads more than 1000 blocks,
since this will be split in several calls, but then the most the
adversary can tell is which 1000 block section the user received
some monero (the adversary can estimate the heights of the blocks
by calculating how many "large" transfers are done, which will be
sections of blocks, the last of which will usually be below 1000,
but the size of the data should allow the actual number of blocks
sent to be determined fairly accurately).
This timing trick still be used via the subsequent scan for incoming
txes in the txpool, which will be fixed later.
This lets a passive attacker with access to the network link
between node and wallet perform traffic analysis to deduce
when an idle wallet receives a transaction.
Reported by Tramèr et al.
xiphon
luigi1111
moneromooo-monero
Sarang Noether
Alexander Blair
Lee Clagett
Tadeas Moravec