Transactions that fail CLTV verification will be rejected from the
mempool, making it easy to test the feature. However blocks containing
"invalid" CLTV-using transactions will still be accepted; this is *not*
the soft-fork required to actually enable CLTV for production use.
<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.
This should fix the spurious comparison tool failures.
See discussion here: https://github.com/bitcoin/bitcoin/pull/6305
The race fix was cherry-picked on top of the version we're currently using, so
it should be functionally identical otherwise.
This should be functionally identical to what's in place now. It was built from
be0eef7744
That commit is the same as this pruned commit in TheBlueMatt's repo:
https://github.com/TheBlueMatt/bitcoinj/commit/0f7b5d8
Now we'll be able to trust the line numbers in the stack traces.
When responding to a getblocks message, only return inv's as
long as we HAVE_DATA for blocks in the chain, and only for blocks
that we aren't likely to delete in the near future.
- fixes#3136
- the problem is related to Boost path and a static initialized internal
pointer
- using a std::string in CDBEnv::EnvShutdown() prevents the problem
- this removes the boost::filesystem::path path field from CDBEnv
26a639e remove using namespace std from addrman.cpp (Philip Kaufmann)
40c592a make CAddrMan::size() return the correct type of size_t (Philip Kaufmann)
For leveldb "An iterator operates on a snapshot of the database taken
when the iterator is created". This means that it is unnecessary to
lock out other threads while computing statistics, and neither to hold
cs_main for the whole time. Let the thread run free.
- rpcwallet: No need to lock twice here
- openssl: Clang doesn't understand selective lock/unlock here. Ignore it.
- CNode: Fix a legitimate (though very unlikely) locking bug.
This allows us to use function/variable/class attributes to specify locking
requisites, allowing problems to be detected during static analysis.
This works perfectly with newer Clang versions (tested with 3.3-3.7). For older
versions (tested 3.2), it compiles fine but spews lots of false-positives.
Wladimir J. van der Laan