-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow alternative methods of proposer payments in validation api. #78
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would love a review from @Ruteri too
@@ -114,6 +114,10 @@ $ geth --help | |||
|
|||
--builder.validation_blacklist value | |||
Path to file containing blacklisted addresses, json-encoded list of strings | |||
|
|||
--builder.validation_force_last_tx_payment (default: false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the default behaviour be to enforce the direct transfer?
That would make the new change opt-in which I think is going to be nicer.
} | ||
} | ||
} | ||
if feeRecipientProfit.Cmp(expectedProfit) >= 0 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, maybe == 0
would help us notice bugs faster
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
= here is so that builders can underestimate their profits. e.g. if you don't count payments to the proposals and withdrawals correctly.
closed in favor of #93 |
📝 Summary
This will allow validation API to accept blocks where:
The way we calculate profit is:
Some features of this method:
CONTRIBUTING.md