Closed dcousens closed 6 years ago
@runn1ng - are you literally just wanting txId | utc
as a first-seen?
Would you also want scId | utc
? Mind you, that could be a huge chunk of data and would be a 2nd order insertion.
Maybe even blockId | height | utc
?
Then you could track how many orphans occur.
That said, each of these indexes would be re-org independent, and would continuously persist (obviously).
That said, all these could be optional.
From documentation of bitcore
timestampindex
This index maps timestamps with block hashes and is useful for searching blocks by date instead of by height. This is useful for a block explorer that will give search options by date. However it should be noted that the timestamps of blocks can be out of order, as there is a tolerance of around 2 hours that a timestamp of block is allowed to be set.
So it's not first seen, but really time -> blockhash.
You deleted your message :) but well... bitcore uses it for displaying blocks on certain date, that's all
https://insight.bitpay.com/blocks-date/2017-03-06
But really it's not a must-have feature in the end, I guess
@runn1ng sorry, I realised you already addressed my question with:
This is useful for a block explorer that will give search options by date
Apologies for the confusion.
Added in https://github.com/bitcoinjs/indexd/pull/37 (query functions are missing, but, you can trivially make a PR! :) )
@runn1ng I assume this is what you mean by
timestamp
index? I'll push up this, as its only in my local fork ofindexd
atm...