[Bug] request_block_header(s) Redundancy

[buggybuck]

What happened?

Hi there!

I noticed that the reference wallet, when synced, is doing a 'request_block_header' and a 'request_block_headers' operation at the same time (more or less). This seems rather redundant or is it not? Wouldn't it suffice if one process is polling new block headers instead of two?

Version

main

What platform are you using?

Linux

What ui mode are you using?

GUI

Relevant log output

No response

[wjblanke]

Can you send us the log snippet that shows what you are seeing? For validation we sometimes have to go grab different blocks at different times so this could be expected but maybe not. Lets find out. Thanks

[buggybuck]

Here is the log snippet. I obfuscated IP addresses and times.

2025-01-10T00:00:00.363 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_header to peer 111.0.0.1 (... and some hex string)
2025-01-10T00:00:00.537 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_headers to peer 111.0.0.1 (... and some hex string)
2025-01-10T00:00:04.459 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_header to peer 222.0.0.2 (...)
2025-01-10T00:00:04.505 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_headers to peer 222.0.0.2 (...)
2025-01-10T00:00:04.570 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_headers to peer 222.0.0.2
2025-01-10T00:00:21.763 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_header to peer 111.0.0.1
2025-01-10T00:00:21.933 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_headers to peer 111.0.0.1
2025-01-10T00:00:22.174 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_headers to peer 111.0.0.1
2025-01-10T00:00:55.213 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_header to peer 111.0.0.1
2025-01-10T00:00:55.419 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_headers to peer 111.0.0.1
2025-01-10T00:00:59.206 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_header to peer 111.0.0.1 
2025-01-10T00:00:59.418 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_headers to peer 111.0.0.1
2025-01-10T00:01:10.669 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_header to peer 222.0.0.2
2025-01-10T00:01:10.728 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_headers to peer 222.0.0.2 
2025-01-10T00:01:10.774 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_headers to peer 222.0.0.2
2025-01-10T00:01:10.831 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_headers to peer 222.0.0.2
2025-01-10T00:01:19.583 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_header to peer 111.0.0.1
2025-01-10T00:01:19.754 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_headers to peer 111.0.0.1
2025-01-10T00:01:19.939 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_headers to peer 111.0.0.1
2025-01-10T00:01:20.709 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_header to peer 111.0.0.1
2025-01-10T00:01:21.320 2.5.1.dev272 wallet wallet_server : DEBUG -> request_block_headers to peer 111.0.0.1

And here are the contents of these request messages:

2025-01-10T00:00:00.363 (111.0.0.1): height: 6466939
2025-01-10T00:00:00.537 (111.0.0.1): start_height: 6466939, end_height: 6466939, return_filter: False

2025-01-10T00:00:04.459 (222.0.0.2): height: 6466940
2025-01-10T00:00:04.505 (222.0.0.2): start_height: 6466940, end_height: 6466940, return_filter: False
2025-01-10T00:00:04.570 (222.0.0.2): start_height: 6466939, end_height: 6466939, return_filter: False

2025-01-10T00:00:21.763 (111.0.0.1): height: 6466941
2025-01-10T00:00:21.933 (111.0.0.1): start_height: 6466941, end_height: 6466941, return_filter: False
2025-01-10T00:00:22.174 (111.0.0.1): start_height: 6466940, end_height: 6466940, return_filter: False
2025-01-10T00:00:55.213 (111.0.0.1): height: 6466942
2025-01-10T00:00:55.419 (111.0.0.1): start_height: 6466942, end_height: 6466942, return_filter: False
2025-01-10T00:00:59.206 (111.0.0.1): height: 6466943
2025-01-10T00:00:59.418 (111.0.0.1): start_height: 6466943, end_height: 6466943, return_filter: False

2025-01-10T00:01:10.669 (222.0.0.2): height: 6466944
2025-01-10T00:01:10.728 (222.0.0.2): start_height: 6466944, end_height: 6466944, return_filter: False
2025-01-10T00:01:10.774 (222.0.0.2): start_height: 6466943, end_height: 6466943, return_filter: False
2025-01-10T00:01:10.831 (222.0.0.2): start_height: 6466942, end_height: 6466942, return_filter: False

2025-01-10T00:01:19.583 (111.0.0.1): height: 6466945
2025-01-10T00:01:19.754 (111.0.0.1): start_height: 6466945, end_height: 6466945, return_filter: False
2025-01-10T00:01:19.939 (111.0.0.1): start_height: 6466944, end_height: 6466944, return_filter: False
2025-01-10T00:01:20.709 (111.0.0.1): height: 6466946
2025-01-10T00:01:21.320 (111.0.0.1): start_height: 6466946, end_height: 6466946, return_filter: False

So I'm basically wondering why a request_block_headers message containing the same block height is send to a peer when a request_block_header message with that height was already sent to that peer.

I will double check now but I think this will also result in an unnecessary received block header. Unnecessary because the wallet already received that block header from the same peer.

Edit: I checked two pairs of respond_block_header/respond_block_headers that gave back a header block for the same height (from the same peer IP). The header block of the respond_block_header message contained a transaction_info section whereas the respond_block_headers message doesn't.