Jun 30, 2021

Specifically, I though, what if a malicious miner would produce many block headers but for blocks that don’t exist. If LibBitcoin’s header and block sync process are one, where the header sync part decides which is the longest chain and block download is then applied on those blocks, if this is how the block sync works then essentially LibBitcoin block sync is stalled during any such >50% malicious miners attack which does an unavailable blocks attack. For this reason I originally assumed that LibBitcoin would have two separate sync processes internally: one separate header sync process, which is about finding the longest header chain. But then a separate block sync process which will cause LibBitcoin to use as actually longest chain, the longest chain for which it has blocks, too. This approach would render LibBitcoin resistant to the attack I described. However, I do see the argument that “header only & block unavailable attack” is unreasonable.