rocketpool-research VS teku

What's to stop the authorities from outlawing all relays except the censoring ones? When you are forced to use MEV-boost trough threat of penalties (up to 80% of your stake!), then even those of us that "fell" for the decentralised promise of RP will be forced to be complicit in censorship.

Unfortunately RP is also starting to look more and more centralised. In the latest upgrade they introduce penalties which were not included in the original "dumb contract" between us, validators, and RP. What's worse, they speak of forcing validators use MEV-boost.

This surprised me a bit - I know this is how it works for a 16 eth node where it has to wait for another 16 eth to be matched and sent by the contract, but what about in my case? Am I still stuck waiting for the oDAO to confirm "everything looks right" (per here)? And if so, is there a way to see where I'm at on this queue? So is the contract holding the other 16 eth in the general pool and then will send it (basically "reserving" it for me)?

This is a better place to dive deeper into the research being done on this and other topics: https://github.com/rocket-pool/rocketpool-research

The minipool will wait for 12 hours while it gets vetted by the Oracle DAO to make sure it didn't abuse the Beacon Chain's withdrawal credentials exploit (this is known as the "scrub check")

We'll make sure to keep our awesome community updated as we go roll out our solution to this unexpected, but very welcomed addition to the protocol. https://github.com/rocket-pool/rocketpool-research/blob/master/Reports/withdrawal-creds-exploit.md

More info on this can be found here: https://medium.com/rocket-pool/the-merge-0x02-mev-and-the-future-of-the-protocol-c7451337ec40 and here: https://github.com/rocket-pool/rocketpool-research

Link to repository: https://github.com/rocket-pool/rocketpool-research/blob/master/delegate-upgrades.md

You can try to upgrade it to the latest version https://github.com/ConsenSys/teku/releases/tag/23.3.1 and see if it fixes your issue, but if that doesn't work then you'll probably need to resync your clients.

I discovered a bug in Lodestar that causes it to fail to preserve queued BLS-to-execution messages on shutdown.

Teku: https://github.com/ConsenSys/teku/releases

Consensus Layer client ✅ Teku v22.11.0: https://github.com/ConsenSys/teku/releases/tag/22.11.0 ✅ Lodestar v1.2.2: https://github.com/ChainSafe/lodestar/releases/tag/v1.2.2 🟡 Lighthouse: coming soon 🟡 Nimbus: coming soon ❌ Prysm: advised to switch to other clients

create an issue here? https://github.com/ConsenSys/teku

It's all coming from besu's slow processing of blocks https://github.com/ConsenSys/teku/issues/6205

Teku v22.9.1-RC1 released today