Generally speaking I would like to have this in the spec. I think an important function for any Eth1 withdrawal contract is to initiate the validator exit. This is an essential function for any staking pool (where it's not sufficient to use the withdrawal key to initiate exit).

One way to implement it would be to add a function to the withdrawal contract

def isExitable(validatorPubkey) -> bool:

and any Eth1 address can initiate the "Eth2 exit" precompile that will then use this function to check if the contract allows an exit.

I would add that in case of using ETH1_ADDRESS_WITHDRAWAL_PREFIX, Ether will be transferred from fixed SYSTEM_CONTRACT address, with exact address added later, so contracts could easy clarify who is the sender.

Should it be part of the spec what minimal functionality must a contract have if it's an eth1 withdrawal address? i.e. be able to send a simple transaction to a TBD address, receive funds, etc.

I would add that in case of using ETH1_ADDRESS_WITHDRAWAL_PREFIX, Ether will be transferred from fixed SYSTEM_CONTRACT address, with exact address added later, so contracts could easy clarify who is the sender.

i'd think specifying a mechanism for the implementation of moving ETH from the beacon chain to the evm userspace is a little premature given the unknowns around the details of the eth1-eth2 merge. (e.g. we could imagine tracking withdrawals outside an actual contract in the EVM)

my understanding of this PR is more to provide a firm(er) commitment to eth withdrawals to today's eth1 so that the use cases that can get away with just this functionality can move ahead w/ development and implementation.

i do think we eventually want a more involved mechanism for eth transfer (e.g. #2151) but i'd suggest waiting for a clearer understanding of the merge before moving ahead w/ concrete specifics of such a scheme

Should it be part of the spec what minimal functionality must a contract have if it's an eth1 withdrawal address? i.e. be able to send a simple transaction to a TBD address, receive funds, etc.

The PR does specify that the eth1 withdrawal address just needs to be able to accept ETH (e.g. by default as an EOA, or a payable function in a Solidity smart contract). If you look at my prior comment, there is certainly a space for a more complex mechanism for withdrawals (discussion starting here: #2151) but I'd say that is a another iteration of withdrawal handling once we better understand the eth1-eth2 merge.

👍

@zilm13

Ether will be transferred from fixed SYSTEM_CONTRACT address, with exact address added later, so contracts could easy clarify who is the sender.

I'm inclined to not even put this in there as it is not an entirely actionable detail today.
Also, assume this is a contract that can split funds or a multi-sig or something. Receiving extra ETH from non SYSTEM_CONTRACT seems fine in almost all cases 😂

Unstaking BLS to ETH1 - the wagyu gui asks for a 24 word recovery phrase, but metamask offers a 12 word phrase, how to proceed in that case? @dankrad @zilm13 @dapplion @ralexstokes @djrtwo

I don't know how the wagyu GUI works and you should probably ask the maintainers

You may find more information here: https://launchpad.ethereum.org/en/withdrawals

allnodes.com created a Ledger Nano X compatible tool that ended up working.
https://help.allnodes.com/en/articles/7235575-how-to-change-your-ethereum-withdrawal-credentials-from-0x00-to-0x01-deposit-cli