From 81d078bfc79a47c50047522199014fc6a2f36b38 Mon Sep 17 00:00:00 2001 From: realbigsean Date: Thu, 8 Sep 2022 00:06:25 +0000 Subject: [PATCH] remove strict fee recipient docs (#3551) ## Issue Addressed Related: #3550 Remove references to the `--strict-fee-recipient` flag in docs. The flag will cause missed proposals prior to the merge transition. Co-authored-by: realbigsean --- book/src/builders.md | 4 +--- book/src/suggested-fee-recipient.md | 14 ++------------ 2 files changed, 3 insertions(+), 15 deletions(-) diff --git a/book/src/builders.md b/book/src/builders.md index 2c24d3100..0f4b3fb10 100644 --- a/book/src/builders.md +++ b/book/src/builders.md @@ -55,9 +55,7 @@ Both the gas limit and fee recipient will be passed along as suggestions to conn in either, it will *not* keep you from proposing a block with the builder. This is because the bounds on gas limit are calculated based on prior execution blocks, so it should be managed by an execution engine, even if it is external. Depending on the connected relay, payment to the proposer might be in the form of a transaction within the block to the fee recipient, -so a discrepancy in fee recipient might not indicate that there is something afoot. If you know the relay you are connected to *should* -only create blocks with a `fee_recipient` field matching the one suggested, you can use -the [strict fee recipient](suggested-fee-recipient.md#strict-fee-recipient) flag. +so a discrepancy in fee recipient might not indicate that there is something afoot. ### Set Gas Limit via HTTP diff --git a/book/src/suggested-fee-recipient.md b/book/src/suggested-fee-recipient.md index c966481a3..c1739aa93 100644 --- a/book/src/suggested-fee-recipient.md +++ b/book/src/suggested-fee-recipient.md @@ -12,8 +12,7 @@ coinbase and the recipient of other fees or rewards. There is no guarantee that an execution node will use the `suggested_fee_recipient` to collect fees, it may use any address it chooses. It is assumed that an honest execution node *will* use the -`suggested_fee_recipient`, but users should note this trust assumption. Check out the -[strict fee recipient](#strict-fee-recipient) section for how to mitigate this assumption. +`suggested_fee_recipient`, but users should note this trust assumption. The `suggested_fee_recipient` can be provided to the VC, which will transmit it to the BN. The BN also has a choice regarding the fee recipient it passes to the execution node, creating another @@ -181,15 +180,6 @@ curl -X DELETE \ null ``` -## Strict Fee Recipient - -If the flag `--strict-fee-recipient` is set in the validator client, Lighthouse will refuse to sign any block whose -`fee_recipient` does not match the `suggested_fee_recipient` sent by this validator. This applies to both the normal -block proposal flow and block proposals through the builder API. Proposals through the builder API are more likely -to have a discrepancy in `fee_recipient` so you should be aware of how your connected relay sends proposer payments before -using this flag. If this flag is used, a fee recipient mismatch in the builder API flow will result in a fallback to the -local execution engine for payload construction, where a strict fee recipient check will still be applied. - ## FAQ ### Why do I have to nominate an Ethereum address as the fee recipient? @@ -198,5 +188,5 @@ You might wonder why the validator can't just accumulate transactions fees in th accumulates other staking rewards. The reason for this is that transaction fees are computed and validated by the execution node, and therefore need to be paid to an address that exists on the execution chain. Validators use BLS keys which do not correspond to Ethereum addresses, so they -have no "presence" on the execution chain. Therefore it's necessary for each validator to nominate +have no "presence" on the execution chain. Therefore, it's necessary for each validator to nominate a separate fee recipient address.