dankrad

> If you're keeping track of the last time that a validator attested then wouldn't it be simpler to just apply the quadratic leak to all validators at all times...

> If, for example, 10% of validators created a slashing event it would have ~0 impact on the safety/liveness of the chain (assuming the other validators are honest), but they...

> Comes phase 1, the remote [slashing protection service](https://github.com/prysmaticlabs/prysm/tree/master/slasher) will need more work to support catching and preventing invalid custody attestations This is not a viable alternative, because in order...

> Does it lose all such protection? Surely regardless of the weight behind it, an invalid state transition (for example) would be rejected by all nodes. Well, an incorrect state...

> This feels like a large and significant change to the requirements for a signer rather than a slight increase. Absolutely, it's a huge increase, that's why I started this...

> There seems to be a lot resting on this assumption. Why _a bit_, and not _a lot_? I am going to paste my answers from the secret shared validators...

Here is another suggestion to get the best of both worlds: Explicitly split Beacon Nodes into the part that verifies state transitions and all the rest. Allow compiling a "State...

> 4\. In response to @dankrad mentioning that slashing for fraud could exacerbate the verifier's dilemma, as it would make validators want to wait to see others' signatures to make...

> I don't see how we can make a good decision on this until we have a better understanding of whether or not (beacon chain) fraud proofs will be too...

> It would open up the validator to being slashed, which neither party would want. A sane staking service would treat their validator keys with as much, if not more,...