>There is also no mechanism for figuring out whether you have all the existing blocks, meaning any blockchain based timeserver could still be tricked into reporting an earlier date by preventing him from receiving the newest blocks.
I feel like what I was hinting at wouldn't quite work like this, but rather a timeserver in this system would do something like take an average of past block times, compare that with cpu time, and derive a best guess at the current time- obviously there is variance from block to block, but statistically might tend towards an accurate representation of time.
Similarly, you could set your client to only update if 80-90% of the blockchain running servers agreed on the time.
>take an average of past block times, compare that with cpu time, and derive a best guess at the current time
But how does that work if the attacker controls your network and prevents you from receiving any blocks newer than the first of april? He can even send you the next (still ancient) block from the blockchain every ten minutes, making everything look legitimate.
If you are cold-starting and have only a vague idea of the date, then you can't defend against this. If you have a sufficiently good idea of the current time that this doesn't impact your threat model, you have already solved your timekeeping problem and don't need the blockchain technique anymore.
Presumably you can corrupt a couple of small networks on which bitcoin nodes are running and that wouldn't disrupt time for the entire chain and clients relying on it...
I feel like what I was hinting at wouldn't quite work like this, but rather a timeserver in this system would do something like take an average of past block times, compare that with cpu time, and derive a best guess at the current time- obviously there is variance from block to block, but statistically might tend towards an accurate representation of time.
Similarly, you could set your client to only update if 80-90% of the blockchain running servers agreed on the time.