48c8a9b96453ca429b38fc5d5181a310ae5a93bf net_processing: log txrelay flag from version message (Anthony Towns) 98fab37ca0517bfe58296e47266cd5bd112e90bf net: use peer=N instead of from=N in debug log (Anthony Towns) 12302105bb0bf14721e91b7a3a9d1bf83c8d4154 net_processing: additional debug logging for ignored messages (Anthony Towns) f7edea3b7c873d6c9bcd50cf528349ef84961a75 net: make debug logging conditional on -debug=net (Anthony Towns) a410ae8cb09f1b809755316566f9e6bccd41c0c4 net, net_processing: log disconnect reasons with -debug=net (Anthony Towns)
Pull request description:
A few changes to -debug=net logging:
- always log when disconnecting a peer
- only log various connection errors when -debug=net is enabled, since errors from random untrusted peers is completely expected
- log when ignoring a message due to violating protocol (primarily to make it easier to debug other implementations)
- use "peer=123" rather than "from 123" to make grepping logs a bit easier
- log the value of the bip-37
fRelayfield in version messages both when sending and receiving a version message
ACKs for top commit: jnewbery: ACK 48c8a9b96453ca429b38fc5d5181a310ae5a93bf MarcoFalke: re-ACK 48c8a9b96453ca429b38fc5d5181a310ae5a93bf only change is rebase 🚓 practicalswift: re-ACK 48c8a9b96453ca429b38fc5d5181a310ae5a93bf
Tree-SHA512: 6ac530d883dffc4fd7fe20b1dc5ebb5394374c9b499aa7a253eb4a3a660d8901edd72e5ad21ce4a2bf71df25e8f142087755f9756f3497f564ef453a7e9246c1
<!-- *** Please remove the following help text before submitting: *** Pull requests without a rationale and clear improvement may be closed immediately. GUI-related pull requests should be opened against https://github.com/bitcoin-core/gui first. See CONTRIBUTING.md -->
<!-- Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly: * Any test improvements or new tests that improve coverage are always welcome. * All other changes should have accompanying unit tests (see `src/test/`) or functional tests (see `test/`). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change. * Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed. * Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible. * Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they *significantly* improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the [developer notes](/doc/developer-notes.md), stylistic code changes are usually rejected. -->
<!-- Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. -->