Many sendcmpct messages are sent during UpdateActiveChain() #21903

During UpdateActiveChain(), many sendcmpct messages are sent after each tip update, repeatedly changing the announce node preferred.

Currently there's a check not to do this during IBD, but this is the wrong check - it ought to check that the Tip is not being updated by more than 1 block instead, or IsIBD() should be changed to return true while the Tip is still far behind the best known header (e.g. blocks are still being announced long before the tip catches up with the best header, which also seems premature).

Example logs:-

2021-05-10T11:56:04.944 Leaving InitialBlockDownload (latching to false) 2021-05-10T11:56:08.729 UpdateTip: new best=00000000000000000009f53e6b366ae9f51e3b0aef2f75f65b9fde451097613b height=682745 version=0x20000004 log2_work=92.865676 tx=640715687 date='2021-05-09T12:11:32Z' progress=0.999532 cache=68.2MiB(501118txo) 2021-05-10T11:56:11.293 send sendcmpct (announce) ver=2 peer=5 2021-05-10T11:56:11.336 UpdateTip: new best=000000000000000000005b47ed3df23276ab4ba2c10aa94c10dcb13ec1e507a7 height=682746 version=0x20000000 log2_work=92.865690 tx=640717020 date='2021-05-09T12:13:03Z' progress=0.999533 cache=68.7MiB(505500txo) 2021-05-10T11:56:15.732 UpdateTip: new best=00000000000000000007e71ed0aa02c3dea105faa75b4ce8b9634942109f1dc1 height=682747 version=0x20a00000 log2_work=92.865704 tx=640719237 date='2021-05-09T12:19:40Z' progress=0.999535 cache=69.7MiB(513742txo) 2021-05-10T11:56:20.473 send sendcmpct (announce) ver=2 peer=1 2021-05-10T11:56:20.509 UpdateTip: new best=0000000000000000000846457710ce4f52a8b47f33e1a3ebb00195210e123342 height=682748 version=0x20400004 log2_work=92.865718 tx=640720955 date='2021-05-09T12:25:23Z' progress=0.999537 cache=70.6MiB(520720txo) 2021-05-10T11:56:24.309 send sendcmpct (announce) ver=2 peer=2 2021-05-10T11:56:24.356 UpdateTip: new best=0000000000000000000ab6d09b8db5256257ea88259485063ed42fe353a6e301 height=682749 version=0x27ffe000 log2_work=92.865733 tx=640723159 date='2021-05-09T12:41:06Z' progress=0.999542 cache=71.7MiB(530167txo) 2021-05-10T11:56:28.833 send sendcmpct (no announce) ver=2 peer=5 2021-05-10T11:56:28.834 send sendcmpct (announce) ver=2 peer=4 2021-05-10T11:56:28.873 UpdateTip: new best=000000000000000000017f79e022ecc84fe26c5f89f77817cbf0c4825db6658f height=682750 version=0x20c00000 log2_work=92.865747 tx=640725094 date='2021-05-09T12:52:38Z' progress=0.999545 cache=72.7MiB(538431txo) 2021-05-10T11:56:33.270 send sendcmpct (no announce) ver=2 peer=1 2021-05-10T11:56:33.270 send sendcmpct (announce) ver=2 peer=5 2021-05-10T11:56:33.309 UpdateTip: new best=00000000000000000008a24ce89de3294cd852dadc30efbec3376d60472940f3 height=682751 version=0x20000004 log2_work=92.865761 tx=640727245 date='2021-05-09T13:00:27Z' progress=0.999548 cache=73.7MiB(545937txo) 2021-05-10T11:56:41.470 UpdateTip: new best=00000000000000000001a28c4338e9ce47f4c2ccf3669ab00a9cfe084f78de00 height=682752 version=0x20c00004 log2_work=92.865775 tx=640728096 date='2021-05-09T13:02:29Z' progress=0.999549 cache=74.7MiB(554524txo) 2021-05-10T11:56:46.222 send sendcmpct (no announce) ver=2 peer=2 2021-05-10T11:56:46.223 send sendcmpct (announce) ver=2 peer=1 2021-05-10T11:56:46.258 UpdateTip: new best=00000000000000000008c7fd38ae162d18a7a26c03b6641cd557493ed364c090 height=682753 version=0x20000000 log2_work=92.865789 tx=640730240 date='2021-05-09T13:20:22Z' progress=0.999554 cache=75.5MiB(560963txo) 2021-05-10T11:56:49.882 send sendcmpct (no announce) ver=2 peer=4 2021-05-10T11:56:49.882 send sendcmpct (announce) ver=2 peer=2 2021-05-10T11:56:49.911 UpdateTip: new best=0000000000000000000580bff00e687d5b2edc84d87afb4c7a69c56b1d748614 height=682754 version=0x20800000 log2_work=92.865803 tx=640731326 date='2021-05-09T13:22:48Z' progress=0.999555 cache=76.2MiB(566899txo) 2021-05-10T11:56:56.073 send sendcmpct (no announce) ver=2 peer=5 2021-05-10T11:56:56.073 send sendcmpct (announce) ver=2 peer=4 2021-05-10T11:56:56.110 UpdateTip: new best=0000000000000000000468ea063eacc56d9d1760712e63b0a9fffdc8f1b6bfb8 height=682755 version=0x20000000 log2_work=92.865818 tx=640732785 date='2021-05-09T13:26:21Z' progress=0.999556 cache=77.1MiB(573757txo) 2021-05-10T11:57:02.756 send sendcmpct (no announce) ver=2 peer=1 2021-05-10T11:57:02.757 send sendcmpct (announce) ver=2 peer=5 2021-05-10T11:57:02.790 UpdateTip: new best=000000000000000000024d5a936bf40d69d7acf803d5f97a37748672abe2e009 height=682756 version=0x37ffe000 log2_work=92.865832 tx=640733404 date='2021-05-09T13:29:25Z' progress=0.999557 cache=78.0MiB(581220txo) 2021-05-10T11:57:08.495 send sendcmpct (no announce) ver=2 peer=2 2021-05-10T11:57:08.496 send sendcmpct (announce) ver=2 peer=6

So the main risk here is that more P2P bandwidth than necessary is being used on sendcmpct messages?

IsIBD() should be changed to return true while the Tip is still far behind the best known header

IsInitialBlockDownload() also checks if the timestamp in the tip is less than 24 hours old (DEFAULT_MAX_TIP_AGE) which I think means that at most we're probably only sending around 144 sendcmpct before we really need to.

I used invalidateblock/reconsiderblock to re-enter IBD and re-download the last 1000 blocks with net logging, and the only sendcmpct messages I saw go out were to new peers during handshake.

The feature request didn't seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.

Closing due to lack of interest and direction. Pull requests with improvements are always welcome.