Topic: How does nLockTime work? (ELI5) (Read 350 times)

I'd like to be able to spend funds in the future, just like savings bonds work today. That's why I became interested in Bitcoin's "nLockTime" feature, as it proves to be extremely convenient for leaving Bitcoin to your loved ones as a form of heritage that can only be unlocked at a specified point in time (in this case, after a number of blocks on the Blockchain have passed).

I was not aware that it was possible to modify raw transactions to create a "locked" transaction before. It don't seem that complicated to do, after looking for references online. I believe that it may be possible to do this on other Bitcoin-based forks as well. The only coin where you cannot do this is in Ethereum (please correct me if I'm wrong), but that's okay since ETH is not meant to be used as a store of value. Considering how useful "nLockTime" is, many Bitcoin users could preserve their balance for the foreseeable future even if they're dead. You could simply program the transaction to be able to be unlocked after a certain period of inactivity on a given address, for peace of mind. The possibilities here are endless.

To my surprise, there's no way to do this via a GUI so it makes the process complicated for the non-tech savvy user. If someday devs decide to create a GUI for people to use this feature, I believe that anyone would become aware of it. In the meantime, using commands on "bitcoind" would be the path to take for creating "locked" transactions on the Bitcoin network.

It's worth noting that this property -- while to some extend counter-intuitive -- is exactly what makes nLocktime useful for smart contracts. For example Lightning Network's penalty transactions rely on this feature.

nLockTime isn't really intended to be used by the average user as it isn't all that practical to use in the first place. The feature is still flawed in a sense that the mempool doesn't keep transactions that has an nLocktime. If your inputs are spent anytime before your nLocktime expires, the transaction that you've created would be completely useless. It isn't all that useful unless you want to spend funds in the future and you want to delete your private keys.

You can easily craft a raw transaction in your client and modify the last few bytes to set the nlocktime before sending. Bitcoin Core, by default has an nLocktime for every transaction, where the nLocktime doesn't actually do anything to prevent the transaction from confirming.

nLockTime transactions are really not intended to be used by individual users, and creating a nLockTime transaction does not appear in the documentation for the bitcoin core wallet.

If you are a business that sends many bitcoin transactions, there may be a use case for nLockTime transactions that makes sense. nLockTime transactions are really intended to be used for applications used "on top" of bitcoin, such as Lightning Network wallets, or Thunder wallets.

If you want to show your friends a "real world" nLockTime transaction, you can open a LN channel with yourself (or your friend), send some transactions between the LN nodes so that each node has a "settlement balance" of about half the channel value, and have one node unilaterally close the LN channel in which the other node does not corporate. This will allow you to show your friend nLockTime transactions in use, and will also allow you to highlight the security (and risks) of using LN.

A well-detailed explanation. Thanks a bunch for this, mate. This is so much easier than using the command line to interact with time-locked transactions. I'd wish to know how to do it on the Bitcoin Core wallet too (bitcoind or bitcoin-qt) so that I could use it at a later time in case the Coinb.in website goes down. The "nLockTime" feature is certainly useful for unlocking funds after Xmas, a birthday, or even after death. I became curious about it the moment I saw "PaperSafe" with some BTC certificates which had a locked address with funds on it. It was then, I've decided to look more thoroughly into "nLockTime" to use it for my own benefit.

Anyhow, if you or anyone else knows how to do this also in Bitcoin Core, I'd greatly appreciate some guidance. In the meantime, I'll use this service for creating time-locked transactions for BTC. It's a really useful tool.




Thanks for this great info! I appreciate your help. I can see that it's easy to create time-locked transactions using this online tool. I would've wished to do everything in Bitcoin Core itself, but I guess that it's somewhat hard to achieve. I'll stick with the Coinb.in service in the meantime until I get to know how to perform these kind of transactions on Bitcoin's native wallet itself.

Very important clarification by @pooya87 IMHO

Put it in layman terms:

every transaction has a payer (source) and a payee (destination), and you are in a different use-case depending on who sets the nLockTime

CASE 1)
if nLockTime is set by a payer, he is signing a "post-dated check", meaning he can give the payee the transaction OFFLINE, but the payee cannot send it to the blockchain until the time/number of block specified by nLockTime has elapsed, otherwise it would be rejected.
But, as in real life post-dated checks, the payee has to trust the payer, meaning that nothing prevents the payer to "double-spend" the same input of the nLockTime-ed future transaction in a regular "earlier" transaction

so...

CASE 2)
it's better if the payer DOESN'T set the nLockTime but instead writes the redeem script in favour of the payee using a CheckLockTimeVerify Opcode (OP_CLTV) and then submits the transaction as a regular one... so his input cannot be double-spended anymore, since the transaction is recorded in the blockchain.
But what is the meaning of OP_CLTV?
The OP_CLTV has a time parameter (again time/number of block), and its semantic is: this UTXO can be ONLY used as input of a future transaction HAVING nLockTimeVerify >= of the OP_CLTV time parameter (so, as originally wanted, the payee cannot spend the amount received until the OP_CLTV time -set by the payer- has elapsed, because otherwise his new transaction would be reject due to the nLockTime he HAS to set)


Instead I'm not sure to be confident about nSequence use related to nLockTime @pooya87 ... stated that nSequence's bit 31 is also used to signal Relative Timelocks, if a transaction has nLockTime set but ALL inputs's nSequence with bit 31=0 (aka Relative TimeLocks enabled), is the nLockTime being ignored or Relative & Absolute Timelocks checks are AND-ed? I mean ...does nSequence's bit 31 mean "Absolute Timelocks XOR Relative Timelocks" or "Relative Timelocks on/off"? And if the former is the case, what about when some BUT NOT ALL bits 31=0?

thanks for reading! See ya guys
baro

nLockTime is a different thing than what is mentioned in previous two comments (time locked transactions). nLockTime  is the last 4 bytes of every transaction which is interpreted either as a block height or a datatime in unix timestamp format.
the way it works is that each input (txin) is  checked and if they had a sequence (last 4 bytes of each txin) that was not 0xffffffff then nLockTime is checked. for example if current block was 600000 and nLockTime  was set to 600000 or anything below that then the transaction will be relayed and could be included in any block that is found from now on. but if the nLockTime was set to 600010 then it won't be relayed or mined until 10 more blocks are found.

in simple terms the difference is that with nLockTime you already have a signed transaction that is spending any type of input but can or can not be included in new blocks depending on its last 4 bytes so you can do it with any input.
but timelocks use OP codes and the input has to be "locked" so they only work with specific input types that have a OP_CheckLocktimeVerify command in them.

It's a feature that when specified with a date (using Epoch Converter) or block height (the block number of a future block),
that transaction wont be mined and/or will be rejected by most nodes by default until that time/block has passed.

For normal transactions: it's just 0 or the current block height.

I believe that uses a CLTV script to make a "time-locked address", not totally just nLocktime.
@Abiky It makes the outputs (received bitcoins) unspendable until the specified date/block, it's more useful than just nLockTime parameter and fits perfectly to your usage description in the OP.

It was discussed here before you can check it from here How to send a transaction at a specific time?

You can follow the guide from posted above with coinb.in until step 5 and then sign the transaction in the Bitcoin core wallet.

To sign the generated hex from coinb.in to Bitcoin core you can use this command to console.

Hexstring should be the hex generated from coinb.in

There is an easy way to do that, which I already explained in another thread:

(not with Core, though)

I've been doing some digging on Bitcoin's "nLockTime" feature which allows anyone to "lock" BTC funds on the Blockchain for a specified time frame. This could prove to be useful for preserving BTC as a form of heritage, where funds will only be unlocked if a certain date (or condition) has passed. I've found some info about it on the official Bitcoin wiki site here. Most of the information is too technical which proves to be quite difficult to understand for the non-tech savvy user. Of course, I was able to understand most of it, but my friends who are not quite fond with Blockchain terminology have found out it to be quite complicated to understand.

What I want to know is how does the nLockTime feature on the BTC blockchain work in layman's terms (ELI5)? This way, I'll be able to clear some of my doubts to properly educate my non-tech savvy friends about it. Additionally, I'd like to ask how to do this with the Bitcoin Core wallet? I've been looking around the web, but have been unable to find a tutorial or guide that would walk me through on setting a BTC transaction that would be unlocked at a certain point in time.

Any help, suggestions or recommendations will be greatly appreciated. Thanks in advance.