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.