1

I have been looking into the code recently done by some developers, they are using block.number + numbers to calculate the time difference. For example if I want to lock fund for some 6 months or 180 days developers are using block.number + (some calculated numbers 1296000 blocks) to calculate number of funds to be unlocked.

I would like to know how this calculation works with time period. And why not to use block.timestamp instead? Is block.number reliable?

Here is the code snippet. It is basically vault that hold the tokens for 180 days.

contract Vault is SafeMath {

    // flag to determine if address is for a real contract or not
    bool public isVault = false;

    Token token;
    address multisig;
    uint256 unlockedAtBlockNumber;
    // 1296000 blocks = 6 months * 30 days / month * 24 hours / day * 60 minutes / hour * 60 seconds / minute / 12 seconds per block
    //uint256 public constant numBlocksLocked = 1296000;
    // smaller lock for testing
    uint256 public constant numBlocksLocked = 12;

    /// @notice Constructor function sets the Lunyr Multisig address and
    /// total number of locked tokens to transfer
    function Vault(address _Multisig) internal {
        if (_Multisig == 0x0) throw;
        token = Token(msg.sender);
        multisig = _Multisig;
        isVault = true;
        unlockedAtBlockNumber = safeAdd(block.number, numBlocksLocked); // 180 days of blocks later
    }

    /// @notice Transfer locked tokens to multisig wallet
    function unlock() external {
        // Wait your turn!
        if (block.number < unlockedAtBlockNumber) throw;
        // Will fail if allocation (and therefore toTransfer) is 0.
        if (!token.transfer(multisig, token.balanceOf(this))) throw;
        // Otherwise ether are trapped here, we could disallow payable instead...
        if (!multisig.send(this.balance)) throw;
    }

    // disallow payment after unlock block
    function () payable {
        if (block.number >= unlockedAtBlockNumber) throw;
    }

}
  • Hi there. Can you provide a snippet of the code you're asking about? – Richard Horrocks Jun 22 '17 at 13:42
  • Richard, I have updated the original post with the sample code. It is basically a vault that halt the tokens for 180 days. Calculation is done through block number calculation. I want to understand how the block number will help to calculate exact days to halt the assets. – Krunal Soni Jun 23 '17 at 14:13
1

I believe the block.timestamp is the wall-clock date/time at which the block was mined. A block number set in the future based on some other block is based on an estimate of the rate of block mining. For example, the average/target block time is, at the time of writing, about ~17s. So if you want to set a time 24 hours in the future via block number, you can use 24 * 60 * 60 / 17 (number of seconds in a day divided by number of seconds per block) to determine roughly what block number will be mined at that time. Note that for times in the mid- and far- future, you will need to take into account the ice age: the rate of block generation will slow down, by design, to encourage a hard fork for proof-of-stake and, in the meantime, makes the profitability of mining decrease materially (when denominated in eth) as the ice age progresses.

Here is a simulator to get an idea of what is happening: https://gist.github.com/CJentzsch/c78768f9837afb8eef74 Note that the rate of slowing has been slowed by a more recent change to the Ethereum protocol, so the simulator is out of date.

  • Thank you so much for clarification. It makes me more clear about the calculation. Based on that I have question regarding time calculation. How secure is to use now() + (6 * 30 days) to calculate the time period ? I have read somewhere without much clarification that miners could play with the date and time. – Krunal Soni Jun 26 '17 at 8:39
  • 1
    I think the consensus algorithm allows miners to fiddle with the date within some small bound to create consensus for clock drift; consensus for wall-clock time is required because it is used for calculating target difficulty. For example, if it took 5 seconds to find a block and the target is 15 seconds, then the difficulty needs to be adjusted upwards to maintain time. If consensus were not required, a miner could set the block's time to some far date in the future and "instamine" several blocks because the resulting difficulty were low. – lungj Jun 26 '17 at 13:39
  • 1
    Conversely, someone with a large amount of hashing power trying to issue a denial of service could increase difficulty more greatly in proportion to their mining power by making it look like the blocks were "instamined". Thus, unless the network has become compromised/malicious (in which case, there might be bigger issues than a smart contract), I think using the timestamp should be fairly safe, but you should wait for someone else to weigh in; I am not an expert on this by any stretch of the imagination and haven't written any smart contracts, yet. – lungj Jun 26 '17 at 13:42
1

The timestamp can be easily gamed over short intervals. For instance, if block n is mined at 13:30:00, the miner of block n+1 can timestamp the next block at 13:30:01, even if they didn't really mine it until 13:30:25.

Over long intervals, if you mess with the timestamp then by extension you also mess with the number of blocks, because the difficulty will adjust to match the number of blocks generated to the faster perceived passage of time.

I think people use block counts in these long-term examples because it makes them feel cyber. If the time period is long, and your goal is security rather than feeling like you're living in a science fiction novel, use a timestamp.

  • Yes, except for some things, I would argue that block height is more accurate. Miners cannot play with the block height like they can play with a timestamp, so calculating by block height would help you put an upper bound on the amt. of transactions that can hit a function in your smart contract, while timestamp cannot do this. – Alex Oct 14 '17 at 22:06

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.