What does the sequence in a transaction input mean?

Question

Following a transaction input:

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

Answer 1

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

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.

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