gnosis/lighthouse
1
0
Fork 0
mirror of https://github.com/sigp/lighthouse.git synced 2026-05-07 00:42:42 +00:00
Code Issues Packages Projects Releases Wiki Activity

remove strict fee recipient docs (#3551)

Browse Source 
## 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 <sean@sigmaprime.io>
This commit is contained in:
realbigsean
2022-09-08 00:06:25 +00:00
parent 419c53bf24
commit 81d078bfc7
2 changed files with 3 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
book/src/suggested-fee-recipient.md
View File

@@ -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.