What are nSequence?

The nSequence opcode is a system that allows time locks in Bitcoin. It helps us to program certain conditions in the transactions that must be fulfilled first, so that this transaction can be accepted on the network permanently. An enormous programming power that Bitcoin offers us for a large number of use cases.

Unot of time locks or TimeLock more particular of Bitcoin es nSequence. This is a relative time lock that operates at the transaction level and that allows the use of the input sequence numbers to program a time lock in the Bitcoin transactions.

NSequences allow an entry to specify the earliest time that it can be added to a block. That is, they avoid the confirmation of a transaction until a certain age has elapsed in the outputs of the transaction. This age can be measured in confirmed blocks or in elapsed time.

Likewise, nSequences allow the creation and programming of multiple time conditions on the same Bitcoin transaction using Bitcoin script. Which, despite being different, will be related to each other, so they must be fully complied with so that the transaction can be validated and included in a block of the blockchain. In the event that all the established conditions are not met, the transaction simply cannot be validated. Therefore, this transaction will be rejected by the network.

How do nSequence work?

The nSequence they use only 18 bits of the 32 bits available in the sequence field of each transaction. This keeps the remaining 14 bits in reserve for future implementations. So the nSequence are one of the lightest time locks in the Bitcoin network.

Likewise, of the 18 bits they use, 16 bits are used to configure the blocking times. This makes these time locks limited to a total of 65.535 available block units. Or at a time of 18 hours, which is equivalent to 64.800 seconds.

So, although nSequence were originally implemented to allow the modification of transactions within the bitcoin mempool. And they allowed the replacement of a transaction before it was finalized or confirmed. That is to say, they are currently used as a relative blocking time. This prevents a transaction from being withdrawn until the established conditions are reached. These conditions can be a defined time interval or a block height. This applies even when your digital signatures are completely valid.

In such a case, if the value of nSequence is greater than 0xEFFFFFFF, there is no consensus on the sequence number, so the transaction can be included in any block with all possible circumstances. Whereas if the value of nSequence is less than or equal to 0xEFFFFFFF, then it means that there is a blocking time. Where bit number 22 of the sequence determines if the block is based on a time interval or the block height.

If this bit has the value of “1”, then the blocking time is based on a time interval; while if its value is not established it is considered as “0” and refers to a number or block height.

Commissioning of the nSequence: activation of BIP 68

El 68 BIP which is called "Relative lockout time using consensus-imposed sequence numbers" This gave a new concept and definition to the sequence numbers for Bitcoin transactions with a version greater than or equal to "2". Allowing these sequence numbers to be reused for new use cases. As well as for future implementations without breaking its functionality.

Likewise, in the 68 BIP it is defined that the time interval is measured starting with the median of the past time (MTP) of the previous block to the exit and ending with the median of the past time (MTP) of the previous block. The Median Past Time (MTP) is defined in the 113 BIP, which specifies the MTP as the endpoint for blocking time calculations.

Interpreting an nSequence

The interpretation of the blocking time is done by counting the bits starting from bit number 16 in the nSequence sequence.

On the other hand, when the blocking time is based on a time interval, then the blocking is developed as a minimum limitation to the block time on the age of the entry. Whereas if the blocking time is based on blocks, this is interpreted as a minimum limitation to the height of the block on the age of the entry.

In the first case, a nSequence based on a time "n" can be included in any of the blocks that are produced 512 * n seconds after the extraction date of the spent output or the MTP of the previous block that extracted it. For time-based time locks, a 512-second scale was chosen since Bitcoin blocks are produced every 10 minutes, which is equivalent to 600 seconds. This allows the same amount of time to be encoded with the number of bits available in both cases. Whether when using block-based time locks or when using time-interval-based time locks.

For the second case, where the blocking time is based on blocks, the nSequence indicates an entry that can be included after "n" number of blocks after the extraction date of the spent output or any block after it.

NSequence implementations

CHECKSEQUENCEVERIFY time lock

The nSequence relative time lock can be implemented in the code OP_CHECKSEQUENCESSEVERIFY. This code allows you to block spending on a specific exit of a transaction. This until certain conditions are met. How to reach certain blocks or a defined time interval from the extraction of the transaction that contains said output.

In this case, when a user uses and spends the UTXOs on a transaction entry, the value of nSequence on that entry must be set to be greater than or equal to the parameter set in CHECKSEQUENCEVERIFY. As well as the format of the nSequence value must match the value of CHECKSEQUENCEVERIFY. In other words, if CHECKSEQUENCEVERIFY is specified in terms of blocks, the value of nSequence must also be block-based.

colored coins

All the colored coins They are an identification method that allows representing and recognizing certain real-world assets on the Bitcoin blockchain. In order to avoid manipulations and counterfeits that these assets may suffer, they take advantage of the properties and characteristics that blockchain technology offers for their protection and safeguard.

Although currently it has lost much popularity with the birth of Ethereum and ERC-20 tokens, these types of transactions that are created in the Bitcoin blockchain are marked in such a way that they can be distinguished from the rest of the transactions that occur within the Bitcoin blockchain. For which a label value is used in the nSequence field of the first entry of the transaction. And although nSequence is always present in transactions, in this case it is not used as a lock but as an identifier, using 6 of its bits to form and encode the tag value.

Decker-Wattenhofer payment channels

The payment channels Duplexes are first described in the papers of Christian Decker and Roger Wattenhofer. This type of payment channel requires the use of nSequence. As the name implies, a duplex payment channel is made up of two one-way payment channels, one in both directions.

These channels use a structure called an "invalidation tree" of off-chain transactions. A property between the financing transaction and the payment channel completion transactions. Invalidation tree transactions also use the relative lock time; the first version of the transaction has a large relative lock time. And the next version of the transaction (which invalidates the first one) uses a slightly lower relative lock time, and so on. There is also a "start" transaction that starts the timeout for the relative lock time.

The sequence of transactions is like this:

Financing -> Home -> Invalidation tree -> Payment channel.

Thanks to this, it is possible to create secure payment channels with an operation similar to that offered by the Lightning Network, although technically more complex in their operation.