Staking requestAuthorizationDecrease function contract update
#99
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The application may revert authorization decrease request, if there is already one pending for the given application. This is entirely up to the application if overwriting pending request at the given moment is fine or not. This is important for TBTC and Random Beacon because allowing to "decrease authorization decrease request" at any moment may be used for pool manipulation and becoming a free-rider.
|
I thought when second request is send Application will try to start over decreasing process, so it's not overwriting but resetting. And if we always reset why it could lead to manipulation? (I'm fine if app can fail on such tx) |
nkuba
added a commit
to threshold-network/keep-core
that referenced
this pull request
Apr 29, 2022
Introduced authorization decrease change period parameter to the beacon See threshold-network/solidity-contracts#99 Introduced authorization decrease change period parameter to the beacon This value protect against malicious operators who manipulate their weight by overwriting authorization decrease request, and lowering or increasing their eligible stake this way. Authorization decrease change period is the time period before the authorization decrease delay end, during which the authorization decrease request can be overwritten. When the request is overwritten, the authorization decrease delay is reset. For example, if `authorizationDecraseChangePeriod` is set to 4 days, `authorizationDecreaseDelay` is set to 14 days, and someone requested authorization decrease, it means they can not request another decrease for the first 10 days. After 10 days pass, they can request again and overwrite the previous authorization decrease request. The delay time will reset for them and they will have to wait another 10 days to alter it and 14 days to approve it. If set to a value equal to `authorizationDecreaseDelay, it means that authorization decrease request can be always overwritten. If set to zero, it means authorization decrease request can not be overwritten until the delay end, and one needs to wait for the entire authorization decrease delay to approve their decrease or to alter it. ``` (1) authorization decrease requested timestamp (2) from this moment authorization decrease request can be overwritten (3) from this moment authorization decrease request can be approved, assuming it was NOT overwritten in (2) (1) (2) (3) --x------------------------------x--------------------------x----> | \________________________/ | authorizationDecreaseChangePeriod \______________________________________________________/ authorizationDecreaseDelay ```
nkuba
added a commit
to threshold-network/keep-core
that referenced
this pull request
Apr 29, 2022
Introduced authorization decrease change period parameter to ECDSA See threshold-network/solidity-contracts#99 This value protect against malicious operators who manipulate their weight by overwriting authorization decrease request, and lowering or increasing their eligible stake this way. Authorization decrease change period is the time period before the authorization decrease delay end, during which the authorization decrease request can be overwritten. When the request is overwritten, the authorization decrease delay is reset. For example, if `authorizationDecraseChangePeriod` is set to 4 days, `authorizationDecreaseDelay` is set to 14 days, and someone requested authorization decrease, it means they can not request another decrease for the first 10 days. After 10 days pass, they can request again and overwrite the previous authorization decrease request. The delay time will reset for them and they will have to wait another 10 days to alter it and 14 days to approve it. If set to a value equal to `authorizationDecreaseDelay, it means that authorization decrease request can be always overwritten. If set to zero, it means authorization decrease request can not be overwritten until the delay end, and one needs to wait for the entire authorization decrease delay to approve their decrease or to alter it. ``` (1) authorization decrease requested timestamp (2) from this moment authorization decrease request can be overwritten (3) from this moment authorization decrease request can be approved, assuming it was NOT overwritten in (2) (1) (2) (3) --x------------------------------x--------------------------x----> | \________________________/ | authorizationDecreaseChangePeriod \______________________________________________________/ authorizationDecreaseDelay ```
manumonti
approved these changes
Aug 17, 2022
cygnusv
approved these changes
Aug 19, 2022
When the staker requests authorization decrease, their weight in the sortition pool is decreased right away. We do it to ensure the staker is not going to be selected to new signing groups based on their previous weight since after the delay period we'll not be able to slash their entire previous stake. For example, if I have 100 tokens staked now and I request authorization decrease to 20 tokens, I should only be selected to new groups based on 20 tokens weight with an assumption that the protocol can slash me for no more than 20 tokens if I do something wrong in the new group. If we allow to discard existing authorization decrease request and start a new one, the following manipulation is possible:
To prevent this manipulation, beacon and ECDSA can reject the authorization decrease request if the amount we are decreasing to is higher than the previous one. They can also accept the new request - with the delay being reset - if the amount to which we are decreasing to is lower than the previous one. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The application may revert authorization decrease request, if there is
already one pending for the given application.
This is entirely up to the application if overwriting pending request at
the given moment is fine or not.
This is important for TBTC and Random Beacon because allowing to
"decrease authorization decrease request" at any moment may be used for
pool manipulation and becoming a free-rider.
See threshold-network/keep-core#2960
See threshold-network/keep-core#2961