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.
Checks memory before and after a transaction that requires a private key.
Each time, 32 bytes of memory for a private key should be used.
Tested in wallet.py instead of its own file to save testing time.
Cleanup request from #10287.
Change "Test #:" comments to "Test:"
Change BOOST_CHECK(... = ...) to BOOST_CHECK_EQUAL(..., ...)
Remove three unnecessary if statements
97477c5 Maintain state across GetStrongRandBytes calls (Pieter Wuille)
Tree-SHA512: 77e9b1f3c6eeb0c2a3e0c64358150767222ff0b7120ccd5f4ae0276cea0e4fa275c1b757e3f20be07dc0b4ef07f70ab0b70112080c8d3d0cb6ed703db8a59168
