Start importwallet rescans at the first block with timestamp greater or equal
to the wallet birthday instead of the last block with timestamp less or equal.
This fixes an edge case bug where importwallet could fail to start the rescan
early enough if there are blocks with decreasing timestamps or multiple blocks
with the same timestamp.
761392d [logging] log system time and mock time (John Newbery)
Tree-SHA512: 0a4b3ad74bcac201be490fe12e4b45adeabc39030ac46f40e1aeb2a20b2f3963e4468e65798d8aaeca1818759cab55ff2b2aa214500aa11571492c3301dd31c1
e3c9f2d Use a verbosity instead of two verbose parameters (Andrew Chow)
c99ab3c RPC: Allow multiple names for parameters (Luke Dashjr)
Tree-SHA512: 686b38f6b0106563738d51f55666fe6d49a5b121b30d4480c2bfb640a59ede8e6f7f3c05c3c5d80a5288e127991e191d19d1d4f9ace566fd39edeb27b31857ff
An off-by-one-block bug in importmulti rescan logic could cause it to return
success in an edge case even when a rescan was not successful. The case where
this would happen is if there were multiple blocks in a row with the same
GetBlockTimeMax() value, and the last block was scanned successfully, but one
or more of the earlier blocks was not readable.
de487b7 Tests: Add test for getnetworkhashps (Jimmy Song)
Tree-SHA512: b1418ad904618f639ffa34dd40906692aff1fdf1a0d13a9af00039e7a6a2b758091734b89c0c91e8d455da6b15a0e435a9a9ca97a41d97bf395b844c761ffa27
Verbose is changed to an int. This can have values from 0-2 for each level of verbosity.
Verbosity level 2 has transaction details displayed in the results.
91700aa Re-enable upnp support in contrib/debian (Matt Corallo)
c5071e1 Build with QT5 on Debian-based systems using contrib/debian (Matt Corallo)
a8e9286 Bump minimum boost version in contrib/debian (Matt Corallo)
9970219 Update contrib/debian to latest Ubuntu PPA upload. (Matt Corallo)
Tree-SHA512: ee4d3c5927a9cfb2794672eaca883c4af5df541383afbdbc6500714ee17518e78b58f509b2e9805bbc424ef97a5e64be0b9a977212c5002cb682f0569d28099b
f203ecc Shadowing is not enabled by default, update doc accordingly. (Pavel Janík)
Tree-SHA512: a7170827caa9d35457356808445ef2387fd2edde72fb76c6241cfd5decad218558b307d223e86bb66041576b638f90f6efa8a46ea6208d43da275a993617c997
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.. )
Store in fee estimate file the block span for which we were tracking estimates, so we know what targets we can successfully evaluate with the data in the file. When restarting use either this historical block span to set valid range of targets until our current span of tracking estimates is just as long.
Track the first time we seen txs in a block that we have been tracking in our mempool. Used to evaluate validity of fee estimates for different targets.
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.
Instead of stopping if it encounters a "sufficient" number of transactions which don't meet the threshold for being confirmed within the target, it keeps looking to add more transactions to see if there is a temporary blip in the data. This allows a smaller number of required data points.
Ryan Havar