Solidity: Timestamp dependency, is it possible to do safely?

Question

My contract depends on checking to see if an expiration period has expired before sending the contracts balance. I was looking at the ConsenSys best practices here and it says:

Timestamp Dependence

Be aware that the timestamp of the block can be manipulated by the miner, and all direct and indirect uses of the timestamp should be considered. Block numbers and average block time can be used to estimate time, but this is not future proof as block times may change (such as the changes expected during Casper).

Is there any way around this? It seems like it would be quite a hinderance to the idea of smart contracts since contracts are often heavily reliant on time.

Answer 1

Just to elaborate on Dennis' answer and explain why this hindrance exists.

Deep down, the decentralized nature of the consensus means that no one's clock is any better than anyone else'. Blocks disambiguate transaction order which is critical for reaching consensus about world state. They do this without reference to a reliable time source. Since no one can check the timeStamp without reference to a non-deterministic time source, the accuracy of the time stamp is dubious.

There's an interesting discussion on the accuracy of the timeStamp, the latitude the miners have and incentives to keep the timeStamp within reason, here: How do Ethereum mining nodes maintain a time consistent with the network?

This is quite a departure from networks synced with atomic clocks as we've come to take for granted, I think. A good understanding can keep us away from hidden assumptions and problems.

We can say ...

"The event will unfold at block _____" which is probably going to occur at approximately date/time given a predictable average block time.

"The event will unfold when a block is mined with a timeStamp >= deadline" which should be roughly at said deadline but isn't guaranteed to be precise.

"The event will unfold when the Oracle injects a transaction to declare that the event has occured without regard to either the block number or the block time stamp" in which case a trusted time source will decide.

Above are some examples of plain english we might use to describe the way a future time is codified in a Smart Contract so things unfold "as advertised."

Hope it helps.

Answer 2

It depends on how fine-grained you need to be. The timestamp has to have a later time than the previous block's timestamp, and if it's too inaccurate then other miners will reject it.

So if your contract has to count days, and two years from now it will still be running and counting days, then timestamps are probably the way to go. You'll have to think carefully about what happens if a miner shifts the time by a few seconds.

If your contract is just going to run for a short time, then you can use block numbers and not worry about manipulation at all.

A complete disaster is to use timestamps as the random seed for a lottery. The miner can try out thousands of acceptable timestamps, looking for one that gives him a win.