It looks like a5cc9e28f9e125a62168dcbe0b3484d098e56c1f should be part of 1893c907eac1e52294add6e059f192eb13702829 & ad5ea77d5dde3fb40dd4701ea0b92e445e060ef0 rather than a separate commit.

How is it determined when to add new information and/or verbosity levels? Given they are additive, it seems unsustainable to just keep adding new levels and more info.

It looks like a5cc9e2 should be part of 1893c90 & ad5ea77 rather than a separate commit.

Done!

How is it determined when to add new information and/or verbosity levels? Given they are additive, it seems unsustainable to just keep adding new levels and more info.

Right, the data provided by getpeerinfo seems to be the upper bound, and apart from the bytes sent/received objects, there are only a handful of remaining fields. My current thinking is to orient levels 1-4 to node operators, and to use level 5 for data more suited to dev/testing. Open to feedback, of course.

Combined the help into the first two commits as suggested by @fanquake and changed the help as follows: git diff a5cc9e2 a52c94c

diff --git a/src/bitcoin-cli.cpp b/src/bitcoin-cli.cpp
index 4c3cc22dfc..5a0371e3de 100644
--- a/src/bitcoin-cli.cpp
+++ b/src/bitcoin-cli.cpp
@@ -592,7 +592,7 @@ public:
         "                                  2 - Like 1 but with an address column\n"
         "                                  3 - Like 1 but with a version column\n"
         "                                  4 - Like 1 but with both address and version columns\n"
-        "                                  5 - Like 4 but with additional statistics in the peers listing (addrl, addrp)\n"
+        "                                  5 - Like 4 but with additional data for development and testing purposes\n"

tACK a52c94c

macOS 11.4

One nit:

The data repaints if it detects a window resize - but if the user uses <Command> + R to "reload" the window - the data doesn't automatically repaint. Not a huge issue. Note the macOS 11 Terminal has repurposed <Command> + R for "Allow mouse reporting" but apps like iTerm still use <Command> + R for "Reset"

One request:

If the terminal listened for up arrows and down arrows to change data info resolution - that would be awesome.

I'm really not convinced these numbers are sufficiently important to turn into a new field, unless the expectation is that many more things will be added to it.

Thanks for the feedback everyone. Droppied the middle two commits; punting on adding a new level until or if there's a clearer need.

Diff: git range-diff 2b5563b a52c94c 936d8ff

code review and tested reACK 936d8ff49beeac5e0c77a87618e021b09d55c7a1

Concept ACK

Thanks for improving this feature: -netinfo is great addition to the toolbox! :)

Thanks @Zero-1729! A propos displaying zeroes, see #22501 (comment).

tACK 936d8ff49beeac5e0c77a87618e021b09d55c7a1

Thanks @klementtan, @vasild, @Zero-1729 and @jarolrod for the ACKs!

I've pushed an update for these reasons:

• to indicate peers that requested we not relay transactions, i.e. relaytxes is false
• to indicate peers we don't relay addresses to, i.e. addr_relay_enabled is false (this is a new getpeerinfo field and required rebasing here)
• added null checking on these new nodestatestats addr fields to avoid UniValue JSON parsing errors
• inversed the order of the addrp and addrl columns and moved them to the left of the age column, so that age is next to id
• updated the PR title and description

Updated per #22501 (comment) review feedback by @Zero-1729 (thanks!)

diff --git a/src/bitcoin-cli.cpp b/src/bitcoin-cli.cpp
index f960737bfd..718ad5dcef 100644
--- a/src/bitcoin-cli.cpp
+++ b/src/bitcoin-cli.cpp
@@ -536,7 +536,7 @@ public:
                     PingTimeToString(peer.ping),
                     peer.last_send ? ToString(m_time_now - peer.last_send) : "",
                     peer.last_recv ? ToString(m_time_now - peer.last_recv) : "",
-                    peer.last_trxn ? ToString((m_time_now - peer.last_trxn) / 60) : peer.is_block_relay ? "." : "",
+                    peer.last_trxn ? ToString((m_time_now - peer.last_trxn) / 60) : peer.is_block_relay ? "*" : "",
                     peer.last_blck ? ToString((m_time_now - peer.last_blck) / 60) : "",
                     strprintf("%s%s", peer.is_bip152_hb_to ? "." : " ", peer.is_bip152_hb_from ? "*" : " "),
                     m_max_addr_processed_length, // variable spacing
@@ -627,7 +627,7 @@ public:
         "  send     Time since last message sent to the peer, in seconds\n"
         "  recv     Time since last message received from the peer, in seconds\n"
         "  txn      Time since last novel transaction received from the peer and accepted into our mempool, in minutes\n"
-        "           \".\" - the peer requested we not relay transactions to it (relaytxes is false)\n"
+        "           \"*\" - the peer requested we not relay transactions to it (relaytxes is false)\n"
         "  blk      Time since last novel block passing initial validity checks received from the peer, in minutes\n"
         "  hb       High-bandwidth BIP152 compact block relay\n"
         "           \".\" (to)   - we selected the peer as a high-bandwidth peer\n"

re crAck and tAck 218862a

Thanks for all the reviews! I updated the PR description with a current screenshot. One peer seems to be spamming addresses a bit:

<->   type   net  mping   ping send recv  txn  blk  hb addrp addrl  age  asmap   id address                                                             version
out   full  ipv4    204    214    0    0    0          14958 31870 2334   6830  296 178.200.242.132:8333                                                70016/Satoshi:0.21.1/

This has many ACKs, seems ready for merge?

Code review and tested ACK 218862a

Concept ACK