Deposit contract exploit

This is a known quantity to spec writers, but could maybe use some better public information.

@jgm put this up for discussion last December and we showed in that issue that there is a safe protocol for key exchange. See initial conversation – https://github.com/ethereum/eth2.0-specs/pull/1506#issuecomment-564086671

We also discussed potential modifications to the deposit contract, but all of these, imo, led to a more complicated and/or confusing scenario for stakers. I’m not currently where all of these various threads of conversation are.

Key exchange protocol copied here for discussion

So you can actually avoid front-running without passing the full private key without making changes to the deposit contract.

  • Sally the staker has a BLS private and public key
  • Derrick the delegate has a BLS private and public key
  • Derrick sends his public key to Sally. Sally combines it with her public key to create the public signing key for the validator.
  • Sally sends the deposit data D (including the combined key) to Derrick.
  • Derrick signs D with his half of the key and sends it back to Sally
  • Sally signs D and creates an aggregate of the signature that can be verified by the combined key.
  • Sally sends D along with the 32 eth to the deposit contract
  • After successful confirmation in the deposit contract, Sally sends her half of the private key to Derrick to do active validation

Only half of the private key was every transmit on the wire, so exposure of the full key to a monitoring attacker is not a risk