`bitcoind -X -noX` ends up, unintuitively, with `X` set.
(for all boolean options X)
This result is due to the odd two-pass processing of arguments. This
patch fixes this oddity and simplifies the code at the same time.
JSON makes no distinction between numbers and reals, and our code
doesn't need to do so either.
This removes VREAL, as well as its specific post-processing in
`UniValue::write`. Non-monetary amounts do not need to be forcibly
formatted with 8 decimals, so the extra roundtrip was unnecessary
(and potentially loses precision).
This is the format that was always returned to JSON clients.
The difference was not noticed before, because VREAL values
are post-processed by univalue.
By implementing the functionality directly it breaks the dependency
of rpcserver on utilmoneystr. FormatMoney is now only used for debugging
purposes.
To test, port over the formatting tests from util_tests.cpp to
rpc_tests.cpp.
Add a function `ParseFixedPoint` that parses numbers according
to the JSON number specification and returns a 64-bit integer.
Then this in `AmountFromValue`, rather than `ParseMoney`.
Also add lots of tests (thanks to @jonasschnelli for some of them).
Fixes issue #6297.
Four cases included:
* The CLTV operand type mismatches the tx locktime. In the script it is
1 (interpreted as block height), but in the tx is 500000000
(interpreted as date)
* The stack is empty when executing OP_CLTV
* The tx is final by having only one input with MAX_INT sequence number
* The operand for CLTV is negative (after OP_0 OP_1 OP_SUB)
<nLockTime> CHECKLOCKTIMEVERIFY -> <nLockTime>
Fails if tx.nLockTime < nLockTime, allowing the funds in a txout to be
locked until some block height or block time in the future is reached.
Only the logic and unittests are implemented; this commit does not have
any actual soft-fork logic in it.
Thanks to Pieter Wuille for rebase.
Credit goes to Gregory Maxwell for the suggestion of comparing the
argument against the transaction nLockTime rather than the current
time/blockheight directly.
Univalue's parsing of \u escape sequences did not handle NUL characters
correctly. They were, effectively, dropped. The extended test-case
fails with the old code, and is fixed with this patch.
The partition checking code was using chainActive timestamps
to detect partitioning; with headers-first syncing, it should use
(and with this pull request, does use) pIndexBestHeader timestamps.
Fixes issue #6251
- Add an accept test for zero amounts, and a reject test for negative
amounts
- Remove ugly hack in `settxfee` that is no longer necessary
- Do explicit zero checks in wallet RPC functions
- Don't add a check for zero amounts in `createrawtransaction` - this
could be seen as a feature
Strict parsing functions for other numeric types.
- ParseInt64 analogous to ParseInt32, but for 64-bit values.
- ParseDouble for doubles.
- Make all three Parse* functions more strict (e.g. reject whitespace on
the inside)
Also add tests.
- implement find_value() function for UniValue
- replace all Array/Value/Object types with UniValues, remove JSON Spirit to UniValue wrapper
- remove JSON Spirit sources
Change `read_string` to fail when not the entire input has been
consumed. This avoids unexpected, even dangerous behavior (fixes#6223).
The new JSON parser adapted in #6121 also solves this problem so in
master this is a temporary fix, but should be backported to older releases.
Also adds tests for the new behavior.
If/when CTransaction::CURRENT_VERSION is incremented, this will break CChainParams and the miner tests. This fix sets the transaction version explicitly where we depend on the hash value (genesis block, proof of work checks).
Previously due to an off-by-one error the wallet ignored
nLockTime-by-height transactions that would be valid in the next block
even though they are accepted into the mempool. The transactions
wouldn't show up until confirmed, nor would they be included in the
unconfirmed balance. Similar to the mempool behavior fix in 665bdd3b,
the wallet code was calling IsFinalTx() directly without taking into
account the fact that doing so tells you if the transaction could have
been mined in the *current* block, rather than the next block.
To fix this we strip IsFinalTx() of non-consensus-critical
functionality, removing the default arguments, and add CheckFinalTx() to
check if a transaction will be final in the next block.
Fix two CSubNet constructor problems:
- The use of `/x` where 8 does not divide x was broken, due to a
bit-order issue
- The use of e.g. `1.2.3.4/24` where the netmasked bits in the network
are not 0 was broken. Fix this by explicitly normalizing the netwok
according to the bitmask.
Also add tests for these cases.
Fixes#6179. Thanks to @jonasschnelli for reporting and initial fix.
On a busy or slow system, the CScheduler unit test could fail because it
assumed all threads would be done after a couple of milliseconds.
Replace the hard-coded sleep with CScheduler stop() method that
will cleanly exit the servicing threads when all tasks are completely
finished.
Create a monitoring task that counts how many blocks have been found in the last four hours.
If very few or too many have been found, an alert is triggered.
"Very few" and "too many" are set based on a false positive rate of once every fifty years of constant running with constant hashing power, which works out to getting 5 or fewer or 48 or more blocks in four hours (instead of the average of 24).
Only one alert per day is triggered, so if you get disconnected from the network (or are being Sybil'ed) -alertnotify will be triggered after 3.5 hours but you won't get another -alertnotify for 24 hours.
Tested with a new unit test and by running on the main network with -debug=partitioncheck
Run test/test_bitcoin --log_level=message to see the alert messages:
WARNING: check your network connection, 3 blocks received in the last 4 hours (24 expected)
WARNING: abnormally high number of blocks generated, 60 blocks received in the last 4 hours (24 expected)
The -debug=partitioncheck debug.log messages look like:
ThreadPartitionCheck : Found 22 blocks in the last 4 hours
ThreadPartitionCheck : likelihood: 0.0777702
Instead of only checking height to decide whether to disable script checks,
actually check whether a block is an ancestor of a checkpoint, up to which
headers have been validated. This means that we don't have to prevent
accepting a side branch anymore - it will be safe, just less fast to
do.
We still need to prevent being fed a multitude of low-difficulty headers
filling up our memory. The mechanism for that is unchanged for now: once
a checkpoint is reached with headers, no headers chain branching off before
that point are allowed anymore.
Wladimir J. van der Laan