Trying on the BIP65, it says that the CLTV will fail if the nSequence discipline of the txin is 0xffffffff. It appears logical to me since if the nSequence of all inputs are set to 0xffffffff, the worth of nLocktime and absolute time are usually not considered. Nonetheless, does the nSequence of the enter that consumes output with CLTV should be != 0xffffffff, or the nSequence of any enter contained in the transaction could be != 0xffffffff and the enter that consumes output with CLTV can stick with nSequence set to 0xffffffff and that CLTV nonetheless move? I’m asking as a result of in each circumstances the locktime and absolute time lock might be considered, that’s, the locktime might be activated. Thanks.

LeaBit is a brand new contributor to this web site. Take care in asking for clarification, commenting, and answering.
Try our Code of Conduct.

Citing BIP65, which launched OP_CHECKLOCKTIMEVERIFY:

When executed, if any of the next circumstances are true, the script interpreter will terminate with an error:

  • the stack is empty; or
  • the highest merchandise on the stack is lower than 0; or
  • the lock-time kind (peak vs. timestamp) of the highest stack merchandise and the nLockTime discipline are usually not the identical; or
  • the highest stack merchandise is bigger than the transaction’s nLockTime discipline; or
    the nSequence discipline of the txin is 0xffffffff;

(emphasis mine)

So OP_CHECKLOCKTIMEVERIFY requires the nSequence worth of the spending enter itself to not be 0xffffffff. Whereas it technically suffices that at the very least one enter has a non-0xffffffff nSequence for the spending transaction to have a related nLockTime, the selection was made in BIP65 to require that the enter itself has such an nSequence. Based on the implementation’s supply code, this was achieved to attenuate the quantity of knowledge wanted to show an enter is appropriate.