Jim McDonald

> Currently, beacon chain hard-forks already invalidate previously signed exit messages which makes it difficult to reason about exit messages targetting epochs in the distant future. The proposed `SignedKeyedVoluntaryExit` signature...

As a counterpoint, [another validator](https://beaconcha.in/validator/0) lost less than 0.01 Ether over the same period. It would be nice to fix this, but I don't see it as in any way...

> I think at the base, there's "complete" trust between BN and VC I don't agree with that. In phase 0 there is no requirement for trust between a VC...

> Well, that would be arguing for point 3 in my list. Many projects go this way, which basically means forgoing any protections from malicious supermajorities. Does it lose all...

Thank you for the detailed response; I now have a better understanding of the utility of fraud proofs. I remain concerned about the difference in requirements between phase 0 and...

It is already possible for a staking service to provide a signed `VoluntaryExit` transaction to their customers. This isn't quite the same, in that the transaction becomes invalid after a...

Two forks, to be fair, which should give holders of the hot key time to sign another message. Not great if you've buried your withdrawal keys and pre-signed messages in...

> Is there any problem with the staking service simply giving a copy of the hot key to their customer It would open up the validator to being slashed, which...

Not sure why you would want to encrypt the validator key with the withdrawal key, given the withdrawal key is out of your control. For a large staking services that...

> Because the withdrawal key owner is the actual owner of the stake, so they should ultimately control it if they want to Although I get the philosophy I don't...