Topic: Bitcoin users or miners - who is behind(initiates) a bitcoin Locktime? - page 2. (Read 499 times)

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.

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

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.

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.

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.

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.

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.

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

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.

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.