<h2>Original meaning of nSequence in transactions</h2>
<p><code>nSequence</code> is a 4 byte input level feature. The original meaning of <code>nSequence</code> was to allow modification of transactions in the mempool. So, if the nSequence value of the input was less than <code>0xFFFFFFFF</code> (<code>4294967295</code> in decimal), it indicated a transaction that was not yet finalized. Such a transaction would be held in the mempool until it was replaced by another transaction spending the same inputs with a higher nSequence value. Once a transaction was received whose inputs had an nSequence value of <code>0xFFFFFFFF</code> it would be considered finalized and mined.</p>
<p>In that implementation, replacement transactions did not have to pay additional fees, so there was no direct incentive for miners to include the replacement. Also, no built-in rate limiting prevented overuse of relay node bandwidth. Hence, this <a href="https://bitcoincore.org/en/faq/optin_rbf/#who-invented-unconfirmed-transaction-replacement-does-it-go-against-the-vision-of-bitcoin" rel="noreferrer">feature was disabled later</a> as it was possible for an attacker to use up all the bandwidth among full nodes at only a small cost to themselves, creating a denial-of-service vulnerability. This made it difficult for spenders to adjust their previously sent transactions to deal with unexpected confirmation delays or to perform other useful replacements.</p>
<h2>Opt-in Full Replace-by-Fee Signaling</h2>
<p>Then came the <a href="https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki" rel="noreferrer">proposal</a> for Opt-in Full Replace-by-Fee Signaling. It considered a transaction to have opted in to allow replacement of itself, if any of its inputs have an nSequence number less than <code>0xFFFFFFFE</code>. It also required a higher fee than the previous relayed transaction.</p>
<h2>Absolute and Relative Locktime</h2>
<p>Transaction with <code>nLockTime</code> is used to prevent the mining of a transaction until a certain date (specified in block no. or time). <a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki" rel="noreferrer">BIP 68</a> activation defined the meaning of sequence numbers for transactions with an <code>nVersion &gt;=2</code>. <code>nSequence</code> was repurposed as a relative locktime. That means it prevents mining of a transaction until the input that the transaction is spending has reached a certain age in blocks or timespan.  If <code>nSequence &gt; 0xEFFFFFFF</code> then there us no consensus meaning to the sequence number and it can be included in any block under all currently possible circumstances. If <code>nSequence &lt;= 0xEFFFFFFF</code>, it implies relative locktime.</p>
<p>If <code>nSequence &lt;=0xEFFFFFFF</code>, then the sequence's 22nd bit determines if the relative lock-time is time-based or block based. If the bit is 1, the relative lock-time specifies a timespan in units of 512 seconds granularity. If the bit is not set (i.e. it is 0), the relative lock-time specifies a number of blocks. The value of the relative locktime, is then interpreted from the first 16 bits of the <code>nSequence</code>. The below figure shows how nSequence is evaluated.</p>
<p><a href="https://i.sstatic.net/1lyHO.png" rel="noreferrer"><img src="https://i.sstatic.net/1lyHO.png" alt="enter image description here" /></a></p>
<h2>Use of nSequence with CHECKSEQUENCEVERIFY (CSV) opcode</h2>
<p>CSV is a script level opcode that is used to lock the spending of a particular output of a transaction until certain blocks/time from when the transaction containing the output was mined. When the user is spending this UTXO in a transaction input, he must set the <code>nSequence</code> value in that input greater than or equal to the CSV parameter. The value in CSV must match the format in the corresponding nSequence value. If CSV is specified in terms of blocks, then so must nSequence.</p>
<h2>Other miscellaneous points</h2>
<ol>
<li>Currently, if <code>nSequence = 0xFFFFFFFF</code>, the sequence number has no effect on the transaction.</li>
<li>If <code>nSequence = 0xFFFFFFFE</code>, then it implies that the transaction uses locktime but does not <code>opt-in replace-by-fee</code>.</li>
<li>Plain vanilla transactions created from Bitcoin Core uses <code>nSequence=0xFFFFFFFE</code>, because they want to use <code>nLocktime</code> to prevent miners from pulling the transactions forward. The <code>nLocktime</code> used in such transaction is set to the last mined block.</li>
</ol>
<p>For more information on Locktime refer <a href="https://bitcoin.stackexchange.com/questions/43067/what-is-bitcoins-locktime-feature-exactly-how-can-it-be-used">here</a>.</p>
<h2>Future potential for nSequence</h2>
<p>As can be seen from the description above, a number of bits in <code>nSequence</code> remain undefined. This allows the possibility to increase its granularity by a soft-fork, or to increase the maximum possible relative lock-time in the future. For example:</p>
<ol>
<li>If <code>nSequence &gt; 0xEFFFFFFF</code> then the remaining 31 bits have no meaning as this condition can be satisfied by just setting bit (1&lt;&lt;31).</li>
<li>If <code>nSequence &lt;= 0xEFFFFFFF</code> then the bits 23 to 30 have no meaning.</li>
<li>Also, only first 16 bits are used to actually encode relative lock-time meaning a further 6 are unused (1 &lt;&lt; 16 through 1 &lt;&lt; 21 inclusive).</li>
</ol>

CC BY-SA 4.0
2019-04-29T16:48:30.530Z
The old nSequence semantics (where non-final transactions were held in the mempool until finalization) were not only a bandwidth issue, but also a memory problem. I believe that was the original reason for removing it, long before the mempool got an actual bounded size.
Pieter Wuille
CC BY-SA 4.0
2019-04-29T17:00:03.730Z
@PieterWuille I always had the opinion that it was to prevent DoS attacks. Earlier, no `minrelayfee` was required and hence that allowed nodes to spam the network at no cost by just incrementing `nSequence`. BIP-125 actually brought the protocol that the fees should be higher than the previously relayed transaction.
Ugam Kamat
CC BY-SA 4.0
2021-06-28T20:16:34.757Z
I think that discussing a relationship between a transaction and an opcode ("CSV is a script level opcode that is used to lock the spending of a particular output of a transaction...") is misleading.  I thought the script has no awareness of transactions, only of the specific UTXO that it's return value, if true/1, unlocks and which therefore makes the transaction to which it's an input valid.  Ben Carman suggested nSequence apply to "at least one" rather than "the first" (input), and I thought "Why not use a bit or two in nSequence to identify what it applies to?"
Dave Scotese
CC BY-SA 4.0
2023-11-01T22:02:57.083Z
@UgamKamat Are you sure about you answer? https://bitcoin.stackexchange.com/questions/120298/what-are-the-correct-threshold-values-of-the-nsequence-in-order-to-activate-re
LeaBit
CC BY-SA 4.0
2019-04-29T11:19:41.580Z
2021-10-20T09:00:30.603Z
2021-10-20T09:00:30.603Z
Ugam Kamat
<p>Following a transaction input:<a href="https://i.sstatic.net/YqFxf.png" rel="noreferrer"><img src="https://i.sstatic.net/YqFxf.png" alt="enter image description here"></a></p>

<p>What is the meaning of the sequence number? What does the 4294967295 tell me?</p>

<transactions><sequence><checksequenceverify><input>
What does the sequence in a transaction input mean?
Michael
# What does the sequence in a transaction input mean?

(Asked by: username_0 on 2019-04-29)

Following a transaction input:[![enter image description here](https://i.sstatic.net/YqFxf.png)](https://i.sstatic.net/YqFxf.png)

What is the meaning of the sequence number? What does the 4294967295 tell me?

**Tags:** transactions, sequence, checksequenceverify, input


---

## 1 answers

### Answer by username_1 on 2019-04-29. Score: 19 | Accepted answer

## Original meaning of nSequence in transactions

`nSequence` is a 4 byte input level feature. The original meaning of `nSequence` was to allow modification of transactions in the mempool. So, if the nSequence value of the input was less than `0xFFFFFFFF` (`4294967295` in decimal), it indicated a transaction that was not yet finalized. Such a transaction would be held in the mempool until it was replaced by another transaction spending the same inputs with a higher nSequence value. Once a transaction was received whose inputs had an nSequence value of `0xFFFFFFFF` it would be considered finalized and mined.

In that implementation, replacement transactions did not have to pay additional fees, so there was no direct incentive for miners to include the replacement. Also, no built-in rate limiting prevented overuse of relay node bandwidth. Hence, this [feature was disabled later](https://bitcoincore.org/en/faq/optin_rbf/#who-invented-unconfirmed-transaction-replacement-does-it-go-against-the-vision-of-bitcoin) as it was possible for an attacker to use up all the bandwidth among full nodes at only a small cost to themselves, creating a denial-of-service vulnerability. This made it difficult for spenders to adjust their previously sent transactions to deal with unexpected confirmation delays or to perform other useful replacements.

## Opt-in Full Replace-by-Fee Signaling

Then came the [proposal](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) for Opt-in Full Replace-by-Fee Signaling. It considered a transaction to have opted in to allow replacement of itself, if any of its inputs have an nSequence number less than `0xFFFFFFFE`. It also required a higher fee than the previous relayed transaction.

## Absolute and Relative Locktime

Transaction with `nLockTime` is used to prevent the mining of a transaction until a certain date (specified in block no. or time). [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) activation defined the meaning of sequence numbers for transactions with an `nVersion >=2`. `nSequence` was repurposed as a relative locktime. That means it prevents mining of a transaction until the input that the transaction is spending has reached a certain age in blocks or timespan. If `nSequence > 0xEFFFFFFF` then there us no consensus meaning to the sequence number and it can be included in any block under all currently possible circumstances. If `nSequence <= 0xEFFFFFFF`, it implies relative locktime.

If `nSequence <=0xEFFFFFFF`, then the sequence's 22nd bit determines if the relative lock-time is time-based or block based. If the bit is 1, the relative lock-time specifies a timespan in units of 512 seconds granularity. If the bit is not set (i.e. it is 0), the relative lock-time specifies a number of blocks. The value of the relative locktime, is then interpreted from the first 16 bits of the `nSequence`. The below figure shows how nSequence is evaluated.

[![enter image description here](https://i.sstatic.net/1lyHO.png)](https://i.sstatic.net/1lyHO.png)

## Use of nSequence with CHECKSEQUENCEVERIFY (CSV) opcode

CSV is a script level opcode that is used to lock the spending of a particular output of a transaction until certain blocks/time from when the transaction containing the output was mined. When the user is spending this UTXO in a transaction input, he must set the `nSequence` value in that input greater than or equal to the CSV parameter. The value in CSV must match the format in the corresponding nSequence value. If CSV is specified in terms of blocks, then so must nSequence.

## Other miscellaneous points

1. Currently, if `nSequence = 0xFFFFFFFF`, the sequence number has no effect on the transaction.
2. If `nSequence = 0xFFFFFFFE`, then it implies that the transaction uses locktime but does not `opt-in replace-by-fee`.
3. Plain vanilla transactions created from Bitcoin Core uses `nSequence=0xFFFFFFFE`, because they want to use `nLocktime` to prevent miners from pulling the transactions forward. The `nLocktime` used in such transaction is set to the last mined block.

For more information on Locktime refer [here](https://bitcoin.stackexchange.com/questions/43067/what-is-bitcoins-locktime-feature-exactly-how-can-it-be-used).

## Future potential for nSequence

As can be seen from the description above, a number of bits in `nSequence` remain undefined. This allows the possibility to increase its granularity by a soft-fork, or to increase the maximum possible relative lock-time in the future. For example:

1. If `nSequence > 0xEFFFFFFF` then the remaining 31 bits have no meaning as this condition can be satisfied by just setting bit (1<<31).
2. If `nSequence <= 0xEFFFFFFF` then the bits 23 to 30 have no meaning.
3. Also, only first 16 bits are used to actually encode relative lock-time meaning a further 6 are unused (1 << 16 through 1 << 21 inclusive).

> **Comments:**
> **username_2**: The old nSequence semantics (where non-final transactions were held in the mempool until finalization) were not only a bandwidth issue, but also a memory problem. I believe that was the original reason for removing it, long before the mempool got an actual bounded size.  
> **username_1**: @username_2 I always had the opinion that it was to prevent DoS attacks. Earlier, no `minrelayfee` was required and hence that allowed nodes to spam the network at no cost by just incrementing `nSequence`. BIP-125 actually brought the protocol that the fees should be higher than the previously relayed transaction.  
> **username_3**: I think that discussing a relationship between a transaction and an opcode ("CSV is a script level opcode that is used to lock the spending of a particular output of a transaction...") is misleading.  I thought the script has no awareness of transactions, only of the specific UTXO that it's return value, if true/1, unlocks and which therefore makes the transaction to which it's an input valid.  Ben Carman suggested nSequence apply to "at least one" rather than "the first" (input), and I thought "Why not use a bit or two in nSequence to identify what it applies to?"  
> **username_4**: @username_1 Are you sure about you answer? https://bitcoin.stackexchange.com/questions/120298/what-are-the-correct-threshold-values-of-the-nsequence-in-order-to-activate-re  

---

