Cases when voting block going to be discarded falsely:

Case 1:

1. peer already have voting block
2. new block is received through block created message
3. this block has proper height, matching topology, proper leader signature
4. BUT incorrect transactions in the new block

This means that leader send two blocks.

I don't think this is issue because after such event current leader would loose it's place in the validators set.

And no one other than current leader can perform this operation.

Case 2:

1. peer already have voting block

2. new block received through block sync message

3. this block has proper height (for soft-fork or ordinary condition), view change index larger than current one (!!!), proper leader signature for this larger signature

4. here is two options why this block might be incorrect:

   • incorrect transactions
   • missing proxy tail signature, not enough voting peers signatures

In case when peer conclude that transactions are incorrect but block has all valid signatures indicates that something is certainly wrong with peer itself.

Case when block has missing signatures (and has incorrect transactions) opens possibility for the following attack by any peer in the topology:

1. find view change index (higher than current once)
2. create block
3. sign it
4. send it through block sync to other peers
5. peers will discard current voting block and this block going to be rejected
6. current view change index will fail
7. repeat the same process for the new view change index

To mitigate this issue we could check all signatures before trying to execute transactions for the given block (and discarding previous voting block).

Originally posted by @Erigara in #4828 (comment)