Topic: Consistent Estimater of Transaction Times - Block Timestamp? (Read 1043 times)

Bitcoin-Qt should operate in server mode if you set up the bitcoin.conf correctly.  Then you can issue the getblockhash and getblock commands to Bitcoin-Qt instead of bitcoind

In my view, a transaction is "pending" until it is added to a block, and it doesn't become an actual transaction until then. So the timestamp for a transaction would be the time it was added to the block chain -- the block's timestamp.

The only problem with this is that bitcoind is not in the standard Mac download.

Whoa!! Thanks!!

bitcoind getblockhash 291050
bitcoind getblock 00000000000000004642ed8eb619f2f84aaf201dbf0ba5fc87c425d040455d5a

Because human beings need date/time, not block height. And the algorithm I'm working on needs actual days, hours, mins.

why dont you just forget the time concept altogether and simply rely on blockheight?
eg instead og balance at time x you say balance at block x

Interesting... I've been looking at just that solution. But the problem is that the address-transaction function only gives you the block height, and unless I'm mistaken, blockchain.info doesn't have a function for getting the block from it's block height. My bitcoin-qt client doesn't give me all the blocks in the block chain, either. What's a poor coder to do? 

The lesson that you should learn from this is that a website named blockchain.info, despite the fancy name, is not a reliable source of information about bitcoin.


The closest that you can get meaningfully, is the timestamp of the block.  The timestamp in the block is usually very close* to the actual time that block was found, and is absolutely sure to be within the fuzzy window that the network defines for validity.

You could also run your own service and keep track of the exact instant that you first see each block.  However, this will quickly run into the problem of no one giving a fuck when you first saw it.  In theory, this problem can be overcome by becoming important in the community, but most people would probably just prefer to use the global timestamp that is already in the block, and accept the limitations thereof.

* And by "very close", I mean within the "reasonable accuracy of a few minutes" that you are asking for.

I'm working on some code to generate a balance history of an address. That is, I want to be able to determine at any point within an address's lifetime, what the balance was at that point. This means I need to determine on what dates inputs and outputs occurred.

Yes, yes, I know this is not the wallet balance. I really am interested in the address balance. And also, I'm interested in the balance, not the sum of outputs to that address. Balance at any point in time is sum(outputs to the address) at time T - sum(inputs drawn from address) at time T of the address.

I'm using blockchain.info's address history api function and I'm finding some bogus transaction/block times in the output. Specifically, one transaction has a time stamp of 2005.12.24. Right Christmas Eve, 2005. Now... you KNOW that's not correct! 

After reading this thread and a couple others, I surmise that the miner that generated the block didn't have the time set correctly on the machine. This tells me that these timestamps aren't reliable. So, how do I determine, within a reasonable accuracy of a few minutes, when a transaction actually made it into a block? Is there some independent source of accurate data on this?

I was thinking I could apply some heuristics to the times and then if I find a bad one, simply interpolate between the times of the neighboring blocks. That's probably close enough for my purposes.

Any ideas gratefully accepted!

Thanks Cryddit..... was hoping I could find something a little more 'exact' but apparently not.  My challenge is the 'time' of a transaction included in a block..... now you might get this from an entry in your wallet, etc., but something out of one's control is the issue..... so that from an audit standpoint you can trust the timestamp to a greater degree.... and build confidence in its use since it is the only time-stamp in the block-chain.

It may well be that this is not relevant to verify a block's integrity or avoid double-spend, but it may impact how bitcoin is percieved in a larger sense, and that is important to us all.  The size of the block chain is already a serious issue, so independently including a time stamp for each transaction is no help.... but if anyone has any thoughts on the matter it would be appreciated.

bob

Further, the blocks are not necessarily sequential in timestamps.  Two blocks formed a minute apart could have the reverse order of timestamps if the two miners' clocks disagreed by more than a minute. 

That said, I think you can rely on block timestamps to within an hour or so for any normal transaction.

You are quite correct that there is no timestamp available that you can call the timestamp of a transaction.

Bitcoin defines the order in which transactions happen, but does not record when* they happen.  If your application depends on timestamps, you'd better rethink it.

* The block timestamp can, at very best, tell you that the transaction existed prior to some time in the rough vicinity of the block timestamp.  But this is a wrinkle in the system.  Block timestamps are only used to prevent people from cheating the block rate (and thus the difficulty [and thus the subsidy]).

So, what i see in the blockchain.info time, is not really based on when any node received the transaction but, rather, the timestamp of the node (block) itself - which is generated off of the miner's system and not some other source.  In that sense, the transaction may have be older than the stamp as it sits in the mempool until it is constructed into a block by the miner, and then only the block will have a timestamp.  Provided PoW works and it is otherwise well formed - it is added to the chain......

Now.... if the block is an orphan, is removed and the transactions go back into the mempool there is no stamping that occurs then.  The transaction will at some point end up in another constructed block that - if it is accepted to the block-chain - it will be that new block's timestamp in its header that will apply to all transactions in the block and show in the blockchain.info you guided me to.... yes?

I understand that the stamp in the bock header is not intended to be a transaction time for included transactions, but I have no other time stamp I am aware of aside from what is in the wallet.

Is this the case?

and BTW, thanks for your response.....

You are correct, there is no "tx time" embedded in the blockchain for individual transactions, only for blocks themselves.

There exists only a pseudo "tx time", which is based on when the node received the transaction.

For example, this is what blockchain.info means by "received time". https://blockchain.info/tx/dc55d9c6ec03ceccf0db43d29e7d626a8b107f41066e3917f30398bb01dda2b5

However, as you can imagine, this can vary greatly between nodes.

Does anyone use the block timestamp to establish a 'transaction time' for the transactions in the block?

If so, do you:
   1. Average the stamps of the prior blocks to account for the date stamp placed by the miner, or
   2. Use the stamp of later blocks in the chain under a theory that the transaction is not 'complete' from a business sense until it is confirmed?

Need to establish the 'time' for several trades made in the past, and from what I read the block timestamp is the only time as there is no tx time in the transaction structure itself.....