Eth1 voting DoS

[JustinDrake]

An attacker that controls the first slot of the Eth1 voting period (more generally, at least n/2 of the first n slots) can pick an Eth1 tip that is valid but stale, and all honest proposers would vote for this stale tip.

One fix is to have an initial voting period (e.g. 64 slots within the 1024-slot Eth1 voting period) where honest proposers do not vote for stale Eth1 tips, regardless of previous votes.

[CarlBeek]

One proposal I had for this would be to give a reward for the distance between a new Eth1 block and the previous one. This incentivises fresh blocks.

I do not like the idea and do not think it should be implemented for the following reasons:

• Eth1 block histories would have to be added to the state (as Justin pointed out)
• It would basically require writing an Eth1 light-client in Eth2 (even if you do some cool Merkel proofs to compress the chain Eth1 headers)

Side note:
Should the Validator Guide have a section on expected behaviour in a contentious Eth1 fork?

[djrtwo]

I remember we discussed making the first chunk of validators vote without looking at D the list of votes, but this didn't make it into the v-guide. Is this something we still want to do?

[JustinDrake]

making the first chunk of validators vote without looking at D the list of votes

Aesthetically-speaking I'm not totally satisfied with that.

Side question: Does the June 30 freeze date cover the validator doc?

[djrtwo]

Aesthetically-speaking I'm not totally satisfied with that.

yeah, generally agree

Side question: Does the June 30 freeze date cover the validator doc?

yes. especially these non-aesthetic items such as this

[djrtwo]

Thoughts on some of the (more complex) proposals we suggested here?

Befor spec freeze...

[dankrad]

I remember we discussed making the first chunk of validators vote without looking at D the list of votes, but this didn't make it into the v-guide. Is this something we still want to do?

Still think this should be implemented :) Everything else sounds too complex to be implemented now, and is likely not doable for the Beacon chain spec freeze.

[JustinDrake]

Everything else sounds too complex to be implemented now, and is likely not doable for the Beacon chain spec freeze.

No implementation required for spec freeze, just specification :) The honest validator spec is not (yet) executable.

[JustinDrake]

Addressed in #1218.