-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate a possible reordering issue of KeyGenMessage #234
Comments
Are the Only once |
In the log, "DKG for Remove" succeeds without any node sending |
Right, but that's only because node 1 committed its own In either case, the attacker shouldn't be able to do any harm: if DKG has succeeded, that means that enough |
I'm closing this, because I think the reason for the weird test log is just that validators can get their own Please reopen if I'm missing something. |
Assuming the sender queue #226 is merged, if you delay
KeyGenMessage::Part
messages and deliver them in an epoch after their correspondingKeyGenMessage::Ack
messages have been delivered by Dynamic Honey Badger, it seems that the DKG protocol may not terminate. This is highly speculative however as I'm looking at the log of my experiments where a queue implementation was faulty and was occasionally droppingKeyGenMessage::Part
messages altogether. I assume that those messages, if delayed, will be simply discarded by the recipient because of the obsolete message epoch. The trick here is that the protocol makes progress withoutPart
s and withAck
s only.Below is a filtered sample log of a non-terminating Dynamic Honey Badger for 2 validator nodes and one observer node is missing
Part
messages. Let's assume those were delayed until a later epoch where the recipient discards them.After this point there are no DKG messages and the Dynamic Honey Badger epoch 5 does not terminate.
The text was updated successfully, but these errors were encountered: