Hi, i’m a full windows validator since genesis… I have a similar problem where my account used to fund my validator with 32 eth was compromised. I was told since I haven’t migrated to 0x01 credentials yet, I’m good. Is this true? thanks in advance
My understanding is if he has the seed phrase you need to go and set your withdrawal address to a fresh secure wallet as quickly as you can or the person who has your seed phrase can do it for you to an address you don’t control. @benjaminchodroff can you confirm?
1 Like
Actually, I replied in haste because I was concerned for you. But thinking about it yes you’re right because the validator withdrawal address is not the deposit address is it? as long as you’ve not lost control of the seed phrase for the withdrawal address you’re okay.
1 Like
If only the seed phrase used for your deposit address was compromised, it will not compromise your validator seed phrase (unless, you did something odd and used the same seed phrase for your validator). As you have indicated you have not yet set your withdrawal address, you can still set this to a new address that is not compromised. I recommend every validator should always set their withdrawal address managed by a seed phrase that is secure, offline and operated with a cold hardware wallet.
2 Likes
hi thanks for your replies! so I don’t think the actual “seed phrase” was compromised, I use metamask and accidentally executed a rogue smart-contract which compromised the metamask “private key” ( i think) … anyway, when I finally migrate to 0x01 I will definitely set a new withdrawal address offline as you stated.
Bringing up this old post again but still hopeful of course!
There have been some chats on discord: Prysm discord + EthStaker discord and wanted to get your views on it.
Potuz (on Prysm discord) wrote the following on twitter (I can’t post links but his handle is potuz_eth and post was made on july 13 of this year).
He proposes to solve this in the “Social layer” by:
- Collecting changes similar to how clwp did it (potentially with even more checks)
- Then in a hardfork change the credentials.
- Potentially sending an execution chain message from the deposit address containing a message signed by the validator keystore?
The likely hood of a malicious user having access to the depoit address + validator signing key + mnemonic is lost are very, very slim (might go so far as to say 0).
There are numerous genesis validators whose operators have lost their seed but have the wallet that funded them. We are literally talking about thousands of ETH mainly by home stakers. The defacto most die-hard supporters of Ethereum since day 1.
This would be a hard fork yes, but it doesn’t affect any transaction on chain. It doesn’t revert any tx and it doesn’t lose anyone ETH.
What are your thoughts on this?
1 Like
Curious to hear about devs thoughts on this. Having a double signature scheme from both the EL depositor(s) (all of them must participate in the event of multiple depositors) + the current keystore operator on the CL might get sufficient security guarantees to make it happen in the future. Restricting to unassigned withdrawal credentials also greatly reduced the risk imho.
I cannot help you build this proposal, but I can give you some guidance. I agree with Potuz that the most realistic option (although going to be a very hard one to convince the community) is to collect a series of signatures off-chain in a manner similar to CLWP, and then aim to enable a consensus layer hardfork to both set/override(?!) the withdrawal address AND exit the validator without requiring the signed BLS messages.
Of course, if someone in the future loses their CL validator mnemonic or execution layer withdrawal address mnemonic, this hardfork process could be repeated again with new data. Additionally, the precedent of including any off chain data into validator clients to request hard forks is extremely concerning to many in the community, regardless of the merits. It may require participants to voluntarily verify this data, and optionally load the data in their CL validator - a much slower but safer process. This raises numerous security challenges with testing and ensuring validators aren’t slashed.
I am certain I have not thought this fully through and changing any aspect of on chain consensus is extremely risky. Best of luck.
1 Like
@philrx31 What do you think about setting up an EIP for this?
1 Like
I may actually be able to write an initial signaling proposal. Delve into the different viable designs and consider a first version that is highly restrictive and involve minimal CL coordination and complexity. @benjaminchodroff I might reach out to you again in the process to collect some insights and formal suggestions before posting.
1 Like
Valefar (over on the Ethstaker Discord #withdrawals channel) has been working on the following (potential) solution similar to CLWP:
Github: /valefar-on-discord/update-credentials-without-mnemonic
(Can’t post links unfortunately)
1 Like
This proposed double signature scheme seems to provide a good solution. Can we have @benjaminchodroff ‘s feedback on the likelihood to see developers’ approval to this scheme and acceptance to perform the credential update in a future hardfork? If so, I would be happy to write down the associated EIP in due format to request that fork. I would also take care of networking to outreach users that may be in this unpleasant situation.
Excellent. Compromising the deposit would not be sufficient for the attacker to change the withdrawal credentials with this proposal. The attacker would also need access to the validator keystore as well because both signatures would be necessary to prove ownership.
There is absolutely a situation where a user may not want to update their BLS credentials for whatever reason and this proposal could put their funds at risk. But how likely is it that not only do they not want to update their BLS credentials but the deposit address and the keystore are compromised?
There are currently 14168 validators with BLS=0x00. Conservative estimate of 1000 (~7%) of these that have lost their mnemonic represents anywhere between 32000-35000 ETH (which added rewards). Big share of these validators are pre-genesis stakers as well.
Indeed, 7% even seems to be a conservative forecast.
Can you elaborate on the scenario that would put funds at risk?
I’d encourage that you start a new thread, and try to direct those impacted to the fresh topic. It will be incredibly hard (read: next to impossible) to convince the community today of such a proposal, but theoretically there may come the right time. I prefer to remain hopeful, plan and begin to prepare a solution so you’re ready when the time is right.
A BLS signature for withdrawals is “not quantum secure” and Ethereum will one day need to hard fork to a new standard. This could provide a one time opportunity for a rescue at that point for validators generated using the existing elliptical curve to be helped. All options could be put on the table in that timeframe on how to handle validators that have not yet set a withdrawal address. You could start building a community and the list of those impacted with the verified signatures. I hope you build it.
"This is precisely why I maintain a positive outlook on the eventual shift from early signature schemes and consensus paradigms. I concur that we must be ready when the opportune moment arrives, as it will be our sole chance to effect this change. I appreciate your input. We will certainly liaise with @maverickandy and transition to a different topic to assemble participants and gather the necessary signatures. In the meantime, please keep us informed if you notice the right timing for an attempt approaching.
Got to this thread through a Google search. I initially thought I messed up my 24 words…
I wanted to change my withdrawal credentials, but no matter how I played with paths and indices, ethdo kept generating completely different withdrawal credentials—none of them matched my running validator. I used ethdo account derive --show-withdrawal-credentials --path=“m/12381/3600/0/0” --mnemonic=“…”. I got really desperate and started doubting whether I had written my mnemonic correctly, even though I always triple-check it.
Then I got the idea to download the same version of the deposit CLI that I used 4 years ago to see if it would generate the same deposit data. And it did! The withdrawal credentials matched—so the mnemonic is good!
I then downloaded the very latest version of the deposit CLI, and it still created the same withdrawal credentials and deposit data. Phew! 
Luckily, this new version now has the ability to change withdrawal credentials from BLS to execution change. Broadcasting that JSON finally made it happen—I can now withdraw.
I skimmed through both the ethdo and deposit CLI code, and it looks like the paths and everything else are correct, yet somehow ethdo derives the same mnemonic differently from the deposit CLI…
I don’t know why this happens, but I thought I’d share it here in case someone thinks they’ve lost access to their staked ETH. If you want to withdraw, just use the same tool you used to generate the accounts.
1 Like
Forgot to mention that I tried ethdo’s test mnemonic from util/account_test.go#L74 with a static binary that eth-docker prepared.
Running it on my airgapped machine gave completely different pubkey… Unfortunately I don’t have time to investigate further (I am happy I’ll get my ETH back), so I am just leaving this here for people who think they lost their mnemonic… Because maybe they didn’t.
If you feel you lost your initial deposit mnemonic, just try another tool, or in another way, or from another timeline, and it may work 