1

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.

0

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.

  • So a value of 0xF0000000 has "no consensus meaning" -- but it is still signalling RBF right? So it still has mempool/policy meaning. This would be true for all transactions, version 1 or 2? – pinhead Jun 10 at 19:22
  • And, does this mean that ALL CSV txs are necessarily "replace-by-fee" as well? – pinhead Jun 10 at 19:24
  • @pinhead as I said in the answer there is no consensus meaning to the sequence number but Other rules apply. Yes, it will be signalling RBF. This changed meaning to nSequence was done as a part of BIP 68 soft fork and work for version>=2. – Ugam Kamat Jun 10 at 19:24
  • @pinhead Yes, all CSV tx signal RBF due to the nature in which the nSequence value is set – Ugam Kamat Jun 10 at 19:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.