# Flashbots Core v0.2 Miner Authentication Pre-requisites & Updated Release timeline

In Flashbots core v0.2, we are moving from RPC-based bundle submission to a Websockets approach, where after a connection between the miner and the relay is established, miners can directly consume the stream of bundles sent by the relay.

In order to establish this initial connection (and re-establish it upon eventual disconnections) we need to provide a secure path for miner authentication. We would like to ask miners to cryptographically sign a message with a private key of an Ethereum address they control, for the sole purpose of authorization.

This should not be the miner/mining pool's coinbase address, we suggest to create a new ethereum address, for security reasons. We would like to collect this public Ethereum address, using a 2FA process to avoid impersonation. This is important due to the sensitive nature of the bundle flow that signers of the address will have privileged access.

## How does it work
The authentication scheme works as follows:
1) The EOA address of the private key (referenced in mev-geth using the flag `--relaywssigningkey`, without 0x prefix) is whitelisted on the relay side.
2) During the websocket conn initiation, mev-geth signs a timestamp (unix epoch in seconds, UTC) using the private key and sends it in the request header body.
3) The relay verifies the signature (valid timestamp and if it was signed by the whitelisted EOA) and authenticates/disconnects accordingly. If it succeeds, mev-geth can start receiving bundles.
4) If mev-geth (on the miner side) has to be restarted for any reason, we repeat the process from step 2.

Considerations:
1) The relay considers the timestamp to be valid if it is within ±5 mins to that of its local clock. This is to account for any syncing/latency issues but authentication fails if the mev-geth client signs timestamps out of that range.
2) The mining coinbase address does not matter when it comes to the signing private key. Therefore, it is important to keep the pk safe/secure because anyone with access to it can start receiving bundles (and pretend to be the whitelisted miner).

## Next Steps (v0.2 new target release date: May 17)
*Note: the following steps are for mining pools already running Flashbots to receive v0.2 bundles. For new mining pools who would like to receive Flashbots bundles, please complete the [Miner Indication of Interest Form](https://docs.google.com/forms/d/e/1FAIpQLSdz29fKXJXJFWXkEu8hZNG-NJUeAbOz0Jvw9mnNLskJHlMUDA/viewform).*

**Stage I. Miner Authentication (Now - May 18)**
* Step 1: Generate a new ethereum address, save the private key for step 5
* Step 2: Send the new ethereum address to Flashbots through a pre-established Flashbots technical support private Discord channel
* Step 3: Wait for Flashbots to ask you for the same ethereum address via another independent channel (email/wechat/telegram) as a 2FA verification

*It is critical that miners only send their address to a trusted member of the Flashbots team, over a previously established communication channel.*

**Stage II. Integration and Testing (May 18 - 23)**
* Step 4: Update MEV-geth node to the lastest version according to the MEV-geth v0.2 spec, MEV-geth v0.2 reference implementation released on May 17
* Step 5: Add the private key to the cli command for the miner's mev-geth, eg. `--relaywssigningkey='a123....` You should start receiving some test fundles through the newly established websocket connection to test your set up.

*Please continue to run your MEV-geth v0.2 pre-release node, while you set up a v0.2 full release node for testing.*

**Stage III. Receive Flashbots Bundles on v0.2 nodes (May 24 - 30)**
* Step 6: We will start sending Flashbots MEV bundles to the mining pools who have integrated with Flashbots Alpha v0.2.
* Step 7: Start migrating your hashrate to the Flashbots Alpha v0.2 nodes

*Please continue to run your MEV-geth v0.2 pre-release node, while you set up a v0.2 full release node for testing.*

**Stage IV. Complete switch to v0.2 nodes (May 31)**
* Step 8: Flashbots relay stops delivering bundles over RPC, and your v0.1 and v0.2 pre-release nodes can safely be shut down, leaving only the Flashbots Alpha v0.2 nodes.