Log timestamp #91

Add timestamp to each line of debug.log.

I like the idea of timestamping log entries. Personally, though, I'd rather see a human-readable timestamp.

I agree with jhyslop: https://github.com/TheBlueMatt/bitcoin/commit/fe460d47b06d10095b882d7a9ea8a98ad0079bbd

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, <gavinandresen> Concern was from satoshi... I shouldn't try to read his mind, but I THINK what he was thinking is somebody subpoena's N bitcoin services for their debug.logs to try to figure out where transactions were originating

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.

OK. My changes are orthogonal to BlueMatt's, so it will be simple to merge.