For the per confirmation number tracking of data, introduce a scale factor so that in the longer horizones confirmations are bucketed together at a resolution of the scale. (instead of 1008 individual data points for each fee bucket, have 42 data points each covering 24 different confirmation values.. (1-24), (25-48), etc.. )
Change the logic of estimateSmartFee to check a 60% threshold at half the target, a 85% threshold at the target and a 95% threshold at double the target. Always check the shortest time horizon possible and ensure that estimates are monotonically decreasing. Add a conservative mode, which makes sure that the 95% threshold is also met at longer time horizons as well.
Track information the ranges of fee rates that were used to calculate the fee estimates (the last range of fee rates in which the data points met the threshold and the first to fail) and provide an RPC call to return this information.
There is no point in even hashing a submitted block which doesn't have
a coinbase transaction.
This also results in more useful error reporting on corrupted input.
Thanks to rawodb for the bug report.
It has no business in `rpcserver.h`. Define it in the interface header
of the implementation unit `rpcblockchain` where it is defined.
Also modernize the signature to:
double GetDifficulty(const CBlockIndex* blockindex = nullptr);
(remove `extern`, replace `NULL` with `nullptr`)
Segwit's version bit will be signalled for all invocations of CreateNewBlock,
and not specifying segwit only will cause CreateNewBlock to skip transactions
with witness from being selected.
This a breaking API change to the prioritisetransaction RPC call which previously required exactly three arguments and now requires exactly two (hash and feeDelta). The function prioritiseTransaction is also updated.
Alex Morcos