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.

eth
  • 85,679
  • 53
  • 285
  • 406
SCBuergel
  • 8,774
  • 7
  • 38
  • 69
  • 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 Dec 26 '16 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 Oct 12 '20 at 08:24

1 Answers1

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.

Edmund Edgar
  • 16,897
  • 1
  • 29
  • 58
  • 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 Dec 26 '16 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 Dec 26 '16 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 Dec 26 '16 at 21:54
  • This isn't quite right. The miner can influence when block number X will appear on the network: They can withhold blocks they've mined until later, or they can switch on more miners to make things go faster for a while. (eg if you have a chunk mining ETC, switching it to ETH temporarily is almost free.)

    It's true that block.timestamp can easily be manipulated at no cost within the block window (ie if you mined 15 seconds after the last block, you could pretend it as 3 seconds after the last block), but the precision you lose to this attack is already lost if you're using block height.

     – Edmund Edgar Dec 26 '16 at 23:09
  • 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 Dec 26 '16 at 23:13
  • ok thanks for the clarification. By how much a miner can really modify the timestamp is another topic that we should discuss in another thread. I think this isnt so obvious (white vs yellow paper vs geth). – SCBuergel Dec 27 '16 at 00:21
  • 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: https://ethereum.stackexchange.com/questions/5927/how-would-a-miner-cope-with-a-huge-block-time – eth Dec 27 '16 at 04:19