block 915130 mined in the future?

[callmejoe]

anyone notice this weird time stamp for block 915130?

says mined 0 seconds ago or in the future (if that makes sense)

https://imgur.com/a/9iT07eM

[achow101]

The timestamp is set by miners, so it can be in the past or future. It must only be greater than the median timestamp of the last 11 blocks, and less than 2 hours in the future when received by a node. That's a multiple hour range, and variability is expected and normal.

[callmejoe]

The timestamp is set by miners, so it can be in the past or future. It must only be greater than the median timestamp of the last 11 blocks, and less than 2 hours in the future when received by a node. That's a multiple hour range, and variability is expected and normal.

thanks for the reply.  i dont think i ever noticed it happening before.  i would have thought a timestamp could not be variable.

[DannyHamilton]

The timestamp is set by miners, so it can be in the past or future. It must only be greater than the median timestamp of the last 11 blocks, and less than 2 hours in the future when received by a node. That's a multiple hour range, and variability is expected and normal.

thanks for the reply.  i dont think i ever noticed it happening before.  i would have thought a timestamp could not be variable.

With a decentralized system, it's very difficult (impossible?) to enforce an exact timestamp. Once you accept that there will have to be some variability, it's just a matter of deciding how much variability is acceptable. If 1 second is acceptable, then why isn't 2 seconds?  If 2 seconds are acceptable, then why isn't 3?  The actual designed purpose of the timestamp drives the decision on how much is acceptable.

Transactions don't have timestamps. Bitcoin doesn't care when a transaction happens. The entire purpose of the blockchain itself is to declare an ordering of transactions BECAUSE there is no reliable way to determine the time that a transaction happened.  Rather than trying to decide exactly when on a clock a transaction happened, Bitcoin works by declaring the order in which they happened (regardless of time). Per the "rules" of the blockchain-based system, any transaction in a block at a lower block height "happened" earlier than any transaction in a block at a higher block height.

Since the blockchain eliminates the need to know the clock-time when a transaction happened, the sole use for the block "timestamp" is to compute what the average time between blocks was during the previous 2016 blocks, so that a new target difficulty can be computed for the next set of blocks.  A variability of a few hours over a period of approximately 2 weeks isn't significant to managing the difficulty target.

Keep in mind that Bitcoin is designed to behave as much like a currency as possible. It isn't designed to be an accounting system or a historical record. It's designed to make it possible to receive a transaction and to know, beyond doubt, that the transaction is real and the sender actually had control over the value being received. If I hand you a $10 bill, there is no timestamp attached to the transaction. You just walk away. with control over that $10 value. Anything else that Bitcoin is capable of beyond that is simply a consequence of the best-known attempt to make such a transaction system functional in a digital/electronic form.

[stwenhao]

Transactions don't have timestamps.

They kinda have. Each and every transaction has "nLockTime" field. Which means, that each and every transaction, can be confirmed after a given block, or a given timestamp. Of course, users could just set nSequence to "0xffffffff", and then "nLockTime" is ignored. Or they could simply use "0x00000000" as their locktime, and get it confirmed at any time, after the Genesis Block.

So, transactions don't have "reliable" timestamps, that you can "trust", but well, many wallets put the current block count inside locktime, to prevent an attack, where miners could constantly reorg a given block, and collect fees from transactions, which were made later. And by analyzing "nLockTime" field, maybe you cannot determine with 100% accuracy, when a given transaction was created, but you can at least assume, when a given user wanted to see it confirmed.

Also, when some transactions are mined, then the more Proof of Work is put on top of it, the more you can be sure, that once some user decided to commit to some timestamp, it wasn't easy to change it, because it would require re-mining the whole transaction. Of course, users can also use locktime as a nonce, but then, it is not that different from what real miners do, by making their timestamps in a two hour window.

So, for many transactions, locktime is not reliable. But if you have a user, which uses the default settings, then "nLockTime" can be pretty much accurate, and commit at least to the block, which was the tip of the chain, when that transaction was made.

[pooya87]

Transactions don't have timestamps.

They kinda have. Each and every transaction has "nLockTime" field.

Technically you can't call it a timestamp because in dictionary timestamp is defined as "time of occurrence" and transactions don't have that, so you have to guess it based on unreliable data (eg. when it was first seen by your node, when it was included in a block, etc.).
Also locktime is the time the transaction can get "locked" in the blockchain, not the time it "occurred" as you already know.

[callmejoe]

With a decentralized system, it's very difficult (impossible?) to enforce an exact timestamp. Once you accept that there will have to be some variability, it's just a matter of deciding how much variability is acceptable. If 1 second is acceptable, then why isn't 2 seconds?  If 2 seconds are acceptable, then why isn't 3?  The actual designed purpose of the timestamp drives the decision on how much is acceptable.

Transactions don't have timestamps. Bitcoin doesn't care when a transaction happens. The entire purpose of the blockchain itself is to declare an ordering of transactions BECAUSE there is no reliable way to determine the time that a transaction happened.  Rather than trying to decide exactly when on a clock a transaction happened, Bitcoin works by declaring the order in which they happened (regardless of time). Per the "rules" of the blockchain-based system, any transaction in a block at a lower block height "happened" earlier than any transaction in a block at a higher block height.

Since the blockchain eliminates the need to know the clock-time when a transaction happened, the sole use for the block "timestamp" is to compute what the average time between blocks was during the previous 2016 blocks, so that a new target difficulty can be computed for the next set of blocks.  A variability of a few hours over a period of approximately 2 weeks isn't significant to managing the difficulty target.

Keep in mind that Bitcoin is designed to behave as much like a currency as possible. It isn't designed to be an accounting system or a historical record. It's designed to make it possible to receive a transaction and to know, beyond doubt, that the transaction is real and the sender actually had control over the value being received. If I hand you a $10 bill, there is no timestamp attached to the transaction. You just walk away. with control over that $10 value. Anything else that Bitcoin is capable of beyond that is simply a consequence of the best-known attempt to make such a transaction system functional in a digital/electronic form.

this is helpful.  thanks