Compilation of bitmonero on Arch with gcc 6.1 results in the following
error:
/home/mwo/bitmonero/tests/unit_tests/hardfork.cpp: In member function ‘virtual void TestDB::set_hard_fork_version(uint64_t, uint8_t)’:
/home/mwo/bitmonero/tests/unit_tests/hardfork.cpp:132:5: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
if (versions.size() <= height) versions.resize(height+1); versions[height] = version;
This can be fixed by simply unfolding this line into three lines.
The tests for rejection of unmixable outputs in v2 are commented out,
as there are no unmixable outputs created anymore. This should be
restored at some point.
This is a list of existing output amounts along with the number
of outputs of that amount in the blockchain.
The daemon command takes:
- no parameters: all outputs with at least 3 instances
- one parameter: all outputs with at least that many instances
- two parameters: all outputs within that many instances
The default starts at 3 to avoid massive spamming of all dust
outputs in the blockchain, and is the current minimum mixin
requirement.
An optional vector of amounts may be passed, to request
histogram only for those outputs.
We also replace the --fakechain option with an optional structure
containing details about configuration for the core/blockchain,
for test purposes. This seems more future friendly.
7658ac0 blockchain: revert handle_get_objects adding block id on tx not found (moneromooo-monero)
3a0f4d8 berkeleydb: fix delete/free mismatch (moneromooo-monero)
1642be2 minor bugfixes and refactoring (Thomas Winget)
098dcf2 unit_tests: fix mnemonics unit test testing invalid seeds (moneromooo-monero)
119eb10 unit_tests: fix hard fork unit tests and add a test for major too (moneromooo-monero)
64a2aa3 hardfork: allow passing chain height in get(height) for convenience (moneromooo-monero)
Some word triplets, such as "mugged names nail", are not valid
results from any 32 bit value. If used to decode a 32 bit value,
the result will therefore encode to a different word triplet.
Fix this by using random words converted from an actual random
bitstring, ensuring we always get valid triplets.
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.
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.
They were trying to send too much monero, and thus failing.
The parameters were set in such a way that the (simple) output
gathering code could fulfill them for 4 block rewards for the
original Bytecoin emission, but that does not work with monero
so we need to use smaller values.
The current monero consensus uses 0.01 per kB fees, so use enough
for 2 kB transactions for now. It'll probably have to be either
bumped further or changed to calculate the proper fee.
The core tests use the blockchain, and reset it to be able
to add test data to it. This does not play nice with the
databases, since those will save that data without an explicit
save call.
We add a fakechain flag that the tests will set, which tells
the core and blockchain code to use a separate database, as
well as skip a few things like checkpoints and fixup, which
only make sense for real data.
Also add some more tests, and rename some instances of
"version" and "add" for clarity.
NOTE: the starting height values are sometimes wrong.
I suspect this is due to the hard fork reorg code being
buggy, since they're good when syncing after the fact.
However, they're not actually used by the consensus code,
so I'm ignoring this for now, but this needs debugging.
The last relayed time of a transaction is maintained, and
transactions will be relayed again if they are still in the
pool after a certain amount of time, which increases with
the transaction's age. All such transactions are resent,
whether or not they originated on the local node.
