-
Notifications
You must be signed in to change notification settings - Fork 35.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Log timestamp #91
Log timestamp #91
Conversation
I like the idea of timestamping log entries. Personally, though, I'd rather see a human-readable timestamp. |
I agree with jhyslop: TheBlueMatt@fe460d4 |
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. |
OK. My changes are orthogonal to BlueMatt's, so it will be simple to merge. |
…TestNet build have been consolidated here.
Improve the transaction size (and fee) prediction of coin control.
Updated some old Bitcoin constants and other stuff
…header Added tests for the state and utxo roots, fixed a typo in CBlockHeader
redirect question removed
Updated version to 1.4.0
b8e5d0d qt: Handle exceptions in SendCoinsDialog::sendButtonClicked slot (Hennadii Stepanov) 1ac2bc7 qt: Handle exceptions in TransactionView::bumpFee slot (Hennadii Stepanov) bc00e13 qt: Handle exceptions in WalletModel::pollBalanceChanged slot (Hennadii Stepanov) eb6156b qt: Handle exceptions in BitcoinGUI::addWallet slot (Hennadii Stepanov) f7e260a qt: Add GUIUtil::ExceptionSafeConnect function (Hennadii Stepanov) 64a8755 qt: Add BitcoinApplication::handleNonFatalException function (Hennadii Stepanov) af7e365 qt: Make PACKAGE_BUGREPORT link clickable (Hennadii Stepanov) Pull request description: This PR is an alternative to #18897, and is based on Russ' [idea](#18897 (review)): > IMO it would be nice to have a followup PR that eliminated the one-line forwarding methods ... Related issues - #91 - #18643 Qt docs: https://doc.qt.io/qt-5.12/exceptionsafety.html#exceptions-in-client-code With this PR the GUI handles the wallet-related exception, and: - display it to a user: ![Screenshot from 2021-04-01 02-55-59](https://user-images.githubusercontent.com/32963518/113226183-33ff8480-9298-11eb-8fe6-2168834ab09a.png) - prints a message to `stderr`: ``` ************************ EXCEPTION: 18NonFatalCheckError wallet/wallet.cpp:2677 (IsCurrentForAntiFeeSniping) Internal bug detected: '!chain.findBlock(block_hash, FoundBlock().time(block_time))' You may report this issue here: https://github.com/bitcoin/bitcoin/issues bitcoin in QPushButton->SendCoinsDialog ``` - writes a message to the `debug.log` - and, if the exception is a non-fatal error, leaves the main window running. ACKs for top commit: laanwj: Code review ACK b8e5d0d ryanofsky: Code review ACK b8e5d0d. This is great! I think more improvements are possible but implementation is very clean and I love how targeted each commit is. Changes since last review: adding more explanatory text, making links clickable, reorganizing. Tree-SHA512: a9f2a2ee8e64b993b0dbc454edcbc39c68c8852abb5dc1feb58f601c0e0e8014dca81c72733aa3fb07b619c6f49b823ed20c7d79cc92088a3abe040ed2149727
Add timestamp to each line of debug.log.