I agree some kind of limit would be required to avoid a bucket (or a few buckets) affecting all others.

But I think a fixed limit on each bucket might not work very well.

If the limit is set too high, say 50% of the total, spam two buckets would lead to the same old issue, it increases the difficulty, but just not that ideal.

If the limit is too low, it would reduce the throughput.

Here are my suggested modifications based on the idea of limit.

Proposed Solution 1:

Reserve a small amount of the elections for each bucket, or each bucket group*. Say 10-20% in total for all buckets, with the remaining 80-90% free to use by any buckets like now.

I.e. if a election from a bucket is below the reserved amount, it should always go into the Action Elections Container without problem

Proposed Solution 2:

For each RR iteration, instead of picking one election from each bucket to put into the AEC directly (Active Elections Container) (which I believe what it is right now, please correct me if I am wrong), we do this:

- select one election from each bucket as representative
- let only a fixed number of these elections from (1) to go into the AEC, say 20
- the selection on (2) should be based on the number of elections of corresponding bucket in the AEC, either
- pick those elections which belongs to bucket with the least weight* in AEC
- pick those elections which belongs to buckets that is least recently used (credits goes to keeri)

- add a bit more delay between iterations as the AEC is close to full, allowing new elections to have chance to compete

*Bucket group - simply like a larger bucket, e.g. bucket 1-4 belongs to a group while bucket 5-9 belongs to another

*weight = number of elections from the corresponding bucket in AEC

Proposal 3:

combine 1 and 2

Edit: these proposals can still be used together with a hard limit on each bucket (or bucket group) to further increase the difficulty for spammers