What is transaction "finality"?

Question

bitcoind IsFinalTx() as seen here checks the properties of a transaction in this order:

1. Is nLockTime exactly 0? That's final. return.
2. If it's not 0, is it below the current block height / time? If so, it's final. return.
3. 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.

Answer 1

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 <= 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.

Answer 2

Why is a "bad" locktime ok as long as all sequences are final? The tx won't be mineable anyway, right?

With a final nSequence, the transaction will be mineable no matter the nLockTime.

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?

No, it's not required.
Regarding the implications, if the nSequence is:

• = 0xffffffff, then the transaction is final no matter the nLockTime.
• < 0xfffffffe, then the transaction signals for RBF.
• < 0xefffffff, then the transaction signals BIP68 relative locktime. More here.

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.

It does. It impacts finality by deactivating the check for nLockTime if it is set to the maximum value, and since BIP68 (consensus soft fork) was activated on the network it may impact finality by specifying a relative lock time.