You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cases when voting block going to be discarded falsely:
Case 1:
peer already have voting block
new block is received through block created message
this block has proper height, matching topology, proper leader signature
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:
peer already have voting block
new block received through block sync message
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
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:
find view change index (higher than current once)
create block
sign it
send it through block sync to other peers
peers will discard current voting block and this block going to be rejected
current view change index will fail
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)
The text was updated successfully, but these errors were encountered: