Bitcoin users or miners - who is behind(initiates) a bitcoin Locktime?

[Felicity_Tide]

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.

[NotATether]

1. who initiates the Locktime on transactions? - miners or Bitcoin users(the performer of transaction).

Locktime is specified by the user at the very end of the raw transaction. See this page 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.

2. where are these locked transactions stored before the stated time or block of approval is reached?.

In the mempool with all the other transactions.

3. Is there any benefit of using Locktime for our transactions?.

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

4. What was Satoshi's reason of implementing this ?(share if you have a clue).

Satoshi actually disabled this feature very early, but it was added back in BIP 68.

[promise444c5]

Locktime is specified by the user at the very end of the raw transaction. See this page 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.

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 ??

[Charles-Tim]

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.

[NotATether]

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 ??

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.

[d5000]

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?.

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.

[Catenaccio]

1. who initiates the Locktime on transactions? - miners or Bitcoin users(the performer of transaction).

3. Is there any benefit of using Locktime for our transactions?.

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

Using Locktime for inheritance planning, backups or gifts
Transaction LockTime

Locktime, also known as nLockTime from the variable name used in the reference client, defines the earliest time that a transaction is valid and can be relayed on the network or added to the blockchain. It is set to zero in most transactions to indicate immediate propagation and execution. If locktime is nonzero and below 500 million, it is interpreted as a block height, meaning the transaction is not valid and is not relayed or included in the blockchain prior to the specified block height. If it is above 500 million, it is interpreted as a Unix Epoch timestamp (seconds since Jan-1-1970) and the transaction is not valid prior to the specified time. Transactions with locktime specifying a future block or time must be held by the originating system and transmitted to the bitcoin network only after they become valid. The use of locktime is equivalent to postdating a paper check.

LockTime parameter by default is 0, but it can be set to somewhere from 0 - 500,000, no more than 500,000,000.

[odolvlobo]

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.

[vjudeu]

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".

[Felicity_Tide]

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.

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.

[pooya87]

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.

[larry_vw_1955]

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.  

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.

[pooya87]

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. 

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.

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.

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.

[nc50lc]

2. where are these locked transactions stored before the stated time or block of approval is reached?.

In the mempool with all the other transactions.

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

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
Example use-case: coinb.in/#newTimeLocked

[vjudeu]

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.

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/

[nc50lc]

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.

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).

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.

[vjudeu]

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".

[larry_vw_1955]

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.

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

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.

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.

[vjudeu]

how much wiggle room is there?

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

11-block median time past (the median timestamp of the 11 blocks preceding the block in which the transaction is mined)

that doesn't sound like a good thing.

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:

Code:

// "Never go to sea with two chronometers; take one or three."
// Our three chronometers are:
//  - System clock
//  - Median of other server's clocks
//  - NTP servers
//
// note: NTP isn't implemented yet, so until then we just use the median
//  of other nodes clocks to correct ours.

Edit:

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?

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).

that way you get alot more use out nlocktime than 9500 years. and it works past the year 2106...

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.

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

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?

[larry_vw_1955]

It is far from perfect, ...

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

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.

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? 

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.

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.