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
{{ message }}
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
This subsystem is responsible for distributing assignments and approval votes generated by the Approval Voting Subsystem (#1601) to and from other validators.
These votes need to make their way to the provisioner, where they can be included on-chain. Gossip is suitable for this subsystem.
We might want this subsystem to be responsible for distributing disputes as well.
The text was updated successfully, but these errors were encountered:
We need one politeness constraint that vote receivers know the candidate exists I suppose.
If we've no stronger politeness constraint then an adversary with 1/3rd would be validating all candidate, and thus know all candidates to be valid, and thus could vote valid from all their 1/3rd of validators, which technically means everyone verifying O(validators * candidates) = O(validators^2) signatures.
We could simply punt addressing this denial-of-service attack so long as these votes never go on chain, or at least not until an assignment goes on chain. If and when we want to address the off-chain attack we could create a politeness criteria for gossiping yes votes too, based upon assignments existing. We should bypass politeness for disputes though.
This subsystem is responsible for distributing assignments and approval votes generated by the Approval Voting Subsystem (#1601) to and from other validators.
These votes need to make their way to the provisioner, where they can be included on-chain. Gossip is suitable for this subsystem.
We might want this subsystem to be responsible for distributing disputes as well.
The text was updated successfully, but these errors were encountered: