bug: Zebra does not advertise mined blocks in some cases

[conradoplg]

What happened?

I expected to see this happen: Zebra should advertise blocks it mines

Instead, this happened: it doesn't if the node is ahead in the network and it's the sole miner.

What were you doing when the issue happened?

Mining on the testnet

Zebra logs

No response

Zebra Version

1.9.0 (restore-internal-miner branch)

Which operating systems does the issue happen on?

• Linux
• macOS
• Windows
• Other OS

OS details

No response

Additional information

Zebra has a gossip task in gossip.rs that repeatedly waits until it's close to the tip and advertises the tip block. However, in SyncStatus::wait_until_close_to_tip() which is used to that, it calls is_close_to_tip() which relies on the last synced block lengths to tell if it's close to the tip. But if the node is the ahead of the other nodes (e.g. it's the sole miner) then it won't ever receive blocks and is_close_to_tip() will return false.

I'm not sure what is the best fix for this.

[arya2]

I'm not sure what is the best fix for this.

We could add a should_gossip_blocks() method to SyncStatus that returns true if RecentSyncLengths is empty. It would only happen when the syncer hasn't found any blocks from its peers since Zebra has started, but that turned out to be problematic.

I think it would also be useful to update the RecentSyncLengths when blocks are:

• submitted through submitblock, or
• downloaded and verified after being gossiped by a peer
  • it may not significantly affect the sync lengths if this happens very rarely when Zebra is far from the tip, or we may need to include an indication that the sync length was 1 because it was gossiped rather than Zebra being close to the tip so those lengths can be excluded from the average.