One of them is that some goverment (probably USA) will subvert all observable time sources (NTP, GPS, etc.) yet the Internet will continue to operate. This is completely ridiculous, as vast majority of the modern digital communication is synchronous and relying on the precise clocks that are satellite-synchronised.
How many time sources is your computer synced to right now? Even of the people running NTP, the vast majority are connected to just a small handful of servers. You don't need to subvert all time sources, you just need to subvert a few for a few hours, because the average miner probably doesn't even check their mining computers daily. The system as it is can withstand a heck of a lot of neglect by miners, your ideas require active management and hence are fragile.
Again, what value to Bitcoin the financial network is there in having really accurate block timestamps anyway?
The other side of this argument proposes two algorithms: one real-time (for "current" blocks) and one past-time (for "historical" blocks). I have yet to see anyone who proposed a single contiguous algorithm which will reject the same blocks both when seeing them on the p2p net and when verifying the stored blockchain. Can you write a proof that your pure function "valid(block,blockchain,t)" is both independent of the "t" parameter and somehow better than the old "valid(block,blockchain)" function? And for what definitions of "better"?
EDIT: on reflection, I think I misread what you were saying, in any case, digging through the below was quite informative for me.
The algorithm is more simple than you think. Every block of unknown validity, whether it's been given to us by a peer, or we're loading new blocks from disk with loadblock, first passes through the ProcessBlock() function. One of the first things ProcessBlock() does is it calls CheckBlock() which does the initial context-independent validity checks. CheckBlock() has only one timestamp-related check, and it's a really simple one:
// Check timestamp
if (GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
return error("CheckBlock() : block timestamp too far in the future");
That just means that if a block has a timestamp more than two hours in the future we will always consider it invalid under
any circumstance. Bitcoin doesn't use the "wall-clock" directly, instead the GetAdjustedTime() function, defined in util.cpp takes the average of all the times reported to us by the nodes we're connected to, and ourselves, and uses that as "time". However it won't let that median change what we consider as "now" by more than 70 minutes; replacing GetAdjustedTime() with just GetTime() is fine if you're clock is accurate. Note how this means that if you set your clock back in time Bitcoin will think perfectly valid blocks are invalid.
ProcessBlock() itself has only one time-related check:
// Extra checks to prevent "fill up memory by spamming with bogus blocks"
int64 deltaTime = pblock->GetBlockTime() - pcheckpoint->nTime;
if (deltaTime < 0)
{
if (pfrom)
pfrom->Misbehaving(100);
return error("ProcessBlock() : block with timestamp before last checkpoint");
}
This code is only run if the block isn't part of what Bitcoin thinks is the best chain, and just makes sure that blocks before a checkpoint don't have a timestamp after the checkpoint. (this is why checkpoints have to be picked from blocks that don't have any blocks before in the chain with timestamps after them) Basically it's a sanity check to make sure that nodes can't DDoS you with fake blocks.
Once ProcessBlock has done its checks, it calls AcceptBlock() to do
context-sensitive checks that depend on what previous blocks exist in the chain. It also has exactly one time-related validity check:
// Check timestamp against prev
if (GetBlockTime() <= pindexPrev->GetMedianTimePast())
return error("AcceptBlock() : block's timestamp is too early");
GetMedianTimePast() returns the median of the timestamps of the past 11 blocks, so basically this check is just ensuring that block timestamps are in fact going forward in time. Now there is also an implicit time-dependency in that the difficulty calculation, GetNextWorkRequired(), uses the block timestamps, but that's a second-order effect.
As you can see,
all block validation is done without any reference to the current time at all, with the one exception that at any given moment we will consider any block invalid if it has a timestamp more than 2 hours into the future.
The reason why that one little rule leads to relatively accurate block timestamps is simply because miners want other miners to build on their blocks, so it makes sense to try to keep your timestamps accurate enough that the vast majority of miners will accept them as valid. Notably a 51% attacker who doesn't care about other miners can make the blockchain timestamps say whatever they want them too.
I would like to interprete the time-stamp as the time when the block got known to the network -- and network propagation is in the order of a few minutes at most.
Why do you need to do this?
FWIW I'm planning on setting up some servers that will automatically timestamp Bitcoin blocks as they come in against public
RFC3161 timestamp servers - there are a variety of public ones run by certificate authorities and other trusted entities - and making the archives of those timestamps publicly available. That type of idea may be what you really want.
The real threat is not that a goverment would manipulate (satellite/ntp) timing to hinder/destroy bitcoin-network or any other technology, but simply changes laws and activate layers (and use police and justice) to restrict its usage severly or totally! This happened already again and again in the past.