Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

block.timestamp always 0 when "callcontract" #480

Closed
hayeah opened this issue Jan 30, 2018 · 8 comments

Comments

@hayeah
Copy link
Contributor

commented Jan 30, 2018

Describe the issue

block.timestamp always 0 when "callcontract"

Can you reliably reproduce the issue?

yes

If so, please list the steps to reproduce below:

Deploy a contract that uses block.timestamp:

pragma solidity ^0.4.18;

contract BlockTime {

  event BlockTimeEvent(uint256 time);

  // ABI method selector: 87ceff09
  function getBlockTime() constant public returns(uint256) {
    BlockTimeEvent(block.timestamp);
    return block.timestamp;
  }
}

Make an RPC call:

qcli callcontract a07ae04b78b475bacf747f3a47391af418e1a770 87ceff09

The result:

{
  "address": "a07ae04b78b475bacf747f3a47391af418e1a770",
  "executionResult": {
    "gasUsed": 22499,
    "excepted": "None",
    "newAddress": "a07ae04b78b475bacf747f3a47391af418e1a770",
    "output": "0000000000000000000000000000000000000000000000000000000000000000",
    "codeDeposit": 0,
    "gasRefunded": 0,
    "depositSize": 0,
    "gasForDeposit": 0
  },
  "transactionReceipt": {
    "stateRoot": "c0d006ca939565b8a5654c8391ca365193f282677510a5a86cc4935523b635fa",
    "gasUsed": 22499,
    "bloom": "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000004000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000000000
00000004000000000000000000000000000000000000000000",
    "log": [
      {
        "address": "a07ae04b78b475bacf747f3a47391af418e1a770",
        "topics": [
          "834b232e222fd478fbc14dc686a95e5120c477293b9aa05d55cc19491077f49a"
        ],
        "data": "0000000000000000000000000000000000000000000000000000000000000000"
      }
    ]
  }
}

Expected behaviour

block.timestamp should be a time that roughly reflects the current time.

It could either just be the local node's time, or network's median blocktime. Personally I think the local node's time more useful for my use case.

Actual behaviour

The block.timestamp is always 0. This makes it hard to use call to check some time-related conditions. For example, whether current time has past crowdsale start time.

What version of Qtum are you using?

qtumd --version
Qtum Core Daemon version v0.14.13.0-b4e73b7-dirty
@hayeah

This comment has been minimized.

Copy link
Contributor Author

commented Jan 30, 2018

Similar issue with a few other globals

pragma solidity ^0.4.18;

contract BlockTime {

  event FooEvent(uint256 time, uint256 blockNumber, address coinbase, bytes32 blockhash, uint256 difficulty);

  function emitFooEvent() constant public returns(uint256, uint256, address, bytes32, uint256) {
    FooEvent(block.timestamp, block.number, block.coinbase, block.blockhash(block.number), block.difficulty);
    return(block.timestamp, block.number, block.coinbase, block.blockhash(block.number), block.difficulty);
  }
}

Behaviour in Ethereum, Rinkeby network:

  • block.timestamp: current time of node
  • block.number: latest mined block number
  • block.coinbase: miner of latest mined block
  • block.blockhash(block.number): 0x0 this is the weird one in ETH... why isn't this the block hash of the latest mined block?
  • block.difficulty: difficult of latest mined block

remix_-_solidity_ide

designsters pushed a commit that referenced this issue Feb 7, 2018

@qtum-neil

This comment has been minimized.

Copy link
Contributor

commented Feb 8, 2018

Fixed here: 8e22a57

@qtum-neil qtum-neil closed this Feb 8, 2018

@patidarmanoj10

This comment has been minimized.

Copy link

commented Jan 24, 2019

@qtum-neil I am still getting block.timestamp as 0.

Though block.number return non zero value but block.timestamp is always 0

I am using
qtumd --version
Qtum Core Daemon version v0.16.2.0-47a3046-dirty

@qtum-neil

This comment has been minimized.

Copy link
Contributor

commented Jan 24, 2019

@patidarmanoj10 I confirm that's a bug, will fix in the next release.
Thanks for reporting!

@qtum-neil

This comment has been minimized.

Copy link
Contributor

commented Jan 24, 2019

Fixed here: dd6090b

@patidarmanoj10

This comment has been minimized.

Copy link

commented Jan 25, 2019

@qtum-neil Thanks for proving fix quickly.

I understand this was fixed in past also. was it overwritten in some release? I want to download that version which had fix instead of building it from latest source code because building from source is taking too much time. I am using $docker build --rm -t qtum/qtum:dev .

@qtum-neil

This comment has been minimized.

Copy link
Contributor

commented Jan 25, 2019

@patidarmanoj10 Yes, the fix was accidentally dropped in a previous release, try version 14.16:

https://github.com/qtumproject/qtum/releases/tag/mainnet-ignition-v0.14.16

A new release including the fix will be made next week.

1 similar comment
@qtum-neil

This comment has been minimized.

Copy link
Contributor

commented Jan 25, 2019

@patidarmanoj10 Yes, the fix was accidentally dropped in a previous release, try version 14.16:

https://github.com/qtumproject/qtum/releases/tag/mainnet-ignition-v0.14.16

A new release including the fix will be made next week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.