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

<p>According to <a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki" rel="nofollow noreferrer">BIP 68</a>, setting <code>nSequence</code> value to 0xFFFFFFFF for every input in the transaction disables <code>nLocktime</code>. So, whatever may be the value of <code>nLocktime</code>, it will have no effect on the transaction as far as <code>nSequence</code> value is 0xFFFFFFFF.</p>

<blockquote>
  <p>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?</p>
</blockquote>

<p>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 <code>CSV</code> your <code>nSequence</code> value has to be &lt;= 0xEFFFFFFF. If <code>nSequence</code> 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 <code>nLocktime</code> along with Opt-in RBF, your <code>nSequence</code> value has to be between 0xF0000000 to 0xFFFFFFFD. Refer <a href="https://bitcoin.stackexchange.com/questions/87372/what-does-the-sequence-in-a-transaction-input-mean/87376#87376">this</a> for more info on <code>nSequence</code> and how it has evolved in the last few years.</p>

<blockquote>
  <p>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..</p>
</blockquote>

<p><code>nLocktime</code> is a transaction level feature while <code>nSequence</code> 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 <code>nLocktime</code>. If you check the function below <code>IsFinalTx</code>, it checks the validity of each transaction inputs by verifying that the <code>nSequence</code> numbers are valid.</p>

CC BY-SA 4.0
2019-06-10T19:22:18.880Z
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
CC BY-SA 4.0
2019-06-10T19:24:22.893Z
And, does this mean that ALL CSV txs are necessarily "replace-by-fee" as well?
pinhead
CC BY-SA 4.0
2019-06-10T19:24:27.007Z
@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
CC BY-SA 4.0
2019-06-10T19:32:51.123Z
@pinhead Yes, all CSV tx signal RBF due to the nature in which the `nSequence` value is set
Ugam Kamat
CC BY-SA 4.0
2019-06-10T18:32:49.400Z
2019-06-10T18:32:49.400Z
Ugam Kamat
<blockquote>
<p>Why is a &quot;bad&quot; locktime ok as long as all sequences are final? The tx won't be mineable anyway, right?</p>
</blockquote>
<p>With a final <code>nSequence</code>, the transaction <em>will</em> be mineable no matter the <code>nLockTime</code>.</p>
<blockquote>
<p>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?</p>
</blockquote>
<p>No, it's not required.<br />
Regarding the implications, if the <code>nSequence</code> is:</p>
<ul>
<li><code>= 0xffffffff</code>, then the transaction is final no matter the <code>nLockTime</code>.</li>
<li><code>&lt; 0xfffffffe</code>, then the transaction signals for RBF.</li>
<li><code>&lt; 0xefffffff</code>, then the transaction signals <a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki" rel="nofollow noreferrer">BIP68</a> relative locktime. <a href="https://bitcoin.stackexchange.com/questions/87372/what-does-the-sequence-in-a-transaction-input-mean/87376#87376">More here</a>.</li>
</ul>
<blockquote>
<p>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.</p>
</blockquote>
<p>It does. It impacts finality by deactivating the check for <code>nLockTime</code> 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.</p>

CC BY-SA 4.0
2020-07-05T09:39:37.093Z
2020-07-05T09:39:37.093Z
Antoine Poinsot
<p>bitcoind <code>IsFinalTx()</code> as seen <a href="https://github.com/bitcoin/bitcoin/blob/03858b23fe1d17e681eb18d24602b276020295a0/src/consensus/tx_verify.cpp#L17-L28" rel="nofollow noreferrer">here</a> checks the properties of a transaction in this order:</p>

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

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

<p><a href="https://bitcoin.stackexchange.com/questions/18984/could-i-mine-a-non-final-transaction">Non-final transactions are not valid in blocks</a>, so my questions are:</p>

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

<transactions><locktime><sequence><checksequenceverify>
What is transaction "finality"?
pinhead
# What is transaction "finality"?

(Asked by: username_0 on 2019-06-10)

bitcoind `IsFinalTx()` as seen [here](https://github.com/bitcoin/bitcoin/blob/03858b23fe1d17e681eb18d24602b276020295a0/src/consensus/tx_verify.cpp#L17-L28) 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](https://bitcoin.stackexchange.com/questions/18984/could-i-mine-a-non-final-transaction), 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.

**Tags:** transactions, locktime, sequence, checksequenceverify


---

## 2 answers

### Answer by username_1 on 2019-06-10. Score: 1 | Accepted answer

> 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](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki), 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](https://bitcoin.stackexchange.com/questions/87372/what-does-the-sequence-in-a-transaction-input-mean/87376#87376) 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.

> **Comments:**
> **username_0**: 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?  
> **username_0**: And, does this mean that ALL CSV txs are necessarily "replace-by-fee" as well?  
> **username_1**: @username_0 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.  
> **username_1**: @username_0 Yes, all CSV tx signal RBF due to the nature in which the `nSequence` value is set  

---

### Answer by username_2 on 2020-07-05. Score: 0

> 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](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) relative locktime. [More here](https://bitcoin.stackexchange.com/questions/87372/what-does-the-sequence-in-a-transaction-input-mean/87376#87376).

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


---

