2

I want to create a converter that can be given a block height, human readable time, or UNIX time and then provide the correlated information for it. For example, if given a block height, the converter will give you an estimated time (UNIX and converted to human readable format). And the same if given a UNIX time, it'll provide block height and human readable time associated with that block. And so forth if given a human readable string (stretch goal).

However, looking at the information online it seems pretty lack luster and also very approximate, using formulas, etc. See links here of similar questions:

https://ethereum.stackexchange.com/questions/10576/calculate-approximative-block-height-at-a-certain-time

https://www.reddit.com/r/BitcoinBeginners/comments/87lr89/is_there_any_block_height_to_datetime_converter

Are there any methods that could be achieved to create a deterministic result?

One method, I am considering is to iterate through the blockchain and generate a database that stores the block height and the UNIX timestamp associated in the block header of the block. Would this be a proper solution to the problem?

1 Answer 1

4

In theory there is one block per 10 minutes. That means you should be able to approximate the time of a block n as FIRST_BLOCK_TIME + n*600, where FIRST_BLOCK_TIME is the time of the genesis block, 1231006505.

Of course, that's very approximate, as the average time per block has been consistently less than ten minutes due to increasing block difficulty. In fact, as of writing (block 622719 with timestamp 1585016395), is 19621510 seconds earlier (over 7 months) than what would be predicted by that formula.

One method, I am considering is to iterate through the blockchain and generate a database that stores the block height and the UNIX timestamp associated in the block header of the block. Would this be a proper solution to the problem?

Using the real data is obviously going to be better than any approximating formula. Note that the timestamp of blocks are not necessary the actual time they are mined (in normal circumstances they can be up to 2 hours in the future, and up to approximately 1 hour in the past).

9
  • Hmmm... what is the time that everyone in the network agrees to? I guess I care about "network time" given your last statement of +2hour/-1hour accuracy. Thank you for your response. It would be nice however to get a more accurate UNIX time but I'll work with what is given. I just want it to be consistent and deterministic.
    – LeanMan
    Mar 24, 2020 at 3:41
  • 1
    There is no time agreed upon by the network but the block timestamp. It's wildly inaccurate, but not wrong, and it's more than enough for its purpose of existing: adjusting difficulty. Mar 24, 2020 at 4:25
  • OK - appreciate the input!
    – LeanMan
    Mar 24, 2020 at 5:03
  • Hi is the time provided by the RPC call GetBlock the timestamp of the block in question? "time" : ttt, (numeric) The block time in seconds since epoch (Jan 1 1970 GMT) bitcoin.org/en/developer-reference#getblock
    – LeanMan
    Mar 24, 2020 at 6:41
  • 1
    Yes, that's the block's timestamp. Mar 24, 2020 at 6:42

Your Answer

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

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