There are cases where the peer status is not updated forever #22898

I tested using regtest for cases where the peer status was not updated.

Test method: I used bitcoin-22.0rc3-win64.zip and bitcoin-22.0rc3-x86_64-linux-gnu.tar.gz. (However, this problem is similar with bitcoin v0.20.0.) PC-A (windows) has a blockchain up to height 3600. PC-B (linux) boots from height 0. Both set -debug=net. I set addnode=192.168.11.13(IP address of PC-B) in bitcoin.conf of PC-A. On PC-A, I ran a python program that generates blocks every 10 seconds for 90 minutes.

Test results: The "Synced Headers" and "Synced Blocks" for peer 0 (192.168.11.13) remained "Unknown" until the end, as shown in the following figure.

On the other hand, as shown in the following figure, the inbound peer 1 was updated once every two minutes on average.

As shown in the attachment, PC-B runs "Send Messages: sending header" on peer 1 once every two minutes on average, but never on peer 0. SendMessages_sending_header.txt

Measures: If PC-B receives a cmpctblock from peer 0 ("received: cmpctblock (261 bytes) peer = 0"), shouldn't it run a "sending header" on peer 0 after successfully adding a new block? Alternatively, peer 0 should not be excluded when executing "Send Messages: sending header" on a regular basis.

Question: Which constant determines the execution interval of "Send Messages: sending header" which is 2 minutes on average? Is it "PING_INTERVAL = 2 * 60"? Please tell me the provisional countermeasures. I want to try it.

A 30-minute follow-up test was conducted from height 4213. The result is the same, the state of peer 0 on PC-A has not been updated since the start. Since there are three peers this time, three figures are attached.

A part of debug.log of PC-B is shown below.

2021-09-06T10:37:59Z received: cmpctblock (261 bytes) peer=0
2021-09-06T10:37:59Z received: blocktxn (33 bytes) peer=0
2021-09-06T10:37:59Z UpdateTip: new best=60d4ec70ce3f1aa955b6bc9ab2334a781d217e3270c749056a4258e027d377c5 height=4336 version=0x20000000 log2_work=13.082482 tx=6354 date='2021-09-06T10:37:59Z' progress=1.000000 cache=0.0MiB(123txo)
2021-09-06T10:37:59Z SendMessages: sending header 60d4ec70ce3f1aa955b6bc9ab2334a781d217e3270c749056a4258e027d377c5 to peer=2
2021-09-06T10:37:59Z sending headers (82 bytes) peer=2
2021-09-06T10:37:59Z SendMessages: sending header 60d4ec70ce3f1aa955b6bc9ab2334a781d217e3270c749056a4258e027d377c5 to peer=1
2021-09-06T10:37:59Z sending headers (82 bytes) peer=1
2021-09-06T10:38:09Z received: cmpctblock (261 bytes) peer=0
2021-09-06T10:38:09Z received: blocktxn (33 bytes) peer=0
2021-09-06T10:38:09Z UpdateTip: new best=3f6f0abf9343d5de4c5378754da63326094d05b0c05aa5bdd87a8ac1ba726141 height=4337 version=0x20000000 log2_work=13.082814 tx=6355 date='2021-09-06T10:38:09Z' progress=1.000000 cache=0.0MiB(124txo)
2021-09-06T10:38:09Z received: headers (82 bytes) peer=1
2021-09-06T10:38:09Z received: headers (82 bytes) peer=2
2021-09-06T10:38:16Z sending ping (8 bytes) peer=2
2021-09-06T10:38:16Z received: pong (8 bytes) peer=2
2021-09-06T10:38:16Z received: ping (8 bytes) peer=2
2021-09-06T10:38:16Z sending pong (8 bytes) peer=2

The block is always received from peer 0. "SendMessages: sending header" is always executed after "UpdateTip: new best". At this time, it is transmitted to peers 1 and 2, but never to peer 0. What distinguishes peer 0? Receiving the block is the only factor that distinguishes it from others. Where is this logic written in the code?

I have created a PR to solve this problem. https://github.com/bitcoin/bitcoin/pull/22913

On PC-A, I ran a python program that generates blocks every 10 seconds for 90 minutes.

This is impossible for us to reproduce. Please write a (functional) test, or exact steps to reproduce. (You can start several nodes on localhost, so no need for several PCs).

Also, is this a GUI issue, an RPC issue, or a P2P issue?

@MarcoFalke This is a p2p issue. The current code is designed not to send headers to the peer from that we received new blocks or headers. Therefore, it looks like this node is delayed from the other node.

See # 22913 for more details.

Closing for now given the lack of clear steps to reproduce, and the accompanying change was closed: #22913.