cbded43 core_tests: fix ring_signature_1 tests (moneromooo-monero)
c3d208f core_tests: bump default test fee to 0.02 monero (moneromooo-monero)
10da0a0 add a --fakechain argument for tests (moneromooo-monero)
eee44e6 unit_tests: fix block reward test using post hard fork settings (moneromooo-monero)
595893f blockchain: log block (not chain) height in "BLOCK SUCCESFULLY ADDED" (moneromooo-monero)
2369968 blockchain: fix off by one in get_blocks (moneromooo-monero)
8af913a db_lmdb: implement BlockchainLMDB::reset (moneromooo-monero)
4833f4f db_bdb: implement BlockchainBDB::reset (moneromooo-monero)
18bf06e tx_pool: fix "minumim" typo in message (moneromooo-monero)
44f1267 tests: fix a typo in test name (moneromooo-monero)
1494557 db_lmdb: create all needed directories, not just the leaf one (moneromooo-monero)
015b68a db_bdb: create all needed directories, not just the leaf one (moneromooo-monero)
f141869 tests: remove data-dir argument registration (moneromooo-monero)
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.
Data is only guaranteed to be valid within the lifetime of a txn.
You cannot use data returned from LMDB after the txn ends.
Also, fixed a missing txn.commit BlockchainLMDB::get_tx_unlock_time()
This fixes coretests, which does not register daemon specific arguments,
but uses core, which uses those arguments. Also gets rid of an unwanted
dependency on daemon code from core.
c6cfe0f wallet: make the wallet refresh type a wallet setting (moneromooo-monero)
fef2493 wallet: default auto-refresh to true for old wallets (moneromooo-monero)
This is a precaution for older Berkeley DB versions.
- smooth reports an issue running with 4.7:
DB_ENV->log_set_config: DB_LOG_IN_MEMORY: method not permitted
after handle's open method
- this works just fine with 5.3
- we do not use DB_LOG_IN_MEMORY, but we use DB_LOG_AUTO_REMOVE
- libdb docs say some flags must be set before open, and some
may be set at any time, but never say some must be set after
open
- moving the call to log_set_config before open works with 5.3
Therefore, it seems best to move the call before open.
This prevents an exception from existing the loop without
calling the exit handler, if one is defined.
The daemon defines one, which stops the p2p layer, and will
only exit once the p2p layer is shut down. This would cause
a hang upon an exception, as the input thread would have
exited and the daemon would wait forever with no console
user input.
Early DB versions did not store key images for inputs if the
transaction spending them had no outputs (ie, all fee). This
is not correct, as this would allow these outputs to be double
spent. This was fixed in 533acc30ed
a few months ago, but databases having synced blocks 2021612 and
685498 with a faulty version will be missing those key images
in the spent keys database. This code checks for this, and adds
those key images if they are missing.
a3c5ca0 blockchain_db: make the indexing base a BlockchainDB virtual function (moneromooo-monero)
a702118 blockchain_dump: fix output key dump for BDB 1-based indices (moneromooo-monero)
3bf35e1 db_bdb: read 32 bit heights from keys (moneromooo-monero)
Berkeley DB uses 1 based indices for RECNO databases, and the
implementation of BlockchainDB for Berkeley DB assumes 1 based
indices are passed to the API, whereas the LMDB one assumes
0 based indices. This is all internally consisteny, but since
the BDB code stores 1 based indices in the database, external
users have to be aware of this, as the indices will be off by
one depending on which DB is used.
