Tweaks to difficulty adjustment algorithm
This PR changes the difficulty algorithm to adjust from the average difficulty over the
block window instead of from the last difficulty. It also removes the special rules for the
testnet, which are incompatible with difficulty averaging.
Closes#147 again.
The min-difficulty blocks are incompatible with difficulty averaging.
Network difficulty is also now defined as the difficulty the network is
currently working to solve, rather than the last non-min-difficulty block
difficulty.
"Block difficulty" is the difficulty listed in a block's header, which in the
testnet can sometimes be min-difficulty (if time-since-last-block is too large).
"Network difficulty" is the difficulty that the network was trying to satisfy
at a particular block height. In mainnet this is always equal to the difficulty
of the solved block for that height, but in testnet the network difficulty is
derived from the last non-min-difficulty block difficulty.
This commit fixes the RPC APIs that are intended to show network difficulty, so
that on testnet they don't sometimes drop to 1.0, confusing users.
Closes#1181
The main and test networks are configured to use parameters that are currently
low-memory but usable with the basic solver; they will be increased once the
solver is optimised. The regtest network is configured to have extremely low
memory usage for speed.
Note that Bitcoin's double-hasher is used for the difficulty check. This does
not match the paper, but is simpler than changing the block header
serialization. Single hashing is kept for the EquiHash solver because there is
no requirement on execution time there, only on memory usage.
03c5687 appropriate response when trying to get a block in pruned mode (Jonas Schnelli)
1b2e555 add autoprune information to RPC "getblockchaininfo" (Jonas Schnelli)
Rebased by @laanwj:
- update for RPC methods added since 84d13ee: setmocktime,
invalidateblock, reconsiderblock. Only the first, setmocktime, required a change,
the other two are thread safe.
If uint256() constructor takes a string, uint256(0) will become
dangerous when uint256 does not take integers anymore (it will go
through std::string(const char*) making a NULL string, and the explicit
keyword is no help).
- rest block request returns full unfolded tx details
- /rest/block/notxdetails/<HASH> returns block where transactions are only represented by its hash
There are 3 pieces of data that are maintained on disk. The actual block
and undo data, the block index (which can refer to positions on disk),
and the chainstate (which refers to the best block hash).
Earlier, there was no guarantee that blocks were written to disk before
block index entries referring to them were written. This commit introduces
dirty flags for block index data, and delays writing entries until the actual
block data is flushed.
With this stricter ordering in writes, it is now safe to not always flush
after every block, so there is no need for the IsInitialBlockDownload()
check there - instead we just write whenever enough time has passed or
the cache size grows too large. Also updating the wallet's best known block
is delayed until this is done, otherwise the wallet may end up referring to an
unknown block.
In addition, only do a write inside the block processing loop if necessary
(because of cache size exceeded). Otherwise, move the writing to a point
after processing is done, after relaying.
This fixes an iterator leak resulting in
bitcoind: db/version_set.cc:789: leveldb::VersionSet::~VersionSet(): Assertion `dummy_versions_.next_ == &dummy_versions_' failed."
exception on shutdown.
Also make sure to flush pcoinsTip before calling GetStats() to make
sure we apply them to the current height.
Bypassing the main coins cache allows more thorough checking with the same
memory budget.
This has no effect on performance because everything ends up in the child
cache created by VerifyDB itself.
It has bugged me ever since #4675, which effectively reduced the
number of checked blocks to reduce peak memory usage.
- Pass the coinsview to use as argument to VerifyDB
- This also avoids that the first `pcoinsTip->Flush()` after VerifyDB
writes a large slew of unchanged coin records back to the database.
