Log timestamp
Add timestamp to each line of debug.log.
That’s fine with me. I’ll close this pull request, and hope that someone submits the human-readable timestamp patch instead.
Also: there was a privacy concern related to universal timestamps, so maybe add an option -logtimestamp, thereby defaulting the timestamps /off/ by default.
Actually, I plan to rework the logging slightly, so I’ll add the optional timestamp when I do that. And since I’m adding a flag, there’s no reason it can’t be ‘-logtimestamp=<off | numeric | human-readable>’.
What was the privacy concern, do you remember?
My plan is to modify OutputDebugStringF to accept two parameters, one indicating the verbosity level (off, critical error, error, warning, info, debug, verbose) and the other a bitmask enum indicating the area the log entry relates to, such as Mining, Transactions, Blocks, etc. (I got tired of wading through quite literally thousands of IRC log messages, and generating a log file around 1.2M per day). Oh, and then change all ‘printf’ statements to OutputDebugStringF( x, y where x and y make sense given the context.
I already have that code in my local source, but it’s based on the previous release and it’s currently hard-coded to Debug, Mining.
Jeff, I’ve been working on the code as mentioned. Can you elaborate on the privacy concerns? I don’t really see how the timestamps in the log could be a privacy concern.
Quote from IRC,
I wondered it might be something along those lines. As a side note, it would be an interesting challenge to figure out how many nodes you’d have to subpoena in order to determine with any degree of certainty the origin of a coin.
My revisions to OutputDebugStringF will, by default, NOT log anything to do with individual transactions. Basically, only infrequent status messages such as the hash rate, warnings, errors and critical errors will be logged by default.
Actually, before I go too far down the road with it, I think I’ll open a discussion on the Bitcoin forums to get feedback on my ideas. Maybe someone there might have some additional thoughts on privacy issues.
In general, incremental approaches tend to work better than grand rewrites, so I would rather test the waters with BlueMatt’s patch. Then, we can look into something more invasive if the community is happy with the general direction.