Gfyuki

Following a transaction input:

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

My search on this website did not reveal a single answer that comprehensively explores nSequence and how it has evolved since inception. They either address a particular query or are dated like this. If you can find a better/older answer, mark this question as duplicate.

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

Currently, if nSequence = 0xFFFFFFFF, the sequence number has no effect on the transaction. If nSequence = 0xFFFFFFFE, then it implies that the transaction uses locktime but does not opt-in replace-by-fee. Plain vanilla transactions created from Bitcoin Core uses nSequence=0xFFFFFFFE, because they want to use nLocktime to prevent miners from pulling the transactions forward. For more information on Locktime refer here.