cerc-io/solidity
16
0
Fork 0
mirror of https://github.com/ethereum/solidity synced 2023-10-03 13:03:40 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Document caveats about timestamp and blockhash

Browse Source
This commit is contained in:
Alex Beregszaszi 2017-08-29 23:34:53 +01:00
parent 8e1aae2e1a
commit f3230a41ce
2 changed files with 12 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
docs/frequently-asked-questions.rst
View File

@ -125,24 +125,6 @@ Example::
}
}
Are timestamps (``now,`` ``block.timestamp``) reliable?
=======================================================
This depends on what you mean by "reliable".
In general, they are supplied by miners and are therefore vulnerable.
Unless someone really messes up the blockchain or the clock on
your computer, you can make the following assumptions:
You publish a transaction at a time X, this transaction contains same
code that calls ``now`` and is included in a block whose timestamp is Y
and this block is included into the canonical chain (published) at a time Z.
The value of ``now`` will be identical to Y and X <= Y <= Z.
Never use ``now`` or ``block.hash`` as a source of randomness, unless you know
what you are doing!
Can a contract function return a ``struct``?
============================================

12
docs/units-and-global-variables.rst
View File

@ -72,6 +72,18 @@ Block and Transaction Properties
``msg.value`` can change for every **external** function call.
This includes calls to library functions.
.. note::
Do not rely on ``block.timestamp``, ``now`` and ``block.blockhash`` as a source of randomness,
unless you know what you are doing.
Both the timestamp and the block hash can be influenced by miners to some degree.
Bad actors in the mining community can for example run a casino payout function on a chosen hash
and just retry a different hash if they did not receive any money.
The current block timestamp must be strictly larger than the timestamp of the last block,
but the only guarantee is that it will be somewhere between the timestamps of two
consecutive blocks in the canonical chain.
.. note::
If you want to implement access restrictions in library functions using
``msg.sender``, you have to manually supply the value of