Mempool only CHECKLOCKTIMEVERIFY (BIP65) verification

Essentially makes passing CHECKLOCKTIMEVERIFY (BIP65) an IsStandard() rule to make it easy to test applications using it; blocks containing transactions with invalid CHECKLOCKTIMEVERIFY arguments are still accepted.

This pull-req is *not* a soft-fork nor does it contain any code to start that process.

An alternative would be to make a command-line flag to enable CLTV, however actually implementing that is somewhat ugly. There is a small risk of people thinking that it's safe to depend on CLTV, although I think that's outweighed by the value of thoroughly testing everything but the soft-fork itself.

Thanks for @sipa and also @btcdrak for the rebase. Credit goes to @gmaxwell for the suggestion of comparing the argument against the transaction nLockTime rather than the current time/blockheight directly.

Background: BIP65 - https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
I'm not sure that's any less confusing.

The key concept to understand is that CLTV only checks the transaction's nLockTime field, not the actual block height or time. Thus anything that disables nLockTime's effect can bypass CLTV.

Incidentally I think part of the confusion is how the SignatureChecker object separates the logic of CLTV into two completely disjoint parts for no clear reason. It's a lot more clear when all this logic is in one place. A better refactoring would be to encapsulate the execution state, and if needed, cache expensive operations on that state like hashing the transaction. This is especially clear when you consider future improvements like opcodes to sign something other than the txin prevout.


On 17 December 2014 10:04:40 GMT-05:00, SergioDemianLerner <notifications@github.com> wrote:
>> +        (txTo.nLockTime <  LOCKTIME_THRESHOLD && nLockTime < 
>LOCKTIME_THRESHOLD) ||
>> +        (txTo.nLockTime >= LOCKTIME_THRESHOLD && nLockTime >=
>LOCKTIME_THRESHOLD)
>> +    ))
>> +        return false;
>> +
>> +    // Now that we know we're comparing apples-to-apples, the
>> +    // comparison is a simple numeric one.
>> +    if (nLockTime > (int64_t)txTo.nLockTime)
>> +        return false;
>> +
>> +    // Finally the nLockTime feature can be disabled and thus
>> +    // CHECKLOCKTIMEVERIFY bypassed if every txin has been
>> +    // finalized by setting nSequence to maxint. The
>> +    // transaction would be allowed into the blockchain, making
>> +    // the opcode ineffective.
>> +    //
>
>The comment regarding "bypassing" is b bit confusing. Shouldn't it say
>"Finally CHECKLOCKTIMEVERIFY WILL INVALIDATE THE REDEEMER TRANSACTION
>if the corresponding txin has been finalized by setting nSequence to
>maxint."
>
>---
>Reply to this email directly or view it on GitHub:
>https://github.com/bitcoin/bitcoin/pull/5496/files#r21976623