This issue captures a discussion on the #witti channel. User virus-in-numeris made a deposit which turned out to be created without the witti flag. This means with an invalid signature for the witti chain due to the different fork-versions
Link to deposit
https://goerli.etherscan.io/tx/0x49a51b838523c08fcc4e9dccca65a8a9d9153e58be4358a3d16bb7c979239df6
In the validator (confirmed to have been started with the witti flag), the pubkey shows up as status=DEPOSITED :
INFO validator: Deposit for validator received but not processed into the beacon state eth1DepositBlockNumber=2771968 expectedInclusionSlot=8479 pubKey=0x8aaebd437a72 status=DEPOSITED
Proto confirmed the wrong signature
BAD signature on deposit #471, tx: 0x49a51b838523c08fcc4e9dccca65a8a9d9153e58be4358a3d16bb7c979239df6, pubkey: 8aaebd437a72f2d9620dfaca15f801b2f77c806c3816fc39de9e8739ce62703200339bb8dcd134df7093e3fa27f78766
(full list from proto of all witti signature verifications at the time: https://gist.github.com/protolambda/34a44e23720ee6666e551d64e6a1dddc)
User is waiting for the validator to become ACTIVE. This does not happen because of the invalid deposit.
Issue is that it shows up in the validator log as normal, whereas it:
Current situation is confusing and misleading.
Yes, the previous version in which this bug was not present was: ....
create a validator without the --witti flag.
Use the deposit data of this validator to make a goerli deposit.
Start the validator with the witti flag.
Pubkey then shows DEPOSITED but nothing else happens.
## 馃實 Your Environment
**Operating System:**
What version of Prysm are you running? (Which release)
Anything else relevant (validator index / public key)?
I'll try to tackle this issue @terencechain .
Assigned to @fabdarice. Please keep us updated on your progress in this issue. Thanks!
Ok, I'd like to run a couple of solutions by you guys @prestonvanloon @0xKiwi before I start diving into the implementations.
Solution A (least amount of effort):
We can verify that the signature in DepositByPubKey match the PubKey and, if invalid, log an Error message directly.
Pros: Least amount of effort
Cons: The error message will show in the beacon-chain client instead of in the validator client which will still show a "DEPOSITED" status (not great, as users can be expected to only run a validator client).
Solution B:
We can update ValidationActivationResponse to return to the ValidatorClient the entire deposit (signature, withdrawalCredentials, amount).
The validator client will then proceed with verifying the signature and display an error message if the signature is invalid. The status would, however, still be DEPOSITED.
Solution C:
We add a new ValidatorStatus such as INVALID.
The signature verification will be done in the beacon-chain rpc server, and will simply return a ValidatorStatus_INVALID to the ValidatorClient.
The validator client will then be able to display an error message displaying that his activation is Invalid.
If we want more information, we would need to add a new field in the ValidationActivationResponse holding the description of why it's invalid.
I prefer solution C @fabdarice, although a reason isn't required, a validator will only be invalid if their signature is invalid no? So that can be assumed/handled without additional complexity.
I think adding a new validator status and verifying the signature before marking the validator status as PENDING in validatorStatus() would be the best route.
Closing in favor of #6063
I don't see the relation with #6063. This issue waiting for PR #6576 from Fabrice to be merged