What is transaction "finality"? bitcoind IsFinalTx() as seen here checks the properties of a transaction in this order:


Is nLockTime exactly 0? That's final. return.
If it's not 0, is it below the current block height / time? If so, it's final. return.
Ensure that every tx input is exactly 0xffffffff. If so, it's final.


Because these are checked in order with return statements, nSequence won't even be checked if nLockTime == 0. Furthermore, a transaction that is NOT past its nLockTime value could still be "final" as long as all the nSequence values are 0xffffffff 

Non-final transactions are not valid in blocks, so my questions are:


Why is a "bad" locktime ok as long as all sequences are final? The tx won't be mineable anyway, right?
What are the implications for replace-by-fee and Check Sequence Verify transactions (when a non-final nSequence value is used)? Does this mean that to use those features, nLockTime has to be set a certain way?
Or, maybe, because nLockTime has to be below the current time/height anyway, this is all just moot and really, nSequence doesn't really impact transaction finality at all.
Why is a "bad" locktime ok as long as all sequences are final? The tx won't be mineable anyway, right?


According to BIP 68, setting nSequence value to 0xFFFFFFFF for every input in the transaction disables nLocktime. So, whatever may be the value of nLocktime, it will have no effect on the transaction as far as nSequence value is 0xFFFFFFFF.


  What are the implications for replace-by-fee and Check Sequence Verify transactions (when a non-final nSequence value is used)? Does this mean that to use those features, nLockTime has to be set a certain way?


It considered a transaction has opted in to allow replacement of itself, if any of its inputs have an nSequence number LESS than 0xFFFFFFFE. To use CSV your nSequence value has to be &lt;= 0xEFFFFFFF. If nSequence value > 0xEFFFFFFF, then there us no consensus meaning to the sequence number and it can be included in any block under all currently possible circumstances. So for using nLocktime along with Opt-in RBF, your nSequence value has to be between 0xF0000000 to 0xFFFFFFFD. Refer this for more info on nSequence and how it has evolved in the last few years.


  Or, maybe, because nLockTime has to be below the current time/height anyway, this is all just moot and really, nSequence doesn't really impact transaction finality at all..


nLocktime is a transaction level feature while nSequence is an input level feature. So, the program basically is optimized so that individual inputs are not checked if the transaction itself is invalid due to nLocktime. If you check the function below IsFinalTx, it checks the validity of each transaction inputs by verifying that the nSequence numbers are valid.