3

There seem to be some irregularities with Blockchain.info's transaction timestamp (aka Received Time) for a set of blocks. The transaction times are recorded with unix timestamps well into the future (2017, 2022, 2035, etc..)

For example, here is a transaction in block 237173 with a timestamp of 2035-05-27 00:00:59.

All the blocks that have transactions with a future Received Time are as follows:

237173 237175 237180 237181 237182 237183 237184 237185 237186 237187 237188 237189 237190 237191 237192 237193 237194 237195 237196 237200 237201 237202 237210 237280 237945 237980 238008 238013 238038 238227 239127 240078 241223 260657 260819

1) Are these valid transactions?

2) If they are valid, how can I assign a valid timestamp to these transactions? Would it be 'fair' to simply assign them the block's timestamp?

3) From what I understand about the Received Time, it represents the time that bc.info sees the transaction, so how can this this timestamp be occurring? Is it a bug?

Improve this question
5
  • A similar (answered) question is available here: bitcoin.stackexchange.com/questions/37721/…
    – Christopher Gurnee
    Jun 4, 2015 at 0:07
  • 1
    That's also my question, but I don't believe it's the same issue. That answer is saying bc.info missed the transaction so it couldn't timestamp it. Here there is a timestamp. Some are close into the future (Aug 2015) and some are very distant into the future (Apr 2078).
    – mrp
    Jun 4, 2015 at 0:21
  • Oops, I should have noticed that was your question. Since bc.i's backend is closed source, it seems unlikely (IMO) that you'll get a better answer to this question other than what you already know... that bc.i is a bit buggy....
    – Christopher Gurnee
    Jun 4, 2015 at 0:28
  • Np, it just seems like a really odd bug. Anyway, I at least hope the info above could be useful to others.
    – mrp
    Jun 4, 2015 at 0:40
  • 1) They are valid if they are in the best blockchain. 2) Take the timestamp from the actual Bitcoin block (instead of the Blockchain.info web service). 3) No idea, it's probably an idiosyncrasy of Blokchain.info's operations.
    – Nayuki
    Nov 30, 2015 at 1:01

2 Answers 2

Reset to default
0

1) Are these valid transactions?

Yes

2) If they are valid, how can I assign a valid timestamp to these transactions? Would it be 'fair' to simply assign them the block's timestamp?

You can do anything. Yesterday I've timestamped them as 1905, today as 2048

3) From what I understand about the Received Time, it represents the time that bc.info sees the transaction, so how can this this timestamp be occurring? Is it a bug?

Yes.

Improve this answer
3
  • Why are you allowed to timestamp them far into the past/future?
    – mrp
    Jun 4, 2015 at 17:45
  • Transactions do not have timestamp fileld! This is only bc.i point of view
    – amaclin
    Jun 4, 2015 at 21:03
  • 1
    @mrp Who would stop you and how would they stop you? You can put any timestamp on any transaction you want. My understanding is that blockchain.info claims to timestamp them based on when they first saw them, but it seems they sometimes screw that up.
    – David Schwartz
    Dec 2, 2015 at 8:23
0

Block and transaction timestamps are unreliable in a peer to peer environment. See similar question here https://bitcointalk.org/index.php?topic=1164293.0

You could have timestamp of block n > timestamp of block n+1. bc.info seems to reporting received time same as block timestamp, which seems to be a bug. I suggest you explore other blockchain apis like blocktrail and tradeblock .

Improve this answer
1
  • There's no such thing as a transaction time stamp anyway so the point is fairly moot.
    – Claris
    Dec 1, 2015 at 7:37

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.