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 may be a race to win the “Change Withdrawal Address” operation (once enabled) if multiple parties (good actor / bad actor) possess 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 guarantee*) the rightful owner of the CL mnemonic will win the race without changing core consensus. The most verifiable signal that Ethereum Core Dev @jgm points out is that the rightful owner was in control of both the CL mnemonic (private key), EL deposit address. Using proof of the EL deposit 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:

1. If beacon nodes supported and load an optional "Change Withdrawal Address Acceptance File” containing a list of verifiable withdrawal credentials and EL deposit addresses, it would be possible to have the beacon nodes take this data into consideration (see #3)
2. 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.
3. 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 options 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 number of nodes to agree.

Multiple large beacon node operators have signalled they will help us brodcast this file when ready which will give all users a significant advantage which may thwart the bad actors.

Note: 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 Ethereum Client Software operators could implement these optional measures (and ideally enable them) to help the entire community.