Store first seen time in block audit#5567
Conversation
5cdf3c7 to
21b3ed2
Compare
21b3ed2 to
1a75e3e
Compare
mononaut
left a comment
There was a problem hiding this comment.
Tested @ [1a75e3e]
A couple of minor issues in the comments, but otherwise looks good!
(1) I ended up with some very late firstSeen times on a bunch of recent blocks while Core was catching up after a restart.
I guess that's technically correct since those were the times my node first saw the block headers, but it might be worth applying some sanity checks to the timestamps we choose to index.
(2) It would be neat to backfill the firstSeen timestamps for older audits as far as we have data available in the debug.log, perhaps in a new indexing task. We can save that for another PR though.
|
also, are we sure we want to store the timestamp in the |
Isn't the long term plan to integrate the |
yeah that's a good point. I was just thinking that this feature doesn't necessarily overlap with the rest of the block audit table. e.g. I could imagine wanting to index block first seen times even with audits disabled, or to index that data for blocks we didn't/couldn't audit, like those added during a reorg. |
Right, the rationale for storing the timestamp in |
83e05a6 to
2eb3f47
Compare
Good point, but how strict should we be with the sanitizing? Even if we require the first seen time to be at most 1-2 hours after the block timestamp, we could end up with some false positives. But with such a loose interval I’m wondering if the sanitizing would be useful at all. |
|
fair enough. in that case let's index the data as it appears in the logs, and we can always clean it up on the client side later. |
cbbce03 to
229a756
Compare
|
Added |
mononaut
left a comment
There was a problem hiding this comment.
looks good! just a few small issues left
229a756 to
dd0542b
Compare
Partially implements #5543
This PR introduces a new
first_seenfield to the block audit, which records the timestamp of when a block was first observed. The timestamp is extracted from theSaw new header ...entries in Core'sdebug.log, with support for both second and microsecond precision.To enable this functionality:
"DEBUG_LOG_PATH": "/path/to/bitcoin/debug.log"to the backend config-logtimemicros=1tobitcoin.conffor microsecond precision (optional)I will make a follow-up PR to use the first seen data in the frontend later on when this has been running for a few days.