Proposal: Change block timestamp to represent moment block is found, rather than moment mining started.

[dan-da]

Background:

Being familiar with bitcoin-core and bitcoin block explorers, my expectation was that the timestamp in a neptune block-header represents the moment when the block was mined. So I was surprised to find it actually represents the moment that mining started, which may be even 1 hour in the past vs when the block is found.

This occurs because the timestamp is set in the block-header when mining starts and after that only the nonce is modified each iteration of the mining loop. It is unknown to me if this is thought-out, intended behavior or an oversight.

Upon realizing this, I was curious how bitcoin handles it because I understood this is something that could vary between implementations. So I asked a question on stackexchange.

Based on Pieter Wuille's answer, I think I can summarize that, in bitcoin, the intent of the timestamp is to represent the time at which a block is found. However, nothing prevents it from being set to the moment mining started.

It is simply convention and user expectation across the bitcoin mining ecosystem (and other cryptos) that the time represents when a block was "mined", ie found. So for example block explorers like blockchain.info will say "Mined on May 08, 2024 11:51:19", not "Began mining at May 08, 2024 11:51:19", even though in theory the latter could be true.

Proposal

I propose we modify the mining loop to update the timestamp in the block header every second, at least. For these reasons:

1. Because it makes logical sense that a timestamp would represent the moment a block is actually created, which technically does not occur until a winning digest is found.

2. Because there is already widespread user expectations that a timestamp represents the moment a block is found/mined, and doing it differently could cause confusion when people look at block explorers, and their own wallets. For example, in Bob's wallet the block could appear to have been created before Bob sent a transaction contained within it.

Note that such a change does not affect consensus and also cannot be enforced. Eventually neptune mining will probably take place using dedicated software, not neptune-core. So this would only be changing the default convention.

[aszepieniec]

Agreed, the timestamp should reflect when the block was found, not when mining started.

[dan-da]

great, I will make the change.

[dan-da]

tdd: 318b7a20baf11a7a99f249660f1f70484c586012 adds a (failing) test for this, and 5f9c9e8306808053882095a0762e3689031d0a22 modifies the mining loop, as per proposal, so the test passes.

[Sword-Smith]

I was a bit unsure about this. Because I expected that the timestamp in question should be committed to in the STARK proof. If that's not the case, then this sounds like a good change.