There is a growing community of users that are either concerned or know their Ethereum consensus layer (CL) mnemonic and private keys have been compromised through scams or accidental negligence by the validator owner. If the user has not yet set an execution layer (EL) withdrawal address for their validator, as it was not originally possible, then there will be a race to win the “change withdrawal address” operation if multiple parties posses the CL mnemonic and key. Validator owners who do not know they have been compromised will be quite angry and confused to find out their address has already been permanently changed by an attacker with no warning or recourse. However, if we were to start collecting the proposed change withdrawal addresses early and recommend beacon node clients to implement protective features, we can help avoid this situation for the community.
It is only possible to create conditions which favor (not a guarantee) the rightful owner of the CL mnemonic will win the race without changing core consensus. The most verifiable signal that @mcdee points out is that the rightful owner was both in control of the CL mnemonic and EL deposit address. Using proof of the EL deposit address as part of core consensus for the change withdrawal address operation will not be feasible for a number of reasons, but there are other ways it could be optionally considered in the beacon node in a way that does not change consensus:
If beacon nodes supported and load an optional “Change Withdrawal Address Acceptance File” containing a list of verifiable withdrawal credential and EL deposit address, it would be possible to have the beacon nodes take this data into consideration (see #3)
If beacon nodes support and load an optional “Change Withdrawal Address Broadcast File” containing verifiable lines of change withdrawal address messages, beacon nodes could help automatically broadcast out verified change withdrawal address messages at the right block height when supported, to help spread these message as fast as possible. Additionally, this list can perpetually be used to filter rebroadcasting P2P requests mismatching any requests found in the file.
If beacon nodes were to allow an optional “change withdrawal address rebroadcast delay” parameter, they could delay rebroadcasting messages via P2P that do not match the original deposit address. This would not prevent an attacker from eventually winning, but would give favor to any user who requests their original deposit address or an optional line matching the broadcast file loaded by the client.
All of these ideas would not change core Ethereum consensus, but could provide significant protection to the entire Ethereum community by ensuring Change Withdrawal Address operations favor the requested address of the EL deposit address holder. Even if no data files are provided, clients enabling the “change withdrawal address rebroadcast delay” by default would give other clients who are “certain” they are correct an opportunity to gain consensus likely faster than any attacker could achieve. While attackers could use these features to load their contradictory/malicious content, they would be at no advantage unless they can convince a large amounts of nodes to agree.
No user can be certain that their CL mnemonic and key have not been compromised. It is recommended that anyone who wishes could participate in a social campaign on github to collect verifiable “CLWP Claims”, and client software operators implement these optional measures (and ideally enable them) to help the entire community. Multiple large beacon node operators have expressed interest in enabling such protections as a way to help the entire community. These measures can assist the change withdrawal address is as safe and orderly as possible for all legitimate users. I greatly appreciate any ideas or feedback.