3b6d1b61d3
6f2c4fd0775a9c45eacc4bab8f138528852fdf44 netinfo: add user help documentation (Jon Atack) Pull request description: This is the help doc commit of #20764 without the rest of the PR or anything new since the 0.21.0 branch-off in order to target giving users a -netinfo help doc for 0.21. - to test the new help ``` $ ./src/bitcoin-cli -netinfo help ``` - to see the updated short help ``` $ ./src/bitcoin-cli -help | grep -A4 netinfo ``` <details><summary><code>-netinfo</code> help doc</summary><p> ``` $ ./src/bitcoin-cli -netinfo help -netinfo level "help" Returns a network peer connections dashboard with information from the remote server. Under the hood, -netinfo fetches the data by calling getpeerinfo and getnetworkinfo. An optional integer argument from 0 to 4 can be passed for different peers listings. Pass "help" to see this detailed help documentation. If more than one argument is passed, only the first one is read and parsed. Suggestion: use with the Linux watch(1) command for a live dashboard; see example below. Arguments: 1. level (integer 0-4, optional) Specify the info level of the peers dashboard (default 0): 0 - Connection counts and local addresses 1 - Like 0 but with a peers listing (without address or version columns) 2 - Like 1 but with an address column 3 - Like 1 but with a version column 4 - Like 1 but with both address and version columns 2. help (string "help", optional) Print this help documentation instead of the dashboard. Result: * The peers listing in levels 1-4 displays all of the peers sorted by direction and minimum ping time: Column Description ------ ----------- <-> Direction "in" - inbound connections are those initiated by the peer "out" - outbound connections are those initiated by us type Type of peer connection "full" - full relay, the default "block" - block relay; like full relay but does not relay transactions or addresses net Network the peer connected through ("ipv4", "ipv6", "onion", "i2p", or "cjdns") mping Minimum observed ping time, in milliseconds (ms) ping Last observed ping time, in milliseconds (ms) send Time since last message sent to the peer, in seconds recv Time since last message received from the peer, in seconds txn Time since last novel transaction received from the peer and accepted into our mempool, in minutes blk Time since last novel block passing initial validity checks received from the peer, in minutes age Duration of connection to the peer, in minutes asmap Mapped AS (Autonomous System) number in the BGP route to the peer, used for diversifying peer selection (only displayed if the -asmap config option is set) id Peer index, in increasing order of peer connections since node startup address IP address and port of the peer version Peer version and subversion concatenated, e.g. "70016/Satoshi:21.0.0/" * The connection counts table displays the number of peers by direction, network, and the totals for each, as well as a column for block relay peers. * The local addresses table lists each local address broadcast by the node, the port, and the score. Examples: Connection counts and local addresses only > bitcoin-cli -netinfo Compact peers listing > bitcoin-cli -netinfo 1 Full dashboard > bitcoin-cli -netinfo 4 Full live dashboard, adjust --interval or --no-title as needed (Linux) > watch --interval 1 --no-title ./src/bitcoin-cli -netinfo 4 See this help > bitcoin-cli -netinfo help ``` </p></details> ACKs for top commit: laanwj: ACK 6f2c4fd0775a9c45eacc4bab8f138528852fdf44 Tree-SHA512: dd49b1ce65546dacfb8ba9f9d57de0eae55560fd05533cf26c0b5d6ec65bf1de789c3287e90a0e2f47707532fab2fe62919a4192a7ffd58ac8eec18293e9aaeb
Bitcoin Core integration/staging tree
What is Bitcoin?
Bitcoin is an experimental digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Bitcoin Core is the name of open source software which enables the use of this currency.
For more information, as well as an immediately usable, binary version of the Bitcoin Core software, see https://bitcoincore.org/en/download/, or read the original whitepaper.
License
Bitcoin Core is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.
Development Process
The master branch is regularly built (see doc/build-*.md for instructions) and tested, but it is not guaranteed to be
completely stable. Tags are created
regularly from release branches to indicate new official, stable release versions of Bitcoin Core.
The https://github.com/bitcoin-core/gui repository is used exclusively for the development of the GUI. Its master branch is identical in all monotree repositories. Release branches and tags do not exist, so please do not fork that repository unless it is for development reasons.
The contribution workflow is described in CONTRIBUTING.md and useful hints for developers can be found in doc/developer-notes.md.
Testing
Testing and code review is the bottleneck for development; we get more pull requests than we can review and test on short notice. Please be patient and help out by testing other people's pull requests, and remember this is a security-critical project where any mistake might cost people lots of money.
Automated Testing
Developers are strongly encouraged to write unit tests for new code, and to
submit new unit tests for old code. Unit tests can be compiled and run
(assuming they weren't disabled in configure) with: make check. Further details on running
and extending unit tests can be found in /src/test/README.md.
There are also regression and integration tests, written
in Python, that are run automatically on the build server.
These tests can be run (if the test dependencies are installed) with: test/functional/test_runner.py
The CI (Continuous Integration) systems make sure that every pull request is built for Windows, Linux, and macOS, and that unit/sanity tests are run automatically.
Manual Quality Assurance (QA) Testing
Changes should be tested by somebody other than the developer who wrote the code. This is especially important for large or high-risk changes. It is useful to add a test plan to the pull request description if testing the changes is not straightforward.
Translations
Changes to translations as well as new translations can be submitted to Bitcoin Core's Transifex page.
Translations are periodically pulled from Transifex and merged into the git repository. See the translation process for details on how this works.
Important: We do not accept translation changes as GitHub pull requests because the next pull from Transifex would automatically overwrite them again.
Translators should also subscribe to the mailing list.