witnet
Old superblocks are not being created when the node synchronizes
When a new node synchronizes to the network, it will only create and persist the "target" superblock, which is the superblock that is announced by its peers using the LAST_BEACON protocol message. For example, if the node synchronizes when the current superblock index is 10, that node will persist superblocks 10, 11, 12... to storage, but anything lower than 10 will not be created. Also, if that node stops at superblock 12 and then starts again later at superblock 15, it will also leave a gap, superblocks 13 and 14 will not be created.
Superblocks can be created while the node synchronizes, but they should not be persisted until the target superblock is validated to avoid possible attacks. A potential problem is that there is no way to validate if the superblock hash is valid, other than asking other nodes for this superblock and compare. So another possibility is to retrieve the missing superblocks from other peers, but that would require trusting your peers.
So far the only thing affected by this issue is the bridge, which uses the getSuperBlock JSON-RPC method to prove inclusion of data requests. This means that the bridge will not be able to include data requests that were finished before the node synchronizes, which is not a big problem.
We should take into account that in the "hack" we specify a hard coded bootstrap committee during several epochs. And if we remove it in the issue #1646 we could have problem to rebuild the SuperBlock chain
