I suggest we look at handling send and receive/open(and change?) blocks differently with regards to elections. Since all wallets and services have/should have a backup solution of checking account for pending I think we can reduce a lot of vote requests during spamming/heavy load by not restarting elections on these blocks if they are not confirmed within x time. As I understand it a block is in active_elections for 5 minutes before being dropped, and then elections are restarted after 30 min, or if another node requests votes on this particular block, and it has above 10% of the voting weight already. Please correct me if I'm wrong here. This leads to a lot of vote requests during saturation, and especially during a situation we have right now with a huge back catalog of blocks needed to be confirmed.
Ideally we should not add these blocks to the ledger at all/remove them from the ledger when their election expires, and wallets and services can easily build and process/broadcast the block again just by checking for pending, but this might be a bigger change.
I think this could also be beneficial against a ledger bloat attack, as the open blocks for the new accounts would be dropped and would not be attempted to be confirmed either until/if the spammer rebroadcasts the block. At the minimum it would make it more complicated for the attacker. He might also have to produce new work again, increasing the cost, depending on how we want to handle the rebroadcasting of the block.
Send blocks on the other hand is more complicated for wallets and services to rebroadcast if they get completely dropped from elections, so for those it makes sense to restart elections after x time.
I'm sure there are details I'm not thinking about here, but I was hoping this might be an easy way to reduce vote traffic on the network during heavy load/a spam attack, and slightly increase complexity for a ledger bloat attack.