Who really drives Bitcoin Locktime users or miners?

Bitcoin just keeps getting more intriguing with all the new terms popping up. Some of them are pretty straightforward, but others leave me scratching my head. Recently, I stumbled upon this term called Bitcoin Locktime or Time lock. I wasn’t really sure what it meant, so I had to dig a bit. So, Bitcoin Locktime is a feature that stops a transaction from being mined until a certain block or time is hit. I found myself wondering, why would anyone want to do that? Apparently, Satoshi put Locktime into the Bitcoin protocol, but it seems like it never gets the attention it deserves. I mean, I haven't really seen it discussed much anywhere. I’m a bit lost on where these transactions even sit. It wouldn’t make sense for them to hang out in the mempool like other transactions waiting for validation. The whole Locktime concept is pretty baffling to me. Like, how can a transaction set for a specific block actually get approved and show up in that same block when miners are the ones choosing the transactions to include? From what I’ve gathered here, a Bitcoin transaction needs a user to kick it off before it goes into the mempool, waiting for a miner to pick it up, validate it, and add it to the Blockchain. If every user wants their transaction to go through instantly, Locktime really doesn’t seem that useful. But hey, maybe Satoshi had a reason for it.

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

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 Transaction LockTime LockTime parameter 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.   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 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

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