Bitcoin Forum

Bitcoin keeps getting interesting as I keep coming across so many new terminologies. some of these terminologies sounds very easy to process, while others raise heavy question. I recently came across what the Bitcoin community call Bitcoin Locktime/Time lock. Not so sure of what it was, but had to find out.

Bitcoin Locktime turns out to be a way of preventing a transaction from been mined till a specified block or time is reached. why on earth would anyone wants to do that?, I asked myself. it also turns out that Satoshi implemented the Bitcoin Locktime as part of Bitcoin protocol, but why is Locktime not thoroughly discussed? (like I haven't seen it anywhere before).

Am not even sure of where these transactions are stored, because it won't make any sense if they are in the mempool alongside other transactions that are waiting for validation. The entire principle of Bitcoin Locktime is really confusing, because I wonder how a transaction specified to a particular block would be approved and placed in same block of specification, when miners are actually the ones picking up  particular transaction and placing it in a particular block.

From what I have learnt so far from this forum, Bitcoin transaction requires a Bitcoin users that would initiate the transaction, before moving it to the mempool where it awaits a miner to pick it up and perform a validation in a block before adding it to the Blockchain. if every Bitcoin user wants their transaction to be approved at that instant, then Bitcoin Locktime might not be of great importance in that aspect, but I guess Satoshi knows best.

So here are my questions surrounding Locktime transactions, and I would appreciate links to topics that discusses this in details.

My Questions:
1. who initiates the Locktime on transactions? - miners or Bitcoin users(the performer of transaction).
2. where are these locked transactions stored before the stated time or block of approval is reached?.
3. Is there any benefit of using Locktime for our transactions?.
4. What was Satoshi's reason of implementing this ?(share if you have a clue).

---

I am 100% open to correction as I still see myself as a learner. Pardon any of my error and share your personal opinion. You might want to also DOYR after reading this.

Locktime is specified by the user at the very end of the raw transaction. See this page (https://learnmeabitcoin.com/technical/transaction/locktime/) for more details. Note that at least one of the inputs have to be locked for the transaction to also be locked - just setting the locktime is not enough, you also have to set the sequence value at the end of at least one of the inputs to 0xfffffffe or below to "enable the locktime functionality to be used".

The nsequence value doesn't actually lock anything, it is just a control variable to signal that the software that made the transaction knows about (supports) RBF, locktime, etc.


In the mempool with all the other transactions.


They can be used for inheritance planning among other things - some forum members have also discussed this.


Satoshi actually disabled this feature very early, but it was added back in BIP 68 (https://github.com/bitcoin/bips/blob/85cda4e225b4d5fd7aff403f69d827f23f6afbbc/bip-0068.mediawiki).

Not OP but need to ask this, if the lock time block or time hasn't been reached and there's a need for change in the setted value ( block or time)  can it be undone or once its setted it cannot be undone again...
If not.. what about the relative lock time ??

You mean if you can cancel the transaction before the date or height is reached? Yes you can cancel the transaction. After you cancel the transaction, you can make another locktime transaction.

But to edit the data like change the amount of bitcoin, that is not possible. You can just cancel the transaction and make the correction with your new transaction.

So what you need to know is that there is two types of lock time you can set - time-based lock time and height-based lock time. Where a transaction cannot be mined until a certain time in UTC or block height has been reached respectively. And one or the other is used depending on the value of the locktime. If it is very low - block height, otherwise if it is very high - UTC time.

A locktime only prevents a transaction from being mined before a certain time (or height). You can still replace it with RBF as long as the nsequence values of the inputs you want to change are 0xfffffffd or below. But I guess that is no longer relevant with the emergence of mempoolrullrbf.

The answer to your second question depends on what you are doing with the transaction.

I'll explain this with the probably easiest use case: a gift for a child to be used when the child gets 18 year old. You create a transaction setting the Locktime date to the child's 18th birthday. So they will be able to access the coins this day.

But what to do now with this transaction? Nodes will normally not store a transaction in their mempool if the Locktime is set too far in the future.

The answer is actually, in the case of long locktime values: it should be stored on a device controlled by the potential beneficiary of the transaction. Ideally it should be stored in a file to prevent the mempool from losing it. Once the Locktime date has passed, the beneficiary can load this transaction into their Bitcoin node or wallet and broadcast it.

Inheritance planning, the other main use case, is a bit more complex. The problem is that you don't know when you will pass away. What you can actually do is to create a Locktime transaction with a date set 1 year in the future, and giving it to your heir(s). If you're still alive after one year, you move the coins to another address or and create a new Locktime transaction again 1 year in the future, transmitting it to your heirs. And so on until your time has come ...

There may be other use cases with shorter locktimes, where it will be better to store the transaction in the mempool.

LockTime is set by a Bitcoin user and it can be used for inheritance.

Using Locktime for inheritance planning, backups or gifts (https://bitcointalk.org/index.php?topic=5180850.0)
Transaction LockTime (https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch05.html)

LockTime parameter (https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06_transactions.adoc#lock-time) by default is 0, but it can be set to somewhere from 0 - 500,000, no more than 500,000,000.

Using nLockTime is like post-dating a check. It prevents a transaction from being confirmed before a specific time. You might give someone a signed transaction with nLockTime set to ensure that something else can happen before the transaction becomes valid.

Some wallets set nLockTime to the current height in order to prevent miners from arbitrarily re-orging the chain. I don't have a complete understanding of this use, so feel free to clarify.

Imagine that the basic block reward is very low, and the coinbase transaction is made out of transaction fees, and not much more than that. Then, Alice creates a transaction in block 1,234,567, with some huge fee, which is confirmed in this block. Imagine that the block 1,234,566 could be reorged, and include Alice's transaction. If that would be the case, then miners could just take the most profitable transactions, from a range of some blocks (for example from the last five blocks), and it could be profitable, to reorg all of those blocks, and to mine for example a block 1,234,563, with the highest possible transaction fees.

So, locking the transaction to the current height simply means, that if Alice's transaction has to appear in block 1,234,567, and cannot be included earlier, then it is no longer possible, to take the most expensive transactions, and just mine some block at the same height, by replacing it over and over again, with some tasty fees, and throwing away other transactions (which will also raise fees, if mempools will start filling up).

Some extreme example: all transactions have locktime zero, and miners could simply mine the same block over and over again, without moving the chain forward. And then, they can wait ad infinitum for bigger and bigger fees. But if you have locktime, then you may say "you will get those fees, but only if you work on some next block, and push the chain forward".

So does this mean that only one of them (time-based lock time or height-based lock time) can be done for a single transaction at a time.

There is only one nLocktime and that single value can only represent one thing, either a datetime value (if bigger than the threshold) or a block height (if smaller than the threshold). That threshold is 500,000,000.

i can understand how everyone could agree on a block height but how does the network come to consensus about a datetime? that doesn't make any sense. there is no consensus mechanism for everyone agreeing on the time. not on bitcoin. so i think this nLocktime feature is suspect.  :o

there should be 2 separate locktimes. one for datetime and one for block height but mixing the two and having a threshhold where one stops and the other kicks in, it's like you're saying after that point you can't use blockheight for specifying a locktime. ridiculous.

There is a mechanism. It is through the timestamp inside block headers. The result has some "wiggle room", since it is not an accurate time.

In each tx we only have 4 bytes to work with as locktime, so we evaluate those 4 bytes like what I explained above. The space is large enough to cover everything.
Think about those values:

• Any value from 0 to 500,000,000 is interpreted as a block height. We don't really need any more since after 15 years we are still at 850k blocks and it would take ~9500 years to get to 500 mil blocks so it covers everything we need.
• Any value from 500,000,000 to 4,294,967,295 (0xffffffff) is interpreted as datetime. As epoch, that value is between 1985 and 2106 which covers all datetime values we need.

Let me add a clarification regarding this for OP.

Transactions with nLocktime field set to future dates/block will be rejected by nodes as "non-final", so it wont make it in any node's mempool that enforce that rule.
so it'll either stay in the wallet locally (not broadcasted); or in text, digital or paper.
Ref: github.com/bitcoin/bitcoin/blob/538363738e9e30813cf3e76ca4f71c1aaff349e7/src/validation.cpp#L797-L802 (http://github.com/bitcoin/bitcoin/blob/538363738e9e30813cf3e76ca4f71c1aaff349e7/src/validation.cpp#L797-L802)

NotATether must be referring to scripts with CheckLocktimeVerify (OP_CLTV) that prohibits the UTXO to be spent until the set expiration date/block in the script.
In this case, locked UTXO can be included to mempools then the blockchain once "mined" but can't be spent until the right condition is fulfilled.
OP_CLTV (BIP-65): github.com/bitcoin/bips/blob/master/bip-0065.mediawiki (http://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki)
Example use-case: coinb.in/#newTimeLocked (http://coinb.in/#newTimeLocked)

This is almost true. Almost, because it is the case for those, who use Bitcoin Core. But there are sites, which can accept timelocked transactions for some reason, hold them for a few hours, and then drop, when it will stay unconfirmed (and yes, for those few hours, they may even show, that there is 35% chance for transaction inclusion, even if the real chance is 0%, because of the locktime).

Some example of such website: https://live.blockcypher.com/btc-testnet/pushtx/

Great, then some of Blockcypher's nodes don't belong to those nodes "that enforce that rule".

I generalized the first part because it's pretty much mandatory to protect the owner's node due to it being a DDOS attack vector.
Plus, I'm not aware of any implementation that accept such transaction to their mempool, some niche or personal Bitcoin client maybe.

There are some corner cases, where you may want to keep some transaction, even if some locktime is still active. For example: if you have a timelock, set to some block 1,234,567. Then, the block 1,234,567 is reorged, and miners are working on that block again. And then, some transaction had one confirmation, but now has zero. However, we are no longer on that height, to get this transaction included in the next block, but maybe after two or three blocks, it should be added. Then, if you throw it away, then there is a risk, that it will be simply dropped and ignored, if enough nodes will behave in the same way.

To sum up: if you can see a lot of timelocked transactions, and there is some chain reorganization ongoing, then there is a room to simply drop some transactions as "non-final".

how much wiggle room is there? that doesn't sound like a good thing.

does that seem like an ideal solution or does that seem like shoehorning two totally separate ways of locking a transaction into the same field? think about it. just add an extra 4 bytes and have one set of bytes for block height and the other set for datetime. that way you get alot more use out nlocktime than 9500 years. and it works past the year 2106... 

having those 4 bytes perform separate things with different meanings is just an example of poor design.

https://en.bitcoin.it/wiki/NLockTime

1. The time always moves forward in the long term. It has to be strictly greater than MTP, which means, that you cannot start from the Genesis Block in 2009, and get a valid block in 2005.
2. For miners, it is profitable to move the time forward. Especially in testnet, where by moving it 20 minutes to the future, you can work with the minimal difficulty. But also in mainnet, if you have more time between blocks, then the difficulty is decreased.
3. Blocks are accepted up to two hours in the future. However, it can be changed locally in the node settings. And as always: you can work on future blocks, but if you work very far in the future (more than two hours), then there is a huge risk of getting your blocks reorged (because they are rejected by other nodes, until their clock will get there, and your blocks will be in this two hours window).
4. If you have some decentralized clock, then there is no one source of truth. Actually, we have three, which means, that having some "wiggle room" is a good thing. As Satoshi wrote in version 0.1.0:


Edit: It is far from perfect, but it was better to have any format, than to have no format at all. And also, it shows that Satoshi tried to compress things, as much as he could. For that reason, we have VarInt. For the same reason, we have compressed 256-bit target into 32-bit value. If Satoshi would know about compressed public keys, then we could also have them from the start. But because he didn't know about it, he applied SHA-256 and RIPEMD-160, to get 160-bit addresses, because 256-bit and 512-bit ones were too big.

So, is it possible to have two separate locktimes, one for block numbers, and one for timestamps? Yes, of course. But: Satoshi wanted to make it small. And I guess it could be even smaller, like "skip the last four bytes, if there is no locktime", but we cannot have that now, because locktime is signed (even if you use SIGHASH_NONE | SIGHASH_ANYONECANPAY).

1. Do you need bigger timespan than 136 years, with accuracy up to one second?
2. It is possible to re-activate locktime in the future, by treating it like (time64 % 2^32). It is a soft-fork.
3. It is more likely, that the time in the block header will be also expressed as something like (time64 % 2^32) in the future. Because if you switch from 80-byte block headers into for example 84-byte block headers, then it will be ASIC-incompatible.

1. You can separate them in your implementation, and add back-and-forth conversion, without touching any consensus rules. It would be a no-fork, not even a soft-fork, if you want to change it locally.
2. It is not a "poor design". It is just some kind of compression. And also tell me: if block numbers wouldn't be there, then would you really need to put locktime between 1970 and 1985, with accuracy to a single second?

oh i already know that. i'm glad you agree.

small and hard to understand and work with and possible unintended consequences if things don't get fixed for that year 2106 bug. is that going to be a bug or what are people going to do?  :o


satoshi must have been a linux hacker. its a hack. that's all it is and not even a very elegant one. and yet, it requires all these possible fixes you mentioned just so it can keep working past 2106 what a disaster of an opcode.

Why? What's the benefit of increasing the transaction size by a fixed 4 byte and wasting the block space for something that can be done already using the current method?

Think about that number a little bit. 9500 YEARS. Bitcoin is probably an ancient history after 100 years just like fire that cavemen built thousands of years ago. In 9500 years people may not even remember something called Bitcoin ever existed.
So I ask again what's the benefit of adding an extra 4 bytes that is never going to be used?

There are a lot of things in the protocol that won't work way before 2106 like SHA256 and ECDSA using secp256k1 curve. For example this last part according to SEC 1 v2 the 256 bit curve is only secure until 2040 (B.2.1 page 73, table 3).

Adding a single "if" in some already working implementation is much easier, than introducing some completely separate field in your data structure, update it in all serialization methods, not forget about constructors and destructors (if any), and so on.

Satoshi did the simplest thing he could. He just called some functions from the standard library or WinAPI, without thinking about "2106 year problem" or "2038 year problem". In the same way, people use "int" as their data type, without thinking if it is "int32", "int64", or maybe "uint32". In that case, Satoshi was aware enough to use unsigned integers, and to specify the size of those fields in most cases, but he was not aware enough, to do the same with time-based data types, like "time_t".

Definitely not. He used Windows, and there are some traces, leading to the conclusion, that he was running Windows on a real hardware, without any virtualization (because in that case, it would affect his mining performance, and some other things). Even if you assume, that he privately used some kind of Linux, then definitely he had at least one physical machine, with Japanese version of Windows XP, without any VirtualBox, and used that for development.

At that time, people didn't think about soft-forks and hard-forks, as we do it now. There were old times, when people thought, that you can upgrade the whole Script by using OP_VER (which is now disabled). In the same way, people thought, that transaction versions and block versions can be used to fully replace everything. But now, we know, that it is not the case.

There are two different things, which should be clearly separated:

1. nLockTime at the end of transaction
2. OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY inside Script

Also note, that even if we run out of those, and if all locktime values could be used (so nLockTime will become de-facto transaction nonce), then still, adding new opcodes is possible. Also: reusing existing ones is another option. Which means, that after block 500,000,000, and after year 2106, when every locktime value will be valid, we can implement completely different locktime rules from scratch, without any limits.

to segregate two different functionalities.

if that's the case then why are you here? shouldn't you be spending your time on something that is going to last?


I see you have a crystal ball now and are able to somehow see into the future. Interesting...


I should be able to use nlocktime to specify any block height i want to even if it's more than 500 million. that's my stance. i don't see the point in specifying a particular date and time since bitcoin knows nothing about precise times. and blocks are not at exact time intervals so there really is no reason to be using a date and time for a locking mechanism. the software could take your datetime and convert that to an estimated block height internally...

It is as precise, as it can be. The network is decentralized. Which means, that there is no one central clock. And how do you want to agree on the current time, when one node can say "it is 12:08:34", and another node can say "it is 12:08:35". How do you want to determine, who is telling the truth, in a decentralized way?

Also, specifying the date and time works quite well in practice. For example, once I locked a transaction into 17,0000,0000 (https://bitcointalk.org/index.php?topic=5465605.msg62932130#msg62932130). It means "Tue Nov 14 22:13:20 2023 UTC". I broadcasted it at "October 02, 2023, 05:45:54 AM" (forum time), and it was confirmed on "2023-11-15 01:13:58". See? The time of the block was 17,0000,7238, so this transaction was confirmed just two hours after becoming valid.

Because they don't have to be. You know, why blocks are timestamped at all? To determine the next difficulty. If not that, then they could be created without any timestamps. And by knowing that, do you think the difficulty is underestimated or overestimated? Because I think it is quite accurate, which means, that block timestamping works fine, as it is.

There are other ways, if you want to use them. If you really want another kind of locktime, then you can try hash-based locktime: https://gwern.net/self-decrypting

Yeah, and then your transaction could be months away from the time, when you want it to confirm. For example: see the exact times of each and every halving, and compare it with scheduled time.
Currently, we have 2024, and the basic block reward already dropped into 3.125 BTC. See?

What are you talking about? He clearly state the reason and source, which can be found on https://www.secg.org/sec1-v2.pdf (https://www.secg.org/sec1-v2.pdf). And it's common that cryptography only deemed secure for some time. For example, SHA-1 which created on 1995 stopped being used by most company between 2010-2020.


But should the software assume block time is always at 10 minutes? Few years ago, i did quick calculation which shows average block time is only about 9.4 minutes since hashrate/difficulty almost always growing.

So we're supposed to just accept their table without them providing any explanation or justifications? Anyone could make up a table like that just saying "let's make the key sizes get bigger every 10 years or so." Unless they can provide some rigorous argument, lets not state these things as facts just rules of thumb projections which may not turn out to be true.



That doesn't have anything to do with the security of SHA256.


we really don't have a way to measure real world time in bitcoin. blocktimes are based on time stamps from miners what would happen if enough miners just set their clocks to 500 years into the future. well then they could mine transactions whose nLocktime was set using the datetime. some people would be pretty surprised to see that their nLocktime had no affect...

you can't forge blockheight but you can forge a timestamp simple as that. it may not be easy but i think it is possible.

You won't see any blocks, which are further than two hours in the future anyway. They will be mined, they will wait for being broadcasted, but you won't get them in your node. And also, anyone could mine a competing block in the meantime, at the same height. Which means, that if anyone is mining further than two hours in the future, then that miner is taking a huge risk of getting all of that reorged.

If you can forge a timestamp, then you can lower the difficulty as well, and produce more blocks than usual (which means, that you indirectly can fake block height as well).

I never said that, i just wanted to point out @pooya87 use that PDF as reference rather than "have a crystal ball now and are able to somehow see into the future". And while i agree it may not turn out the be true, they attempt to explain it on B.1 page 70 to 72 and B.2.11 page 84 to page 85. Although on 2024, we can see the explanation isn't very good since Moore Law slows down and it doesn't consider quantum computing.


You're right, although i've stated it's just an example how cryptography usually only deemed secure for some time.

They estimated that for about $10 million a machine with 325,000 processors could be built that would solve the ECDLP for an elliptic curve E with n ≈ 2^120 in about 35 days. Hardware attacks on larger values of n, such as n ≈ 2^160, appear impractical at this time. Pelzl [Pel06] estimated in 2006 that the cost of special purpose hardware to solve the ECDLP for n ≈ 2^160 over a prime field is about $6 × 10^11.

it's funny how they later say that computer power is going up by a factor of 2^16 per decade. so it's been almost 2 decades since they made these estimates. that means computing power went up by 2^32.  so that $10 million machine that could solve n=2^120 in 35 days should now be able to handle 2^152 in 35 days. multiply that by 2^8 and it can do 2^160 in less than 10 years. which contradicts their table that says that 128 bit ECC should be secure until 2040.

i think the problem is in their later assumption that computer power increases by a factor of 65536 every 10 years. i don't think that's true. not even close. i think on average it might increase by a factor of 10. but not a factor of 65536.

There is no need to RBF.

Nodes reject any transaction with locktime set in the future.
Therefore, if you have broadcasted a transaction with locktime set in the future, nodes don't have that in their mempools and you can easily broadcast a new transaction using same inputs even with lower fee.