Allows CCoinsCacheEntry/CCoinsMap entries to either be a CCoins
or, by setting a flag in the map key, a withdraw output from a
chain from which withdraw proofs are allowed to move to this
chain from.
This uses IsInitialBlockDownload to enable headers-fetching from
all peers (in addition to the existing recent-headers-tip check).
It also adds a hidden flag which allows you to force IBD to false,
enabling download from all peers.
This starts a headers-sync with *all* peers instead of just "good"
ones after we finish initial headers sync.
It also downloads blocks from all peers after IBD finishes.
Support watchonly in fundrawtransaction, CreateTransaction, SelectCoins
and coin selection in general.
Coin selection is exposed over RPC through fundrawtransaction, and
watchonly can be enabled by passing includeWatching true (defaults to
false).
fundrawtransaction will first attempt to fund a transaction without
using watchonly, even when includeWatching is enabled. When this fails,
an includeWatching attempt is made.
When an includeWatching attempt at coin selection is performed (in
CreateTransaction), and all watchonlys are consumed leaving no funds
available for a fee, then CreateTransaction will not include a fee in
the transaction.
Also, includeWatching tests (for fundrawtransaction).
See also: https://github.com/bitcoin/bitcoin/pull/5503
Transactions that fail CSV verification will be rejected from the mempool, making it easy to test the feature. However blocks containing "invalid" CSV-using transactions will still be accepted; this is *not* the soft-fork required to actually enable CSV for production use.
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.
Transactions are not allowed in the memory pool or selected for inclusion in a block until their lock times exceed chainActive.Tip()->GetMedianTimePast(). However blocks including transactions which are only mature under the old rules are still accepted; this is *not* the soft-fork required to actually rely on the new constraint in production.
Transactions that fail relative lock time checks will be rejected from the mempool and not included in generated blocks, making it easy to test the feature. However blocks including transactions containing "invalid" relative lock times will still be accepted; this is *not* the soft-fork required to actually enable relative lock times for production use.
<nInvSequence> CHECKSEQUENCEVERIFY -> <nInvSequence>
Fails if ~txin.nSequence < nInvSequence (the nSequence field of the txin is bit-inverted before the comparison), allowing funds of a txout to be locked for a number of blocks or a duration of time after its inclusion in a block.
Only the logic and unit tests are implemented; this commit does not have changes to policy or consensus behavior.
<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.
The lock-time code currently uses CBlock::nTime as the cutoff point for time based locked transactions. This has the unfortunate outcome of creating a perverse incentive for miners to lie about the time of a block in order to collect more fees by including transactions that by wall clock determination have not yet matured. By using CBlockIndex::GetMedianTimePast from the prior block instead, the self-interested miner no longer gains from generating blocks with fraudulent timestamps. Users can compensate for this change by simply adding an hour (3600 seconds) to their time-based lock times.
If enforced, this would be a soft-fork change. This commit only adds the functionality on an unexecuted code path, without changing the behaviour of Bitcoin Core.
In summary, the sequence number of each input in a transaction is used to store an inverted relative locktime: a delta value which is added to the height or time of the block which included the output being spent to generate a per-input lock time from the sequence number. If enforced, this would make transaction replacement possible as replacing an input with a higher sequence number (lower relative lock time) would allow the new transaction to make it on the chain sooner.
This commit does not implement the transaction replacement logic. Nor does this commit make the relative lock time rules as consensus or policy rules. It merely adds new, but disabled functionality and unit tests for that functionality.
Instead of checking if the transaction is in a category of cases to return true and failing otherwise, we return false if the tx is a failure case and otherwise return true. This removes an early-exit opportunity which will no longer be possible once sequence numbers are re-enabled, but has no change in behaviour.
Under some circumstances it is possible for there to be a significant, discontinuous jump in a node's clock value. On mining nodes, this can result in block templates which are no longer valid due to time-based nLockTime constraints. UpdateTime() is modified so that it will never decrease a block's nLockTime, thereby preventing such invalidations.
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).
