79beed2 tests: fix various tests by using parameters better suited to monero (moneromooo-monero)
d0a8362 tests: fix some double spending tests (moneromooo-monero)
2358d0d tests: use 255 as a "too high" block version (moneromooo-monero)
f33a88c blockchain: fix a few block addition bugs (moneromooo-monero)
a9ff11c blockchain: fix an off by one error in unlocked time check (moneromooo-monero)
f294be3 blockchain: reinstate double spending checks in check_tx_inputs (moneromooo-monero)
737b6d6 blockchain: make some flag twiddling code closer to the original (moneromooo-monero)
81cb0fc blockchain: fix bitflipping test with quantized block rewards (moneromooo-monero)
22ddf09 blockchain: add missing m_tx_pool.on_blockchain_dec (moneromooo-monero)
d837c0c blockchain: fix switch to alternative blockchain for more than one block (moneromooo-monero)
5cec076 blockchain: add a missing validity check to rollback_blockchain_switching (moneromooo-monero)
3cabdb5 core: catch exceptions from get_output_key (moneromooo-monero)
5eef645 db: throw when given a non txout_to_key output to add (moneromooo-monero)
Some tests assume the first output in a transaction goes to the recipient.
However, it can be the change. When it is, the recipient's keys will not
recognize this output. To fix this, we send all we have, to ensure there
is no change, and the first output goes to the recipient.
I'm not sure why this worked with Cryptonote. The tests sent 17 coins,
which seems way smaller than the first Bytecoin block reward, so there
would have been change too. Maybe outputs were not shuffled originally.
If the block reward was too high, the verification failed flag
was set, but the function continued. The code which was supposed
to trap this flag and return failure failed to trap it, and,
while the block was not added to the chain, the function would
return success.
The reason for avoiding returning when the block reward problem
was detected was to be able to return any transactions to the
pool if needed. This is now mooted by moving the transaction
return code to a separate function, which is now called at all
appropriate points, making the logic much simpler, and hopefully
correct now.
We also move the hard fork version check after the prev_id check,
as block which does not go on the top of the chain might not
have the expected version there, without being invalid just for
this reason.
Last, we trap the case where a block fails to be added due to
using already spent key images, to set the verification failed
flag.
This fixes some double spending tests.
This may or may not be unneeded in normal (non test) circumstances,
to be determined later. Keeping these for now may be slower, but safer.
Block reward may now be less than the full amount allowed.
This was breaking the bitflipping test.
We now keep track of whether a block which was accepted by the core
has a lower than allowed block reward, and allow this in the test.
The check was explicit in the original version, so it seems
safer to make it explicit here, especially as it is now done
implicitely in a different place, away from the original check.
ffcf6bd BlockchainLMDB: When removing, find amount output index fast by starting at end (warptangent)
f11def0 BlockchainLMDB: Remove tx outputs in reverse order (warptangent)
Data should be removed in the reverse order it was added. Not doing so
breaks assumptions and can cause problems in other DB implementations.
This matches the order of tx removal in
blockchain_storage::purge_block_data_from_blockchain.
This improves blockchain reorganization time by allowing one of the more
expensive DB lookups when popping a block to not have to seek through a
long dup list in the "output_amounts" subdb. This is most noticeable for
HDDs.
As before, the dup list is still walked if necessary (but in reverse),
and the global output index still confirmed to be the one looked for.
But under proper use, the result will be found at the end of the dup
list, so we start there.
Removing an amount output index is always done in the context of popping
a block, so the global output index being looked for should be the last
one in that amount key's dup list. Even if the txs themselves aren't
removed in reverse order (supposed to be according to original
implementation), the specified amount output index will still be near
the end, because the txs are in the same block.
TEST:
Pop blocks with blockchain_import.
Blocks should be successfully removed with no errors shown.
bitmonerod should be able to start syncing from the reduced blockchain
height.
Since connections from the ::connect method are now kept in
a deque to be able to cancel them on exit, this leaks both
memory and a file descriptor. Here, we clean those up after
30 seconds, to avoid this. 30 seconds is higher then the
5 second timeout used in the async code, so this should be
safe. However, this is an assumption which would break if
that async code was to start relying on longer timeouts.
When the boost ioservice is stopped, pending work notifications
will not happen. This includes deadline timers, which would
otherwise time out the now cancelled I/O operations. When this
happens just after starting a new connect operation, this can
leave that operations in a state where it won't receive either
the completion notification nor a timeout, causing a hang.
This is fixed by keeping a list of connections corresponding
to the connect operations, and cancelling them before stopping
the boost ioservice.
Note that the list of these connections can grow unbounded, as
they're never cleaned up. Cleaning them up would involve
working out which connections do not have any pending work,
and it's not quite clear yet how to go about this.
8ea7af1 Allow the wallet to access hard fork information (moneromooo-monero)
760331b epee: make log macros behave like statements (moneromooo-monero)
3f2970f Add missing semicolons after log statements (moneromooo-monero)
In particular, <boost/program_options.hpp> blows up daemon.cpp.obj,
making it too big to compile in debug mode on Win32. Even on a
release build it drops daemon.cpp.o on Linux from 31MB to 20MB.
This has no effect on the final linked binary size.
The version number passed to those data's serialize function
was always 0, not the wallet's version as I had expected.
A version number now exists for these structures so they're
versioned correctly.
