17

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.

  • 1
    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
12

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.

  • 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. – Validity Labs - Sebastian 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? – Validity Labs - Sebastian Dec 26 '16 at 21:54
  • 2
    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
  • 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 Dec 27 '16 at 4:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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