P2P block inv notification bug #17451

Connecting with a whitebinded peer on localshost to P2P, Bitcoin Core selectively sends block invs after generatetoaddress 10 address RPC command.

Expected behavior

Send block invs for every block generated in the proper order.

To reproduce

1. Connect to bitcoind with a whitebinded local peer and listen to the invs.
2. Generate 10 blocks with RPC in one command: generatetoaddress 10 address
3. Only get some invs. On my computer it's 7, on @lontivero's computer it's 2.

System information

Ubuntu 18.04, Windows 10, Bitooin Core 0.18.1

Below is the log that shows that 10 blocks are created but only 9 inv messages are sent. I've run our test many times and 9 is the maximum number of invs messages that I've received when using generatetoaddress 10 address.

However, if we introduce a one second wait in between of each block creation, the 10 invs are sent as expected, this is:

generatetoaddress 1 address
sleep 1
generatetoaddress 1 address
sleep 1
generatetoaddress 1 address
sleep 1
...
...

Also, the node had time to send the inv message for the latest block because there are 2 minutes between the last inv message and the rpc stop request.

Log

2019-11-12T09:28:01Z Bitcoin Core version v0.18.1 (release build)
2019-11-12T09:28:01Z InitParameterInteraction: parameter interaction: -whitebind set -> setting -listen=1
2019-11-12T09:28:01Z Validating signatures for all blocks.
2019-11-12T09:28:01Z Setting nMinimumChainWork=0000000000000000000000000000000000000000000000000000000000000000
2019-11-12T09:28:01Z Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation
2019-11-12T09:28:01Z Using RdSeed as additional entropy source
2019-11-12T09:28:01Z Using RdRand as an additional entropy source
2019-11-12T09:28:01Z Default data directory /home/lontivero/.bitcoin
2019-11-12T09:28:01Z Using data directory /home/lontivero/.walletwasabi/tests/P2pBasedTests/TrustedNotifierNotifiesBlockAsync/regtest
2019-11-12T09:28:01Z Config file: /home/lontivero/.walletwasabi/tests/P2pBasedTests/TrustedNotifierNotifiesBlockAsync/bitcoin.conf
2019-11-12T09:28:01Z Using at most 125 automatic connections (1048576 file descriptors available)
2019-11-12T09:28:01Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2019-11-12T09:28:01Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2019-11-12T09:28:01Z Using 4 threads for script verification
2019-11-12T09:28:01Z scheduler thread start
2019-11-12T09:28:01Z HTTP: creating work queue of depth 16
2019-11-12T09:28:01Z Starting RPC
2019-11-12T09:28:01Z Starting HTTP RPC server
2019-11-12T09:28:01Z Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcauth for rpcauth auth generation.
2019-11-12T09:28:01Z HTTP: starting 4 worker threads
2019-11-12T09:28:01Z Using wallet directory /home/lontivero/.walletwasabi/tests/P2pBasedTests/TrustedNotifierNotifiesBlockAsync/regtest/wallets
2019-11-12T09:28:01Z init message: Verifying wallet(s)...
2019-11-12T09:28:01Z Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2019-11-12T09:28:01Z Using wallet /home/lontivero/.walletwasabi/tests/P2pBasedTests/TrustedNotifierNotifiesBlockAsync/regtest/wallets
2019-11-12T09:28:01Z BerkeleyEnvironment::Open: LogDir=/home/lontivero/.walletwasabi/tests/P2pBasedTests/TrustedNotifierNotifiesBlockAsync/regtest/wallets/database ErrorFile=/home/lontivero/.walletwasabi/tests/P2pBasedTests/TrustedNotifierNotifiesBlockAsync/regtest/wallets/db.log
2019-11-12T09:28:01Z init message: Loading banlist...
2019-11-12T09:28:01Z Loaded 0 banned node ips/subnets from banlist.dat  0ms
2019-11-12T09:28:01Z net: setting try another outbound peer=false
2019-11-12T09:28:01Z Cache configuration:
2019-11-12T09:28:01Z * Using 2.0 MiB for block index database
2019-11-12T09:28:01Z * Using 56.0 MiB for transaction index database
2019-11-12T09:28:01Z * Using 8.0 MiB for chain state database
2019-11-12T09:28:01Z * Using 384.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
2019-11-12T09:28:01Z init message: Loading block index...
2019-11-12T09:28:01Z Opening LevelDB in /home/lontivero/.walletwasabi/tests/P2pBasedTests/TrustedNotifierNotifiesBlockAsync/regtest/blocks/index
2019-11-12T09:28:01Z Opened LevelDB successfully
2019-11-12T09:28:01Z Using obfuscation key for /home/lontivero/.walletwasabi/tests/P2pBasedTests/TrustedNotifierNotifiesBlockAsync/regtest/blocks/index: 0000000000000000
2019-11-12T09:28:01Z LoadBlockIndexDB: last block file = 0
2019-11-12T09:28:01Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=1452, size=377070, heights=0...1451, time=2011-02-02...2019-11-12)
2019-11-12T09:28:01Z Checking all blk files are present...
2019-11-12T09:28:01Z Opening LevelDB in /home/lontivero/.walletwasabi/tests/P2pBasedTests/TrustedNotifierNotifiesBlockAsync/regtest/chainstate
2019-11-12T09:28:01Z Opened LevelDB successfully
2019-11-12T09:28:01Z Using obfuscation key for /home/lontivero/.walletwasabi/tests/P2pBasedTests/TrustedNotifierNotifiesBlockAsync/regtest/chainstate: a12e61b4a55d5787
2019-11-12T09:28:01Z Loaded best chain: hashBestChain=699739cba6c3cb2192aa8cf046c9f3568ada62ec8b2b3d72d3a81682cbe6a942 height=1451 date=2019-11-12T09:25:03Z progress=1.000000
2019-11-12T09:28:01Z init message: Rewinding blocks...
2019-11-12T09:28:01Z init message: Verifying blocks...
2019-11-12T09:28:01Z Verifying last 6 blocks at level 3
2019-11-12T09:28:01Z [83%]...[99%]...[DONE].
2019-11-12T09:28:01Z No coin database inconsistencies in last 6 blocks (6 transactions)
2019-11-12T09:28:01Z  block index              59ms
2019-11-12T09:28:01Z Opening LevelDB in /home/lontivero/.walletwasabi/tests/P2pBasedTests/TrustedNotifierNotifiesBlockAsync/regtest/indexes/txindex
2019-11-12T09:28:01Z Opened LevelDB successfully
2019-11-12T09:28:01Z Using obfuscation key for /home/lontivero/.walletwasabi/tests/P2pBasedTests/TrustedNotifierNotifiesBlockAsync/regtest/indexes/txindex: 0000000000000000
2019-11-12T09:28:01Z init message: Loading wallet...
2019-11-12T09:28:01Z txindex thread start
2019-11-12T09:28:01Z Syncing txindex with block chain from height 1442
2019-11-12T09:28:01Z BerkeleyEnvironment::Open: LogDir=/home/lontivero/.walletwasabi/tests/P2pBasedTests/TrustedNotifierNotifiesBlockAsync/regtest/wallets/database ErrorFile=/home/lontivero/.walletwasabi/tests/P2pBasedTests/TrustedNotifierNotifiesBlockAsync/regtest/wallets/db.log
2019-11-12T09:28:01Z [default wallet] nFileVersion = 180100
2019-11-12T09:28:01Z [default wallet] Keys: 2012 plaintext, 0 encrypted, 2012 w/ metadata, 2012 total. Unknown wallet records: 0
2019-11-12T09:28:01Z txindex is enabled at height 1451
2019-11-12T09:28:01Z txindex thread exit
2019-11-12T09:28:01Z [default wallet] Wallet completed loading in              53ms
2019-11-12T09:28:01Z [default wallet] setKeyPool.size() = 2000
2019-11-12T09:28:01Z [default wallet] mapWallet.size() = 1111
2019-11-12T09:28:01Z [default wallet] mapAddressBook.size() = 11
2019-11-12T09:28:01Z mapBlockIndex.size() = 1452
2019-11-12T09:28:01Z nBestHeight = 1451
2019-11-12T09:28:01Z torcontrol thread start
2019-11-12T09:28:01Z Bound to 127.0.0.1:12911
2019-11-12T09:28:01Z init message: Loading P2P addresses...
2019-11-12T09:28:01Z Loaded 0 addresses from peers.dat  0ms
2019-11-12T09:28:01Z init message: Starting network threads...
2019-11-12T09:28:01Z net thread start
2019-11-12T09:28:01Z Imported mempool transactions from disk: 0 succeeded, 0 failed, 0 expired, 0 already there
2019-11-12T09:28:01Z dnsseed thread start
2019-11-12T09:28:01Z Loading addresses from DNS seeds (could take a while)
2019-11-12T09:28:01Z 0 addresses found from DNS seeds
2019-11-12T09:28:01Z dnsseed thread exit
2019-11-12T09:28:01Z addcon thread start
2019-11-12T09:28:01Z init message: Done loading
2019-11-12T09:28:01Z msghand thread start
2019-11-12T09:28:01Z Leaving InitialBlockDownload (latching to false)
2019-11-12T09:28:01Z opencon thread start
2019-11-12T09:28:01Z Added connection peer=0
2019-11-12T09:28:01Z connection from 127.0.0.1:39923 accepted
2019-11-12T09:28:01Z received: version (108 bytes) peer=0
2019-11-12T09:28:01Z sending version (102 bytes) peer=0
2019-11-12T09:28:01Z send version message: version 70015, blocks=1451, us=[::]:0, peer=0
2019-11-12T09:28:01Z sending verack (0 bytes) peer=0
2019-11-12T09:28:01Z receive version message: /WasabiClient:1.1.9.3/: version 70012, blocks=0, us=127.0.0.1:12911, peer=0
2019-11-12T09:28:01Z added time data, samples 2, offset +0 (+0 minutes)
2019-11-12T09:28:01Z sending alert (168 bytes) peer=0
2019-11-12T09:28:01Z received: verack (0 bytes) peer=0
2019-11-12T09:28:01Z sending sendheaders (0 bytes) peer=0
2019-11-12T09:28:01Z sending ping (8 bytes) peer=0
2019-11-12T09:28:02Z received: ping (8 bytes) peer=0
2019-11-12T09:28:02Z sending pong (8 bytes) peer=0
2019-11-12T09:28:02Z received: pong (8 bytes) peer=0
2019-11-12T09:28:02Z ThreadRPCServer method=generatetoaddress user=f8985cc2feca0c178e42c67adef33d6bbda6fd1b9f
2019-11-12T09:28:02Z CreateNewBlock(): block weight: 892 txs: 0 fees: 0 sigops 400
2019-11-12T09:28:02Z UpdateTip: new best=484096729b1785a0e7dac627a60adbffe87ee8db8b60fec0dffe5602b3dce390 height=1452 version=0x20000000 log2_work=11.504819 tx=1453 date='2019-11-12T09:28:02Z' progress=1.000000 cache=0.0MiB(1txo)
2019-11-12T09:28:02Z CreateNewBlock(): block weight: 892 txs: 0 fees: 0 sigops 400
2019-11-12T09:28:02Z UpdateTip: new best=32bd2a1aaac32d8fd2b47289c8da6d0458bd6a16b6bba2c8d1a027e07685c9b8 height=1453 version=0x20000000 log2_work=11.505812 tx=1454 date='2019-11-12T09:28:02Z' progress=1.000000 cache=0.0MiB(2txo)
2019-11-12T09:28:02Z CreateNewBlock(): block weight: 892 txs: 0 fees: 0 sigops 400
2019-11-12T09:28:02Z UpdateTip: new best=4845a8e32bbb6738ab46cb28d83782ebedf02a9e2e9dfdf65f415896063da7f1 height=1454 version=0x20000000 log2_work=11.506803 tx=1455 date='2019-11-12T09:28:02Z' progress=1.000000 cache=0.0MiB(3txo)
2019-11-12T09:28:02Z CreateNewBlock(): block weight: 892 txs: 0 fees: 0 sigops 400
2019-11-12T09:28:02Z UpdateTip: new best=6d2515a602daacab6142030f5f337e94a20ab76b09d6cf6abe84d00303c5791c height=1455 version=0x20000000 log2_work=11.507795 tx=1456 date='2019-11-12T09:28:02Z' progress=1.000000 cache=0.0MiB(4txo)
2019-11-12T09:28:02Z CreateNewBlock(): block weight: 892 txs: 0 fees: 0 sigops 400
2019-11-12T09:28:02Z UpdateTip: new best=6d7f3af9bbcc52e372717d9fbbd74334a5bafa91beaa8abf8a43f6e5454cae28 height=1456 version=0x20000000 log2_work=11.508785 tx=1457 date='2019-11-12T09:28:02Z' progress=1.000000 cache=0.0MiB(5txo)
2019-11-12T09:28:02Z CreateNewBlock(): block weight: 892 txs: 0 fees: 0 sigops 400
2019-11-12T09:28:02Z UpdateTip: new best=2f48479e01bb83271c316d718dc2ecf2dd35168fea0560ab7373991f72a36af4 height=1457 version=0x20000000 log2_work=11.509775 tx=1458 date='2019-11-12T09:28:02Z' progress=1.000000 cache=0.0MiB(6txo)
2019-11-12T09:28:02Z CreateNewBlock(): block weight: 892 txs: 0 fees: 0 sigops 400
2019-11-12T09:28:02Z SendMessages: sending inv peer=0 hash=484096729b1785a0e7dac627a60adbffe87ee8db8b60fec0dffe5602b3dce390
2019-11-12T09:28:02Z sending inv (37 bytes) peer=0
2019-11-12T09:28:02Z SendMessages: sending inv peer=0 hash=32bd2a1aaac32d8fd2b47289c8da6d0458bd6a16b6bba2c8d1a027e07685c9b8
2019-11-12T09:28:02Z sending inv (37 bytes) peer=0
2019-11-12T09:28:02Z SendMessages: sending inv peer=0 hash=4845a8e32bbb6738ab46cb28d83782ebedf02a9e2e9dfdf65f415896063da7f1
2019-11-12T09:28:02Z sending inv (37 bytes) peer=0
2019-11-12T09:28:02Z SendMessages: sending inv peer=0 hash=6d2515a602daacab6142030f5f337e94a20ab76b09d6cf6abe84d00303c5791c
2019-11-12T09:28:02Z sending inv (37 bytes) peer=0
2019-11-12T09:28:02Z SendMessages: sending inv peer=0 hash=6d7f3af9bbcc52e372717d9fbbd74334a5bafa91beaa8abf8a43f6e5454cae28
2019-11-12T09:28:02Z sending inv (37 bytes) peer=0
2019-11-12T09:28:02Z SendMessages: sending inv peer=0 hash=2f48479e01bb83271c316d718dc2ecf2dd35168fea0560ab7373991f72a36af4
2019-11-12T09:28:02Z sending inv (37 bytes) peer=0
2019-11-12T09:28:02Z UpdateTip: new best=0ec957f5349e856c1a24f0ca785446bfc65d02f91f3d33084696fae446243974 height=1458 version=0x20000000 log2_work=11.510764 tx=1459 date='2019-11-12T09:28:03Z' progress=1.000000 cache=0.0MiB(7txo)
2019-11-12T09:28:02Z CreateNewBlock(): block weight: 892 txs: 0 fees: 0 sigops 400
2019-11-12T09:28:02Z UpdateTip: new best=3cf99ebca1d0683aa98f01f88b08f9ee073885391744704734f4f61c1110f3cf height=1459 version=0x20000000 log2_work=11.511753 tx=1460 date='2019-11-12T09:28:03Z' progress=1.000000 cache=0.0MiB(8txo)
2019-11-12T09:28:02Z CreateNewBlock(): block weight: 892 txs: 0 fees: 0 sigops 400
2019-11-12T09:28:02Z received: getdata (37 bytes) peer=0
2019-11-12T09:28:02Z received getdata (1 invsz) peer=0
2019-11-12T09:28:02Z received getdata for: block 484096729b1785a0e7dac627a60adbffe87ee8db8b60fec0dffe5602b3dce390 peer=0
2019-11-12T09:28:02Z UpdateTip: new best=42a40e412ed1804fabdca9aef42f1af920241cdb254c49dc0da5adbcd7f14286 height=1460 version=0x20000000 log2_work=11.51274 tx=1461 date='2019-11-12T09:28:03Z' progress=1.000000 cache=0.0MiB(9txo)
2019-11-12T09:28:02Z CreateNewBlock(): block weight: 892 txs: 0 fees: 0 sigops 400
2019-11-12T09:28:02Z UpdateTip: new best=11fefbdb728be17af779df4245a88f8654502fd2f5c06f2299946a01512bd2ac height=1461 version=0x20000000 log2_work=11.513728 tx=1462 date='2019-11-12T09:28:03Z' progress=1.000000 cache=0.0MiB(10txo)
2019-11-12T09:28:02Z sending block (215 bytes) peer=0
2019-11-12T09:28:02Z SendMessages: sending inv peer=0 hash=3cf99ebca1d0683aa98f01f88b08f9ee073885391744704734f4f61c1110f3cf
2019-11-12T09:28:02Z sending inv (37 bytes) peer=0
2019-11-12T09:28:02Z received: getdata (37 bytes) peer=0
2019-11-12T09:28:02Z received getdata (1 invsz) peer=0
2019-11-12T09:28:02Z received getdata for: block 32bd2a1aaac32d8fd2b47289c8da6d0458bd6a16b6bba2c8d1a027e07685c9b8 peer=0
2019-11-12T09:28:02Z sending block (215 bytes) peer=0
2019-11-12T09:28:02Z received: getdata (37 bytes) peer=0
2019-11-12T09:28:02Z received getdata (1 invsz) peer=0
2019-11-12T09:28:02Z received getdata for: block 4845a8e32bbb6738ab46cb28d83782ebedf02a9e2e9dfdf65f415896063da7f1 peer=0
2019-11-12T09:28:02Z sending block (215 bytes) peer=0
2019-11-12T09:28:02Z received: getdata (37 bytes) peer=0
2019-11-12T09:28:02Z received getdata (1 invsz) peer=0
2019-11-12T09:28:02Z received getdata for: block 6d2515a602daacab6142030f5f337e94a20ab76b09d6cf6abe84d00303c5791c peer=0
2019-11-12T09:28:02Z sending block (215 bytes) peer=0
2019-11-12T09:28:02Z received: getdata (37 bytes) peer=0
2019-11-12T09:28:02Z received getdata (1 invsz) peer=0
2019-11-12T09:28:02Z received getdata for: block 6d7f3af9bbcc52e372717d9fbbd74334a5bafa91beaa8abf8a43f6e5454cae28 peer=0
2019-11-12T09:28:02Z sending block (215 bytes) peer=0
2019-11-12T09:28:02Z received: getdata (37 bytes) peer=0
2019-11-12T09:28:02Z received getdata (1 invsz) peer=0
2019-11-12T09:28:02Z received getdata for: block 2f48479e01bb83271c316d718dc2ecf2dd35168fea0560ab7373991f72a36af4 peer=0
2019-11-12T09:28:02Z sending block (215 bytes) peer=0
2019-11-12T09:28:02Z SendMessages: sending inv peer=0 hash=42a40e412ed1804fabdca9aef42f1af920241cdb254c49dc0da5adbcd7f14286
2019-11-12T09:28:02Z sending inv (37 bytes) peer=0
2019-11-12T09:28:02Z SendMessages: sending inv peer=0 hash=11fefbdb728be17af779df4245a88f8654502fd2f5c06f2299946a01512bd2ac
2019-11-12T09:28:02Z sending inv (37 bytes) peer=0
2019-11-12T09:28:02Z received: getdata (37 bytes) peer=0
2019-11-12T09:28:02Z received getdata (1 invsz) peer=0
2019-11-12T09:28:02Z received getdata for: block 3cf99ebca1d0683aa98f01f88b08f9ee073885391744704734f4f61c1110f3cf peer=0
2019-11-12T09:28:02Z sending block (215 bytes) peer=0
2019-11-12T09:28:02Z received: getdata (37 bytes) peer=0
2019-11-12T09:28:02Z received getdata (1 invsz) peer=0
2019-11-12T09:28:02Z received getdata for: block 42a40e412ed1804fabdca9aef42f1af920241cdb254c49dc0da5adbcd7f14286 peer=0
2019-11-12T09:28:02Z sending block (215 bytes) peer=0
2019-11-12T09:28:02Z received: getdata (37 bytes) peer=0
2019-11-12T09:28:02Z received getdata (1 invsz) peer=0
2019-11-12T09:28:02Z received getdata for: block 11fefbdb728be17af779df4245a88f8654502fd2f5c06f2299946a01512bd2ac peer=0
2019-11-12T09:28:02Z sending block (215 bytes) peer=0
2019-11-12T09:29:02Z Adding fixed seed nodes as DNS doesn't seem to be available.
2019-11-12T09:30:01Z received: ping (8 bytes) peer=0
2019-11-12T09:30:01Z sending pong (8 bytes) peer=0
2019-11-12T09:30:02Z sending ping (8 bytes) peer=0
2019-11-12T09:30:02Z received: pong (8 bytes) peer=0
2019-11-12T09:30:23Z socket closed
2019-11-12T09:30:23Z disconnecting peer=0
2019-11-12T09:30:23Z Cleared nodestate for peer=0
2019-11-12T09:30:23Z ThreadRPCServer method=stop user=f8985cc2feca0c178e42c67adef33d6bbda6fd1b9f
2019-11-12T09:30:23Z Interrupting HTTP RPC server
2019-11-12T09:30:23Z Interrupting RPC
2019-11-12T09:30:23Z tor: Thread interrupt
2019-11-12T09:30:23Z addcon thread exit
2019-11-12T09:30:23Z torcontrol thread exit
2019-11-12T09:30:23Z Shutdown: In progress...
2019-11-12T09:30:23Z opencon thread exit
2019-11-12T09:30:23Z Stopping HTTP RPC server
2019-11-12T09:30:23Z Stopping RPC
2019-11-12T09:30:23Z RPC stopped.
2019-11-12T09:30:23Z net thread exit
2019-11-12T09:30:23Z msghand thread exit
2019-11-12T09:30:23Z Flushed 0 addresses to peers.dat  4ms
2019-11-12T09:30:23Z scheduler thread interrupt
2019-11-12T09:30:23Z Dumped mempool: 7e-06s to copy, 0.00746s to dump
2019-11-12T09:30:23Z [default wallet] Releasing wallet
2019-11-12T09:30:23Z Shutdown: done

@lontivero just to add to this log: the problem is that 0ec957f5349e856c1a24f0ca785446bfc65d02f91f3d33084696fae446243974 was never announced via a inv.

It is strange, it never happened to me but the log seems to indeed show that a block was not announced.

This seems to be the case if direct headers announcement / BIP 130 is not used (is there a reason for that?) and if the blocks are generated faster than the propagation mechanism with validationinterface callbacks and SendMessages picks them up - according to the following code comment it is intentional that in this case, only the tip is INV'ed and the rest of the blocks are dropped from vBlockHashesToAnnounce and never INV'ed (I am not sure why): https://github.com/bitcoin/bitcoin/blob/cd6cb9745e13a62e130b11f78a13bcc1d424b05e/src/net_processing.cpp#L3751-L3754

I think @mzumsande might be right. I never experienced this problem, probably because I use header announcement. You should try to switch to the same by sending a SendHeaders upon connection and using new headers announcement instead of the invs.

This behavior is intentional and, in my view, largely correct. For some history, this code was last restructured in #6494 (merged in #7129) and also discussed in #5982, see in particular this comment.

I don't think that the goal of the p2p protocol for block announcements is to ensure that every block hash is announced; instead our goal is to ensure that the network synchronizes quickly and reasonably efficiently. If somehow our queue of block announcements fills to the point that we're falling back to just announcing our tip, it's either because (a) our node is too slow to drain the announcement queue, (b) blocks are arriving way faster than you'd ever expect given our consensus parameters, or (c) we're experiencing a large (>8 block) reorg.

I think (a) is by far the most likely cause that we'd see in practice -- and in the event that we are being slow to process block announcements, it's not important for the network's health to clear through our backlog announcing old blocks. Scenario (b), which is described in this issue, is unrealistic for mainnet, and (c) should be very rare, so it's something we should handle but not necessarily optimize for, as such a large reorg will already be very disruptive (and it's not clear that having the whole network announce every block hash on every link is better in such a case than just announcing tips and letting nodes decide which peers to sync headers from).

Moreover, as I pointed out in the comment linked above, sending INV messages for lots of intermediate block hashes is inefficient for implementations like Bitcoin Core's, where we send a getheaders message in response to an INV in order to determine whether to download the block (which is necessary for anti-DoS reasons), resulting in n^2 behavior if we were to be announced a quick succession of blocks at once.

That said, if there is a use case of applications listening to (say) a trusted node implementation to be notified of all blocks which is not yet being met using the existing ways (like zmq or -blocknotify or whatever other listening ways we have nowadays), then I think we should improve that. I would just be skeptical about trying to make the p2p layer serve that need -- and if some use case must use the p2p layer, I would suggest implementing some minimal headers syncing logic to be compatible.