OP_CHECKLOCKTIMEVERIFY source code clarification

[qrius1111]

from src/interpreter.cpp - I'm seeking clarification on why OP_CHECKLOCKTIMEVERIFY will fail if the current txin sequence number is set to maxint. The code comments say it will be "bypassed", but it is my understanding that if the script fails to validate with SCRIPT_ERR_UNSATISFIED_LOCKTIME then the transaction will not go into the mempool, and thus will not be selected for mining into a block.

Code:

...
case OP_CHECKLOCKTIMEVERIFY:
{
    ...
    // Actually compare the specified lock time with the transaction.
    if (!checker.CheckLockTime(nLockTime))
        return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);

    break;
}
...

bool TransactionSignatureChecker::CheckLockTime(const CScriptNum& nLockTime) const
{
    ...

    // 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.
    //
    // Testing if this vin is not final is sufficient to
    // prevent this condition. Alternatively we could test all
    // inputs, but testing just this input minimizes the data
    // required to prove correct CHECKLOCKTIMEVERIFY execution.
    if (txTo->vin[nIn].IsFinal())
        return false;

    return true;
}

For starters I don't understand why only the current txin is tested. And secondly, I would have thought that if all txin sequence numbers were set to maxint then it should return true, not false. Maybe the if statement has a bug and should be negated there?

Can someone explain this code to me please.

[gmaxwell]

It is saying that if this case weren't rejected then CHECKLOCKTIMEVERIFY could be bypassed by the signer, via making all their txins final.  To prevent this, _this_ txin is required to be non-final.  From a modularity/clarity perspective it's preferable if a script has only local effects (only looks at it's own input) unless more is needed.

[qrius1111]

That makes sense. I guess allowing OP_CHECKLOCKTIMEVERIFY to be bypassed by the signer using sequence=maxint would make OP_CHECKLOCKTIMEVERIFY no more useful than the locktime field that already exists in the transaction, so I can see why its set up that way. Its just not at all obvious from the comments that this is the intended functionality.

I think I understand why only the sequence number for the txin containing OP_CHECKLOCKTIMEVERIFY is tested, but it does have weird implications when considered in combination with IsFinalTx(). Like a transaction could be "not final" (other txin sequence nums < maxint, and a locktime in the future), yet this script would still validate so long as this txin sequence = maxint. I can't think of any circumstances where that would be a problem, since the transaction would not make it into the blockchain due to failing the IsFinalTx() constraint, but still... the logic is weird.