block timestamp is before than my transaction create time

[junha-ahn]

So Simply Our Send workflow like this:

1. DB) inesrt transfer
2. wallet middleware) sign & broadcast (to my local Geth node) transaction

so (in UTC)

• DB created_at: 15:00:40
• sign start : 15:01:04
• block.timestamp: 14:59:24

but the block.timestamp is 14:59:24 what is wrong?

• I checked block timestamp in Etherscan and eth_getBlockByHash in my Geth node.

I read some articles.

https://ethereum.org/en/whitepaper/#notes

• "Check that the timestamp of the block is greater than that of the previous blockfn. 2 and less than 2 hours into the future"

https://geth.ethereum.org/docs/interface/peer-to-peer

• "Your local time might be incorrect. An accurate clock is required to participate in the Ethereum network. Check your OS for how to resync your clock (example sudo ntpdate -s time.nist.gov) because even 12 seconds too fast can lead to 0 peers."

#21784

• "The block timestamp is set when the miner starts working on the block. So it will most likely be pretty close to the time when the previous block was propagated on the network. The header needs to be set before the pow-grinding starts."

So I think

The network time is correct. and I checked my DB time, that is correct too.

So what is wrong with it?

"The block timestamp is set when the miner starts working on the block"

• I think mining starts when all transaction is ready in the miner's node (txpool), so can make txRoot and blockHash

[ligi]

Did this happen once or regularly?

I think mining starts when all transaction is ready in the miner's node (txpool), so can make txRoot and blockHash

this assumption is wrong - mining starts and transactions can come in in between

[junha-ahn]

Did this happen once or regularly?

I don't know for sure

this assumption is wrong - mining starts and transactions can come in between

but we have to make block hash with a previous hash and transaction root which is Root of the transaction trie
And then, we can calculate nonce. (with block hash)

Am I misunderstanding?

[rjl493456442]

@junha-ahn we can always switch the mining block in flight, with the exact same timestamp but different tx list.

[holiman]

The header is created, transactions added (new tx root).
The mining is started on that hash.
Then, a bit later on, we do an update, to include new transactions. This changes the tx root hash, but we do not update the header timestamp, because that would force us to reexecute all transactions already there (because the timestamp is obervable from the evm).
So a block that takes a minute to mine will have a minute old timestamp, even though it can contain a transaction that was created one second before mining completed.

[junha-ahn]

Ok, Thank you but I'm wondering one thing

1. there is an (unknown) nonce that we have to find to create a new block (nonce + block hash)
2. but if block hash changed, (unknown) target nonce will be change
3. And if the transaction list changed, txRoot will be change, and blockhash will be change too, so We have find a new nonce
4. so if a new transaction added in txlist, Miner have to find a "new nonce" (it's like time waste?)

Where did I start thinking wrong?

[holiman]

1. Yes
2. Yes
3. Yes
4. Yes

Where did I start thinking wrong?

Your mental model is wrong. You think it's like when searching for a lost glove in the apartment: first you search the living-room, then the hallway, etc, and eventually you'll find it. After a while, there's only the bathroom left -- you're closing in! And in this model, if you switch and suddenly starts looking for a sock instead, then the time spent was wasted, and you start again in the living-room.

Consider instead that you're on the coast of australia, searching for a particular sort of sand-grain. There's a near-infinite search space, so it doesn't matter if you jump randomly across the coast or if you investigate one square millimeter at a time - it's not like you're accidentally going to pick the same grain for comparison again anyway. And it's not like you're closing in on the possible locations of this grain of sand.

Similarly, if you switch the grain of sand to another one, you don't have to re-examine the particular grains that you have already checked. The search just goes on.