3

Following a transaction input:enter image description here

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

7

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.

enter image description here

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 remain undefined. This allows the possibility to increase granularity by soft-fork, or for increasing 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).
  • 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. – Pieter Wuille Apr 29 at 16:48
  • @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 Apr 29 at 17:00

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.