-
Notifications
You must be signed in to change notification settings - Fork 108
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
Extension token locking #922
Conversation
9b3c01f
to
288ab75
Compare
288ab75
to
528f5f8
Compare
93bd554
to
d515877
Compare
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.
Unfortunately, while I think this implementation is now fine, I don't think it can be merged in the current state. The problem is that with the existence of the VotingReputation
contract (which can call arbitrary functions on a colony with a root motion), anyone can unlock anyone else's tokens arbitrarily if this function is introduced.
Ah! You're so right. I think the fix here is to add a mapping of |
Also unfortunately, such a mapping cannot be trusted because of recovery mode. |
@area I don't think that's a major concern. A lot of things "cannot be trusted" because of recovery mode, but by definition it's a highly trusted mode so I'm not worried. If anything we could call it a feature -- a bug was found in an extension, we need to remove the lock so we "give" the lock to another voting contract, etc. Using recovery mode as part of an attack on a token lock seems like much more trouble than it's worth. |
fd93293
to
e66862c
Compare
e66862c
to
671ece6
Compare
b508063
to
43d9974
Compare
77abc02
to
3943592
Compare
You've not commented on my changes to the tokenlocking event or the requireExecuteCall changes so I assume you're good with them 😛 |
Definitely :) |
Closes #921
Supports #915, allowing extensions (here,
VotingToken
) to lock & unlock user's tokens.