Height Size Tx Timestamp Block Hash
857514 172 0 2015-12-06 22:27:18 29a7fab8e70f7427e83369e376c703466d659e9e82970c53207efc26a76ac46f
857513 210 0 2015-12-06 22:30:52 0577cccde88d30305510f02d2de74831b0dad75a63a968809245fe6e79e8595c
857512 1609 2 2015-12-06 22:27:25 7828369138ec760bf96621a1f6f618bd4585602719460dbfae1cbca63e025bfe
in this example it shows block 857514 with a timestamp before block 857513 (and before 857512)
whats wrong?
(timestamp seems off on many blocks there, blockheight is higher but timestamp is earlier)
Timestamps are approximate. They are set by the miner but if the miner's computer clock is off, the timestamp will be off. They're still accepted by the network if within some range.
thanks
don't know what's used to determine if the timestamp (and so the block is in the required range), but i guess the last x blocks are used to get the "real" time, or is there some other way?
I can't guess anything else then it has to be determined on something (blocks) in the blockchain to get a consensus of the "real time".
If so, isn't this an network attack vector?
What if an bad acting miner gets lucky (or owns big hashing power) and finds for example 10 consecutive blocks (xxx1, xxx2, xxx3, xxx4, ..., xx10), if i get it right he is allowed to set the timestamp for the block by his local time, inside the time window, so if he is a bad player and there is a time window of lets say 30 min between each block couldn't he just change the timestamp to something like:
block xxx1 real time + 25min
block xxx2 real time + 50min
block xxx2 real time + 75min
...
block xx10 real time + 250min
so every other miner who will try to submit a block after block xx10 will then be rejected, because their blocks are not in the allowed time window after the last block was 250min "later" then the real timestamp?!
So in the end only the bad acting miner will be able to mine new blocks?!
Does this makes sense? How does the determination/consensus of the "time window" works?
There is a maximum time "ahead" of 120 minutes. No one else will accept the block if it is more than 120 minutes ahead of what they think the current time is. So the miner in your example could mine those blocks but the later ones would be rejected by everyone else for some time period, during which time others would be able to mine different blocks, likely causing the bad miner's effort to be wasted.
There are some potential vulnerabilities having to do with time (look in google for bitcoin time attack or something). Monero is in some ways less vulnerable than Bitcoin because "network time" was never implemented, so you can't mess with nodes' notion of time with a sybil attack on the p2p network.