Skip to content
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

Add checkVoteStatus to PFOffer.sol #217

Merged

Conversation

LefterisJP
Copy link
Contributor

This PR is made to add the functionality of what @alexvandesande introduced in his sample Offer contract as protectFromAmbush() to the Proposal Framework Offer contract located in this repository.

The name of the function is changed to checkVoteStatus(). At any point within voteStatusDeadline seconds before the end of the voting period anyone can call checkVoteStatus() to attempt and set the
wasApprovedBeforeDeadline flag.

This allows for a way to protect against a last minute yes vote by requiring the flag to be set to true at an earlier point of the voting deadline. The offer can not be signed without this flag being set.

Tests for the functionality and logic introduced by checkVoteStatus() are added and are passing.

a note for the compilation of the contract: You need a very recent version of solc. It needs to contain this fix for the Dynamic Return Data Decoder bug.

This is a port of @avsa's contribution from his proposed offer contract
that can be seen here:
https://gist.github.com/alexvandesande/122c05a0f8a7108523aed29ae7ec92b1

At any point `voteStatusDeadline` seconds before the end of the voting
period anyone can call `checkVoteStatus()` to attempt and set the
`wasApprovedBeforeDeadline` flag.

This allows for a way to assure that the last minute yes vote does not
occur by requiring the flag to be set to true at an earlier point of the
voting deadline.
A test that the checkVoteStatus will fail if it is called after the
`voteStatusDeadline` period
@@ -98,6 +118,7 @@ contract PFOffer {
oneTimeCosts = _oneTimeCosts;
minDailyWithdrawLimit = _minDailyWithdrawLimit;
dailyWithdrawLimit = _minDailyWithdrawLimit;
proposalID = _proposalID;
Copy link
Contributor

@alexvandesande alexvandesande Jun 7, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The contractors doesn't know the proposal id at this point at it might take a while until it's whitelisted. They should have a separate functon watchContract or similar that will add it and check it:

https://gist.github.com/alexvandesande/122c05a0f8a7108523aed29ae7ec92b1#file-proposal-js-L271

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I have considered that. It's easy to get the proposal ID. It's just always proposalsNumber()+1.

The problem with this approach is that you gotta make the proposal right after you deploy the contract. And even when you do you may collide with someone else who is making a proposal at the same time.

I had not thought of a separate watchContract function. That's a nice idea. But we need to have a way to prevent the contractor from setting it to a proposalID that's not theirs in order to fool the checkVoteStatus() function.

Probably the easiest way to do so is by means of community awareness. If the proposalID does not match the one that actually tries to sign() the contract we can put out a community alert that the contractor is a scammer.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check how I implemented the watch function to prevent that:

https://gist.github.com/alexvandesande/122c05a0f8a7108523aed29ae7ec92b1#file-proposal-js-L271

It checks if the address is the same and if the proposal has not been voted
yet. Someone could still trick it by submitting two proposals, but then the
token holders would be able to see that.

On Tue, Jun 7, 2016 at 9:02 AM, Lefteris Karapetsas <
notifications@github.com> wrote:

In PFOffer.sol
#217 (comment):

@@ -98,6 +118,7 @@ contract PFOffer {
oneTimeCosts = _oneTimeCosts;
minDailyWithdrawLimit = _minDailyWithdrawLimit;
dailyWithdrawLimit = _minDailyWithdrawLimit;

  •    proposalID = _proposalID;
    

Yes I have considered that. It's easy to get the proposal ID. It's just
always proposalsNumber()+1.

The problem with this approach is that you gotta make the proposal right
after you deploy the contract. And even when you do you may collide with
someone else who is making a proposal at the same time.

I had not thought of a separate watchContract function. That's a nice
idea. But we need to have a way to prevent the contractor from setting it
to a proposalID that's not theirs in order to fool the checkVoteStatus()
function.

Probably the easiest way to do so is by means of community awareness. If
the proposalID does not match the one that actually tries to sign() the
contract we can put out a community alert that the contractor is a scammer.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/slockit/DAO/pull/217/files/5620e943d777294e89ca7e1263df220847a10a92#r66057366,
or mute the thread
https://github.com/notifications/unsubscribe/AAG5AtCRRr7jH2XcVM5fm5YwwEVdi_LYks5qJV3rgaJpZM4IvUqK
.

Alex Van de Sande
Lead Designer
Ethereum Foundation

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I had seen your implementation, but as you also point out it can be tricked by submitting two different proposals.

At the end I think that all these will be so easily detectable by the token holders that it does not matter at all. If such a thing happens the DAO observation team will put out an alert.

I am gonna port the function as is :)

Adding the watchProposal() function that @alexvandesande introduced in
his Sample Offer contract
[here](https://gist.github.com/alexvandesande/122c05a0f8a7108523aed29ae7ec92b1#file-proposal-js-L271).

This way there is no requirement to pass the `proposalID` as a
constructor argument. The contractor should instead add it on his own
after he makes the proposal by calling `watchProposal()`.

If the contractor tries to cheat by making 2 or more different proposals and
adding the one that has gotten the most votes as the proposal ID in
`watchProposal()` the token holders will notice and raise the alert so
that the contractor can be blacklisted.
@CJentzsch CJentzsch merged commit 75e0ceb into blockchainsllc:master Jun 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants