Strange Timestamp Argument

[pooya87]

Is there a theoretical most distant future locktime that a transaction can have?

Block height 499,999,999 or if time is used a time equal to Sun Feb 07 2106 06:28:15.

I imagine the fee would have to be quite large for miners to want to keep it in the mempool for that amount of time, and then it might become a race to see who could publish it the soonest after the benchmarked time.

That would be their choice to keep a non-mineable transaction until becomes mineable. They usually don't waste their memory and stick to the standard rule and reject transactions that have a far away locktime.

[BlackHatCoiner]

If nLocktime is time based it is not based on the current time, it is based on the blockchain's median time past.

I read in our wiki that the median time past is based on the last eleven blocks. Is there any specific reason the developers chose this or is it arbitrary?

Block height 499,999,999 or if time is used a time equal to Sun Feb 07 2106 06:28:15.

Are you sure about that date? Did you possibly mean something like the year 6836 instead?

[pooya87]

Are you sure about that date? Did you possibly mean something like the year 6836 instead?

These are Epoch Unix timestamps and when you convert the maximum possible value for a locktime to datetime you get the exact time I posted above. The locktime variable is a 32-bit unsigned integer so it can be as big as 0xffffffff which is equal to 4294967295. An example online tool for conversion: https://www.unixtimestamp.com/

[ranochigo]

I read in our wiki that the median time past is based on the last eleven blocks. Is there any specific reason the developers chose this or is it arbitrary?

See the BIP that I referenced a few post prior. Using the MTP allows for a strictly increasing block time which is more accurate than just using the block's timestamp to check if the nlocktime transaction can be included in the block.

When a unix time is specified, we used to determine it by comparing directly to the block timestamp, which really isn't as accurate as the one that we've implemented now.

[BlackHatCoiner]

These are Epoch Unix timestamps and when you convert the maximum possible value for a locktime to datetime you get the exact time I posted above. The locktime variable is a 32-bit unsigned integer so it can be as big as 0xffffffff which is equal to 4294967295. An example online tool for conversion: https://www.unixtimestamp.com/

But, why did you say block height 499,999,999 if the 32-bit limit will be reached far earlier than that? Besides, that shouldn't be a concern. A soft fork could be desired anytime where it replaces the 32-bit variable with a 64-bit one.

When a unix time is specified, we used to determine it by comparing directly to the block timestamp, which really isn't as accurate as the one that we've implemented now.

I read it. Okay, so the point for this accuracy improvement is to prevent any miner from claiming more transaction fees by lying their block timestamp.

[pooya87]

But, why did you say block height 499,999,999 if the 32-bit limit will be reached far earlier than that?

Because there are 2 ways to set the locktime value. If that integer value is smaller than (and not equal to) 500,000,000 it will be interpreted as a block height so the maximum height value of a locktime is 499,999,999; and if it is bigger than or equal to 500,000,000 it will be interpreted as datetime so maximum datetime value of a locktime is Feb 07 2106 06:28:15.

[kaggie]

When a unix time is specified, we used to determine it by comparing directly to the block timestamp, which really isn't as accurate as the one that we've implemented now.

I read it. Okay, so the point for this accuracy improvement is to prevent any miner from claiming more transaction fees by lying their block timestamp.

There are two safe guards though:

1) The blockchain has a time stamp that the processed transactions must adhere to, within the previous 11 blocks. So lying about timestamps is limited to that.

2) Most users will want to have their transactions processed sooner rather than later. If a miner wants to process transactions faster, then this will typically not be an issue.
The number of users who want delayed processing will be so low to make this effect insignificant.

-
Do miners check that confirmed transactions from other miners have waited a sufficient nlocktime for a transaction? They must do...
If not, then I still don't fully understand what prevents a miner from processing delayed transactions early, since the signed transaction has all information viewable at any stage and delayed locktime information isn't relayed downstream, as far as I understand. It's mostly related to the honesty of the miners, isn't it? It's not really a concern, since the number of people desiring such a method would be minimal.

[ranochigo]

Do miners check that confirmed transactions from other miners have waited a sufficient nlocktime for a transaction? They must do...

Nodes do.

If not, then I still don't fully understand what prevents a miner from processing delayed transactions early, since the signed transaction has all information viewable at any stage and a delayed locktime isn't relayed downstream, as far as I understand. It's mostly related to the honesty of the miners, isn't it? It's not really a concern, since the number of people desiring such a method would be minimal.

Each node will check the transactions within a block such that they have to be final with respect to the MTP of the past 11 blocks. Miners can include non-final transactions, but it would just result in the block being considered invalid to the rest of the network.