Conversation
9b3c01f to
288ab75
Compare
288ab75 to
528f5f8
Compare
93bd554 to
d515877
Compare
area
left a comment
There was a problem hiding this comment.
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.