Rez

Agree with this change for a later fork. Will review properly after all bectra related work is done

The comment is vague. It's likely referring to `engine_exchangeCapabilities` in which the CL and EL will tell each-other which methods they support. Reth doesn't care: https://github.com/paradigmxyz/reth/blob/d3acdda21b9aacb5194cea0be5085fc306cdabfa/crates/rpc/rpc-engine-api/src/engine_api.rs#L991 Geth doesn't care: https://github.com/ethereum/go-ethereum/blob/db03e015772ca3e28bfa8021b6a1a43c38fcdb03/eth/catalyst/api.go#L1182...

https://github.com/orijtech/consensuswarn Repo hasn't been updated in 6 months. Don't think we want to be adding unused and unmaintained tools. wdyt @abi87

We will decide whether to implement this after the pectra withdrawals hardfork. There is still some debate about whether we should implement it or if there are other priorities.

Sounds peering related. Try the following: Delete the addressbook.json file in your beacond home directory ```sh $BEACON_HOME_DIR/config/addrbook.json ``` Then kill your beacon node, then execution client and restart both.

It's likely still peering but perhaps a different issue to the one my solution solves. Can you dump your beacond and execution logs next time it gets slow. Also the...

Supportive of this approach. Especially since its

> I would expect a proper hard fork, with a (list of) timestamps specified in specs for when withdrawals should be activate/disactivated right? I have added this @abi87 @calbera

> Some points: > > * request to rename disabling window > * question about disabling not just servicing of withdrawals but enqueing of requests as well (it's in a...

> General question. Do these 2 chain spec values imply we can "re-use" them to do a withdrawals freeze in the future? I.e. say we recognize an issue at t=100....