#39 - nLockTime and nSequence

Article
steffenkd

1 month ago by steffenkd

I just remembered, that all forks of the bitcoin protocol are operating at different block heights.
It triggered the nLockTime subject so I did some reading.

The nLockTime is not necessarily about “time”. It can be set to “unix-time”, but in addition it can be set to “block height” as well.
It is kinda similar, but still different, keeping in mind that the “difficult-adjusting-algorithm” has a standard-deviation and can be “tricked and cheated on” to some degree.

I wrote this as a draft on 11.11.2021 and just finished it, so the block heights are off and I do not want to recalculate. However, my point is the time differences between the different chains/forks, which probably hasn’t changed more than an additional hour, therefore it is neglectable when talking about days.

Here is the difference in time vs. block-height between BTC, BSV and BCH (

BTC = +00= +00 days –> 709283 blocks * 10 min = 7092830 min / 60 min = 118214 h / 24 h = 4926 d / 365 d ~ 13.50 y

BSV = +00+26= +26 days –> 713085 blocks * 10 min= 7130850 min / 60 min = 118848 h / 24 h = 4952 d / 365 d ~ 13.57 y

BCH = +00+26+4= +30 days –> 713662 blocks * 10 min = 7136620 min / 60 min = 118943 h / 24 h = 4956 d / 365 d ~ 13.58 y

BSV is 26 days ahead of BTC. BCH is 4 days ahead of BSV and 30 days ahead of BTC.

So the important element is, that BTC is almost one month behind the other two chains. This means, nLockTime is one month behind if used with block-height parameter and if BTC wouldn’t have deactivated it by default.
If unix-time parameter was used, nLockTime should be about the same for all Chains +-10 minutes difference due to 10 minute-blocktime.

Some ideas which came to mind:

  • When using block-height for nLockTime you actually can’t really set a time in the future. You have to calculate and settle for a rough estimation, based on the blocktime which is adjusted to around 10 min per block. This means, the further in the future your nLockTime, the higher the “time-error”, due to the difficulty-adjustment-algorithm and its implied deviations in block-time.

  • If you speed-mine blocks on a chain you should be able to kinda like pre-unlock a nLockTimed-TX when locked with block-height parameters. Probably not really a thing though.

  • The opposite scenario would be, if the hashrate suddenly drops really low at the beginning of a new “two weeks difficulty adjustment period”, or it drops slowly over a longer period of time. In both scenarios, your “calculated unlock time” will be way off. Unix-time would be way more accurate.

  • nLockTime-transactions can be “overwritten” as well. I understand it kinda like the “replaced by fee” situation, but with a “command” called “nSequence”.
    If a TX’s nSequence is updated to 0xFFFFFFFF it will be finalised and moved into the main mempool. It only is included though, when nLockTime is met as well.

So why use the block-height instead of unix-time? It would add some randomnes, but so far that is the only use case I could come up with.