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

Security feature request: set some limitations on worker's begin time #565

Closed
abitmore opened this issue Feb 10, 2016 · 10 comments
Closed

Comments

@abitmore
Copy link
Contributor

In order to prevent a whale of a group of whales from stealing funds from the reserve pool, I think it's better to set some limitations on workers' begin time, so stake holders have enough time to react. For example, after created, worker need at least one week or two weeks to start being paid. Best if the value can be adjusted by the committee.

//Edit:
This feature may require a hard fork.

@abitmore
Copy link
Contributor Author

I think this is high priority. Currently it's possible to steal funds with as little as 115M BTS of voting power. @bytemaster @theoreticalbts @xeroc

@bytemaster
Copy link
Contributor

I don't think this would actually solve anything. I would create the worker 1 week before I vote for it.

What is really required is a 1 week vesting period where vesting funds can only be claimed if the worker is still voted in.

I suspect that if someone pulled such a stunt the network would react in less than 24hrs. This is far easier to resolve by increasing the vote turn out for existing workers and refund workers.

@abitmore
Copy link
Contributor Author

If you create worker 1 week before, other people have chance to down vote it.

@abitmore
Copy link
Contributor Author

If I create worker 1 hour before start getting paid, most people have no chance to vote against it. And I can create a worker every hour.

@bytemaster
Copy link
Contributor

Pro-active downvoting is a losing proposition. Users can create 1000 workers and the network will no allow you to down-vote so many workers. The only real solution is to UPVOTE refund workers. Perhaps removing DOWNVOTING is the actual solution to this attack.

@abitmore
Copy link
Contributor Author

Maybe another solution is increasing the fee for creating worker to 400K BTS or so, so proxies and stake holders have one day to react (I mean vote against the attacking worker).

@bytemaster
Copy link
Contributor

I think that makes good sense... increasing the fee will be reimbursed if they are voted in and stay in long enough to get paid. This doesn't require a hardfork and can be completely resolved by committee.

@abitmore
Copy link
Contributor Author

Will this solve the "1000 workers" issue as well?

@bytemaster
Copy link
Contributor

It would at least make it more expensive.... only one could get voted in which means it would take them 1000 times longer to break even.

xeroc added a commit to BitShares-Committee/Instructions that referenced this issue Feb 11, 2016
xeroc added a commit to BitShares-Committee/proposals that referenced this issue Feb 11, 2016
@xeroc
Copy link
Contributor

xeroc commented Mar 9, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants