This fixes rapid reconnections failing as the peer hasn't yet
worked out the other side is gone, and will reject "duplicate"
connections until a timeout.
912ff6abe simplewallet: plug a timing leak (moneromooo-monero)
cc2fc0bc3 epee: allow a random component in once_a_time timeouts (moneromooo-monero)
c0f504787 wallet: reuse cached height when set after refresh (moneromooo-monero)
f98d9673e wallet2: fix is_synced checking target height, not height (moneromooo-monero)
98cdc8492 wallet: fix another facet of "did I get some monero" information leak (moneromooo-monero)
69b8aa5a2 wallet2: do not send an unnecessary last getblocks.bin call on refresh (moneromooo-monero)
2ca057402 wallet2: do not repeatedly ask for pool txes sent to us (moneromooo-monero)
Make sure it links to our libtinfo from our ncurses build.
Hardcode some basic terminal descriptions into our libtinfo.
Re-enable $HOME/.terminfo support to allow user customization.
Use unlikely terminfo-dir, to prevent accidentally using
differently-configured system databases.
As reported by Tramèr et al, timing of refresh requests can be used
to see whether a password was requested (and thus at least one output
received) since this will induce a delay in subsequent calls.
To avoid this, we schedule calls at a given time instead of sleeping
for a set time (which would make delays additive).
To further avoid a scheduled call being during the time in which a
password is prompted, the actual scheduled time is now randomized.
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).
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.