25

In Solidity, some properties such as block.timestamp are attackable by miners and are not (strongly) protected by the protocol. How about block.number, could a miner introduce a randomly high number?

EDIT: I'm thinking of securing a game which facilitates actions such as a pay out, after a certain time period elapsed.

Improve this question
2
  • 2
    If we're talking about hours or days and we just want to know if time has passed or not I don't think there would be any meaningful security benefit to using block numbers rather than block timestamps. However, if the time is intended to give people a chance to react to something happening by sending transactions - for example, to challenge a proposed action - you might want to include a block number as well just in case something weird is happening on the network. I think it's borderline whether the value of this is worth the security cost of the extra complexity.
    – Edmund Edgar
    Commented Dec 26, 2016 at 13:34
  • 1
    Please note that block.timestamp speculation is usually warrantless. block.timestamp is very safe in real-life scenarios. block.timestamp is safe for 99% use cases. If you are afraid of the frontrunning problem, then using block.number does not really solve it. If you are afraid miners mess with your transaction, then you have an avenue of other attack vectors that using block.number does not solve.
    – Mikko Ohtamaa
    Commented Oct 12, 2020 at 8:24

1 Answer 1

Reset to default
17

The block number will always be correct by definition: It's number x in the chain, because it's chained on top of x-1.

However, as you say block.timestamp can be gamed a little bit - or with the cooperation of the economic majority of validating nodes a lot - which also means that the relationship of block.number to actual time can be gamed. So if you don't trust that a block.timestamp of 2017-01-01 will really be approximately 2017-01-01, you can't rely on counting the blocks that are supposed to be mined between now and 2017-01-01 either.

PS. People may be able to give you more helpful advice if you tell us what purpose you want to be secure for, and what you want to be secure against.

Improve this answer
7
  • I don't understand So if you don't trust that a block.timestamp of 2017-01-01 will really be approximately 2017-01-01, you can't rely on counting the blocks that are supposed to be mined between now and 2017-01-01 either.: If my game starts at block number 1M and should last 100blocks until payout then I could just check if we already reached block 1'000'100. I'm here trusting the consensus algorithm that the time in-between was 100*14s and not just a single miner.
    – SCBuergel
    Commented Dec 26, 2016 at 13:52
  • The consensus algorithm prevents blocks going backwards, or being further forwards than the current time. And any honest miner can bring it forwards to the right time. So it shouldn't be far off without a lot of miner collaboration. If there's a lot of miner mischief over time this will also affect retargeting, so the block interval won't reliably be 14 secs.
    – Edmund Edgar
    Commented Dec 26, 2016 at 14:26
  • 2
    For max clarity, let me try to rephrase: Without significant collaboration, miners cannot influence when block number X will appear on the network. Hence block.number is significantly more secure than block.timestamp which can be manipulated (to some extend) by a single miner. Since the blocktime is not constant, this is however only a viable solution if the exact time is not needed. Correct?
    – SCBuergel
    Commented Dec 26, 2016 at 21:54
  • 3
    My pulled-out-of-my-bum suggestion, without committing mathematics, would be that you want to be using block height (or both, if you need human time) for small numbers like 10 blocks, because if fewer blocks have elapsed nothing the blockchain can tell you about time is reliable. For days and weeks you should use block.timestamp if what you care about is human time to find out about something through social channels, or block height if what you care about is the ability to send a transaction through an automated process, or both if you care about both. 100 blocks feels a bit borderline.
    – Edmund Edgar
    Commented Dec 26, 2016 at 23:13
  • 1
    @Sebastian The protocol doesn't have a limit into how high the timestamp can be, but getting other miners to build on top of such a block is unlikely: ethereum.stackexchange.com/questions/5927/…
    – eth ♦
    Commented Dec 27, 2016 at 4:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.