What is the logic (if there is) behind linking the nSequence and nLockTime?

Question

The nSequence transaction field was originally intended for a replacement logic, but since it was never well thought out, it was never implemented. However, it has been implemented since the beginning that if the nSequence of all inputs is 0xffffffff, then the nLocktime and the absolute time are not activated. Later, some additional features are added like the relative time lock consensus rule by not setting the 32nd bit and the RBF policy rule by setting the value of some nSequence within a transaction to a value less than 0xffffffff-1.

However, what I don't understand is why nSequence and nLocktime are made to have any relationship at all? If the nSequence was seen to have no original purpose (back in 2009), why wasn't it simply dropped from the transaction or left for some future purpose (as was eventually done through relative time locking and RBF)? Why did they make any connection between nSequence and nLocktime? If you don't want the absolute timelock, then just set it to 0x00000000 and that's it, why would it be disabled by setting all nSequences to 0xffffffff. I can not understand. Is there any logical reason behind linking these two?

Answer 1

While the full policy side of the original nSequence replacement idea was never implemented, it does appear Bitcoin's creator had a design in mind, and the corresponding consensus rules were implemented.

In this design, a transaction had a notion of finality. It appears that the idea was that transactions would be replaceable only up until its locktime is hit, and only as long as its sequence values can increase. So, transactions are final if at least one of these is true:

• Its nLockTime has a height or timestamp in the past.
• All its nSequence values were maximal (because such a transaction would not be replaceable by increasing any nSequence).

The consensus side of this design called for allowing transactions on-chain which are final (for whatever reason), while the policy side of it requires also accepting non-final transaction into the mempool, and permitting replacement there.

This replacement logic in the mempool was never fully implemented, and found impossible to align with incentive compatibility and DoS resistance (by permitting effectively free relay and processing, by continuously replacing transactions). However, the consensus rules exist, and were - for better or worse - never changed. Dropping the "All nSequence values are maximal implies finality" rule would be a hard fork, with little benefit. It seems unlikely that anyone could manage to go through the tremendous effort of getting the ecosystem to agree to a hardfork for an edge case that can be trivially avoided by wallets (by just not setting the nSequence value maximal).