blockchain.info transaction timestamps set into the future

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?

mrp

Posted 2015-06-04T00:00:44.473

Reputation: 195

A similar (answered) question is available here: http://bitcoin.stackexchange.com/questions/37721/bc-info-transactions-with-no-timestamp

– Christopher Gurnee – 2015-06-04T00:07:46.067

1That'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 – 2015-06-04T00:21:26.140

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 – 2015-06-04T00:28:20.873

Np, it just seems like a really odd bug. Anyway, I at least hope the info above could be useful to others. – mrp – 2015-06-04T00:40:41.433

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 – 2015-11-30T01:01:23.900

Answers

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.

amaclin

Posted 2015-06-04T00:00:44.473

Reputation: 5 763

Why are you allowed to timestamp them far into the past/future? – mrp – 2015-06-04T17:45:57.870

Transactions do not have timestamp fileld! This is only bc.i point of view – amaclin – 2015-06-04T21:03:08.333

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 – 2015-12-02T08:23:55.890

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 .

dark knight

Posted 2015-06-04T00:00:44.473

Reputation: 1 532

There's no such thing as a transaction time stamp anyway so the point is fairly moot. – Anonymous – 2015-12-01T07:37:27.247