Resetting the timer after shutdown was initiated would keep
a reference to the object inside ASIO, which would keep the
connection alive until the timer timed out
Such a template would yield an invalid block, though would require
an attacker to have mined a long blockchain with drifting times
(assuming the miner's clock is roughly correct)
Fixed by crCr62U0
9f68669 blockchain_blackball: add --historical-stat which prints historical stats of spent ratio (stoffu)
2425f27blockchain_blackball: use is_output_spent instead of ringdb.blackballed for spentness test (stoffu)
50813c1 ringdb: fix bug in blackballing (stoffu)
d046ca1 difficulty: fix check_hash on big endian (moneromooo-monero)
bdda084 epee: fix local/loopback checks on big endian (moneromooo-monero)
32c3834 storages: fix writing varints on big endian (moneromooo-monero)
516f7b9 storages: fix 'portable' storage on big endian (moneromooo-monero)
0e2fda5 unit_tests: fix levin unit test on big endian (moneromooo-monero)
4672b5c db_lmdb: print percentages as percentages, not ratios (moneromooo-monero)
54fd97a slow-hash: fix CNv2+ on big endian (moneromooo-monero)
c1fa4a7 boost: fix little/big endian compatibility (moneromooo-monero)
bc1144e Fix IP address serialization on big endian (moneromooo-monero)
The problem actually exists in two parts:
1. When sending chunks over a connection, if the queue size is
greater than N, the seed is predictable across every monero node.
>"If rand() is used before any calls to srand(), rand() behaves as if
it was seeded with srand(1). Each time rand() is seeded with the same seed, it
must produce the same sequence of values."
2. The CID speaks for itself: "'rand' should not be used for security-related
applications, because linear congruential algorithms are too easy to break."
*But* this is an area of contention.
One could argue that a CSPRNG is warranted in order to fully mitigate any
potential timing attacks based on crafting chunk responses. Others could argue
that the existing LCG, or even an MTG, would suffice (if properly seeded). As a
compromise, I've used an MTG with a full bit space. This should give a healthy
balance of security and speed without relying on the existing crypto library
(which I'm told might break on some systems since epee is not (shouldn't be)
dependent upon the existing crypto library).
The issue is triggered by the captured `this` in RPC server, which
passes reference to throwable `core_rpc_server`:
`core_rpc_server.cpp:164: m_bootstrap_daemon.reset(new bootstrap_daemon([this]{ return get_random_public_node(); }));`
The solution is to simply remove noexcept from the remaining `bootstrap_daemon`
constructors because noexcept is false in this context.
>"An exception of type "boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::asio::invalid_service_owner>>" is thrown but the throw list "noexcept" doesn't allow it to be thrown. This will cause a call to unexpected() which usually calls terminate()."
One considers the blockchain, while the other considers the
blockchain and some recent actions, such as a recently created
transaction which spend some outputs, but isn't yet mined.
Typically, the "balance" command wants the latter, to reflect
the recent action, but things like proving ownership wants
the former.
This fixes a crash in get_reserve_proof, where a preliminary
check and the main code used two concepts of "balance".
When no little/big endian flag is given to the writer, it stores
data in host endianness. When loading, if no flag is set, it also
assumes host endianness. This works as long as the loading and
writing are done on machines with the same endianness.
We change this to default to little endian when saving. This will
cause the loader to see the little endian flag, and swap endianness
when loading on a big endian machine. Similarly, writing on a big
endian machine will swap on save, and a little endian machine will
load little endian data.
