Proofs of Possession as per IETF spec

[CarlBeek]

This is a proposal to switch to the IETF specs' proof-of-possession.

We currently use sign(hash_tree_root(deposit_data)) whereas the IETF spec suggests using sign(pubkey). I don't see a reason not to use the "official" PoP as the signature is only used to verify possession and not for security reasons.

I created a PR against @kirk-baird's BLS branch on the @sigp fork to show cleaner diffs. Have a look at it here: sigp#1

[CarlBeek]

I think this also removes the need for DepositData being a special case in @protolambda's sexy signing root removal PR (#1491) as this removes the need to calculate the signing root of DepositData. The proof_of_possession just becomes another field in a normal container which is never signed.

@protolambda, can I get a sanity check here?

[kirk-baird]

One thing that I would like to make sure of is the impact of front running the deposit contract:

If we only sign the public_key then someone would be able to use the same public_key but with different withdrawal_credentials.
Thus, if userA makes a deposit of 32ETH. userB could front run this transaction with the same signature but different withdrawal_credentials and MINIMUM_DEPOSIT_AMOUNT.
The withdrawal_credentials are only set once, on the first deposit event thus if a transaction successfully front runs, it will have ownership of the withdrawal_address.

[protolambda]

Thanks Kirk, yes we are already aware of that and discussed in chat, and then a related issue and repeat of the front-running issue in the eth2 discord. We may consider another solution with 2 sigs to conform to IETF, but the status quo (sign over deposit message) seems to be the most efficient and doesn't have the front-running problem.

[kirk-baird]

Yea it's a bit of a trade-off between having two signatures and conforming vs being more efficient.

[CarlBeek]

@kirk-baird and @protolambda Thanks for your input. As was mentioned, the front running issue has been brought up by a few different people and breaks this proposal in its current form.

I am really not a fan of the dual signature approach. It is conformance for the sake of conformance. Considering the signature operates as a perfectly functional PoP, it I really don't think the overhead is worth it.

I will be closing this issue and sigp#1