BitShares Forum

Main => General Discussion => Topic started by: emski on June 19, 2014, 07:28:02 pm

Title: Attack scenario
Post by: emski on June 19, 2014, 07:28:02 pm
I was wondering what would happen if we had the following situation:

Imagine an evil user (EVIL) exists with 34% of the total stake.
Imagine we have 34% of the users (LAZIES) who let the software autovote.
Imagine EVIL votes for misbehaving delegates with all of his stake (34% of the total).
This should cause the LAZIES to (auto)vote against the same misbehaving delegates with ~ 34% of the total stake. So that the misbehaving delegates have <0 total votes.
As the total stake is 100% the remaining 32% controlled by honest users (HONEST) elect the remaining/acting delegates.

Then EVIL registers 51 delegates and (instantly?) votes for them with his stake (34% of the total). EVIL will surely elect all of them as we have 34% LAZIES who voted against the initial misbehaving delegates.

1.How long will it take for the LAZIES to autovote again?
2.What if EVIL arranges his votes in such way, that autovoting of LAZIES gives upvotes for his delegates, freeing some of his stake to elect other delegates?
3.Is controlling 51 of the delegates a problem?
4.Can EVIL attempt the same with less than 34% of the stake? (what is the minimum stake he needs?)

5.Is this situation impossible?

PS: Sorry if the question is lame, I'm still collecting pieces of the puzzle and I might've missed some information.
Title: Re: Attack scenario
Post by: tonyk on June 19, 2014, 08:37:39 pm
Why is the EVIL evil? Opportunistic maybe?
Title: Re: Attack scenario
Post by: bytemaster on June 19, 2014, 08:45:49 pm
Why is the EVIL evil? Opportunistic maybe?

Lazy votes will likely be those with cold storage and thus 'unchanging'. 

I think that it isn't really a problem for an attacker to have 51% unless they want to use their 51% to ignore blocks from the 49... at which point it becomes very clear that a hard fork that removes all balances voting for the attacker should be performed. 
Title: Re: Attack scenario
Post by: emski on June 19, 2014, 08:49:23 pm

Lazy votes will likely be those with cold storage and thus 'unchanging'. 


Isnt it possible to have 30% stake in lazy active shareholders that don't bother setting delegates?
Title: Re: Attack scenario
Post by: bytemaster on June 20, 2014, 01:18:08 pm

Lazy votes will likely be those with cold storage and thus 'unchanging'. 


Isnt it possible to have 30% stake in lazy active shareholders that don't bother setting delegates?

It is.

However, I am sure if something went wrong in a major way that couldn't be resolved by the active 70% that these inactive shareholders have financial incentive to take action.
Title: Re: Attack scenario
Post by: emski on June 20, 2014, 02:39:56 pm
And what if an attacker decides to use the LAZIES to make them vote for his delegates.
Imagine the following:
EVIL has 2% stake.
EVIL votes for misbehaving delegate.
LAZIES votedown that misbehaving delegate.
EVIL switches his votes to his own delegate placing it in such a way that LAZIES autovote for it.
Each block EVIL reduces his vote for that delegate making all LAZIES' transactions autovote for that particular delegate.

This shouldn't cause much trouble initially but if EVIL carefully places his votes he could control most of the LAZIES.

I understand that there are more "imminent" and important tasks at hand and this might not be even possible.

However my point is that LAZIES could be exploited and it might be a good idea to think about updating the autovoting algorithm to the point that it is not that predictable.
Title: Re: Attack scenario
Post by: bytemaster on June 20, 2014, 03:00:58 pm
Quote
EVIL switches his votes to his own delegate placing it in such a way that LAZIES autovote for it.

Big leap here... how do you place it in such a way that LAZIES auto vote for it? 
Title: Re: Attack scenario
Post by: emski on June 20, 2014, 03:14:53 pm
Quote
EVIL switches his votes to his own delegate placing it in such a way that LAZIES autovote for it.

Big leap here... how do you place it in such a way that LAZIES auto vote for it?
I used as reference https://github.com/BitShares/bitshares_toolkit/blob/master/docs/dpos.dox - @section dpos_voting_algorithm  Voting Algorithm

Assuming the new delegate has high score. Evil places it at rank 101 with some of his %2 stake (that delegate has less than 1% of votes). The misbehaving delegate now has -2% votes (all from LAZIES and none from EVIL) and is at rank > 200. With LAZIES' next transactions they should autovote again (am i right?). And LAZIES' vote should be according to the following rule
# If there are no trusted_delegates in then vote for the observed_delegate with the highest score and less than 1%
         of the vote
EVIL can easily place votes for his (high scored) delegate so that he falls in this rule. And adjust his votes each block so that he is still in that rule.

So he can free most of his stake to repeat this (assuming EVIL controls several high performing delegates). And he might "trap" all the LAZIES' votes into delegates he controls... AND THEN....
Title: Re: Attack scenario
Post by: Agent86 on June 20, 2014, 04:26:25 pm
emski,
Can you think of any attacks against "approval voting"?  It's quite simple; no down votes and every share can vote for (approve) of as many delegates as they like.  Delegates with the most approval win.  I think it's a perfect system for what we want and can't think of any reasonable attack.

More detailed discussion in the DPOS thread:
https://bitsharestalk.org/index.php?topic=4009.msg66308#msg66308
Title: Re: Attack scenario
Post by: tonyk on June 20, 2014, 04:31:26 pm
emski,
Can you think of any attacks against "approval voting"?  It's quite simple; no down votes and every share can vote for (approve) of as many delegates as they like.  Delegates with the most approval win.  I think it's a perfect system for what we want and can't think of any reasonable attack.

More detailed discussion in the DPOS thread:
https://bitsharestalk.org/index.php?topic=4009.msg66308#msg66308

Only concerns I have are:
-Is it really far more demanding/taxing on the blockchain?
-Is it as easy to vote out bad delegates?
Title: Re: Attack scenario
Post by: Agent86 on June 20, 2014, 04:49:31 pm
emski,
Can you think of any attacks against "approval voting"?  It's quite simple; no down votes and every share can vote for (approve) of as many delegates as they like.  Delegates with the most approval win.  I think it's a perfect system for what we want and can't think of any reasonable attack.

More detailed discussion in the DPOS thread:
https://bitsharestalk.org/index.php?topic=4009.msg66308#msg66308

Only concerns I have are:
-Is it really far more demanding/taxing on the blockchain?
-Is it as easy to vote out bad delegates?
I don't think it really adds much to the blockchain as you only need to specify changes in delegate selections, people probably won't be changing their selections as often.  There is some idea that a constructed database of votes would be bigger.

My thoughts:  Whatever the costs, it is almost certainly worth it.  It is just sooo much better than current voting method.

"-Is it as easy to vote out bad delegates?"
Yes. In fact it's much easier to vote out bad delegates than in the current system and much less likely that bad delegates get voted in in the first place.  In the current system if someone has enough stake to vote themselves in as a delegate (less than 1% required) it will be next to impossible to get rid of them as a delegate if they want to vote for themselves.
Title: Re: Attack scenario
Post by: emski on June 21, 2014, 12:45:29 am
emski,
Can you think of any attacks against "approval voting"?  It's quite simple; no down votes and every share can vote for (approve) of as many delegates as they like.  Delegates with the most approval win.  I think it's a perfect system for what we want and can't think of any reasonable attack.

More detailed discussion in the DPOS thread:
https://bitsharestalk.org/index.php?topic=4009.msg66308#msg66308

Its not that much about the voting system as it is about the predictable autovoting algorithm for LAZIES. I believe this could be exploited relatively easy and could be an issue.

As for the "approval voting" I'm not convinced in the advantages it has over current system (although I don't think current negative votes are good for the system but this is entirely different topic). In general "fair" voting system for our case is extremely complex and controversial topic that might require much more research.
Title: Re: Attack scenario
Post by: toast on June 21, 2014, 12:53:59 am
Its not that much about the voting system as it is about the predictable autovoting algorithm for LAZIES. I believe this could be exploited relatively easy and could be an issue.

I talked with Dan today about this. The voting algorithm could obviously use more thought, for more than just the reason you gave.
I don't think it will be hard to come up with a voting algorithm which makes it hard to manipulate LAZIES.

Also, I think 34% is not sufficient - the LAZIES will not need to push EVIL's delegates to 0, just out of top 101. They do not need to use all 33% of their LAZY votes to accomplish this.
Title: Re: Attack scenario
Post by: Agent86 on June 21, 2014, 03:39:05 am
Its not that much about the voting system as it is about the predictable autovoting algorithm for LAZIES. I believe this could be exploited relatively easy and could be an issue.
I share your concern about the autovoting algorithm but I also think it's the symptom of the bigger problem.  This type of algorithm is not really needed for approval voting;  you can just vote for some delegates that you trust and leave it at that.  The client can give you warnings if one of your delegates is messing up or give you some network statistics, but the constant vote balancing/autovoting isn't needed. (there's also more to voting and selecting candidates than network statistics)
As for the "approval voting" I'm not convinced in the advantages it has over current system (although I don't think current negative votes are good for the system but this is entirely different topic).
Negative votes is not an "entirely different topic" I proposed a voting scheme that doesn't rely on negative votes but you've said you're not convinced.

Do you think we can just get rid of negative votes from the current voting system and otherwise leave it as is?

Do you think it's fine if anyone (or group) with 1% can elect a delegate with no way for everyone else to get rid of that delegate?

In general "fair" voting system for our case is extremely complex and controversial topic that might require much more research.
OK, so you think it's complex. but I've given a place to start and proposed a system to solve the problem.  Are there specific reasons you suspect it doesn't or other specific reservations or you just haven't had time to think about it?
Title: Re: Attack scenario
Post by: emski on June 21, 2014, 08:09:44 am
Negative votes is not an "entirely different topic" I proposed a voting scheme that doesn't rely on negative votes but you've said you're not convinced.
Difference comes from the topic I intended - LAZIES vote manipulation. What problem will your proposed voting scheme solve ?

Do you think we can just get rid of negative votes from the current voting system and otherwise leave it as is?
Do you think it's fine if anyone (or group) with 1% can elect a delegate with no way for everyone else to get rid of that delegate?

I think negative voting shouldn't exclude positive vote. But I'm too lazy to research extensively on this so I stay quiet.

OK, so you think it's complex. but I've given a place to start and proposed a system to solve the problem.  Are there specific reasons you suspect it doesn't or other specific reservations or you just haven't had time to think about it?
What problem will your proposed voting scheme solve ? And as I already said I didn't research this extensively I cant say which is better.
Title: Re: Attack scenario
Post by: emski on June 21, 2014, 08:25:48 am
Also, I think 34% is not sufficient - the LAZIES will not need to push EVIL's delegates to 0, just out of top 101. They do not need to use all 33% of their LAZY votes to accomplish this.
Well 34% was just a number. Under very probable circumstances EVIL could manipulate LAZIES with just 3% or 4%. Pushing a delegate out of top101 requires 2%- X% , where X is the NET VOTE for 101th delegate. And even in the test network this diff is close to 1%. I believe that in the real network a lot of the top delegates will have NET VOTE of 2%, leaving 101th (X) with much lower NET VOTE.

If EVIL has 4% stake and acts like this:
1 EVIL votes up misbehaving delegate with 4% stake. (this may take some time while LAZIES downvote it, so EVIL can use up all his stake)
2 LAZIES vote it down with 3% (which may still be in top101 as the missbehaving delegate has 1% but this is the worst case).
3 EVIL moves his 4% upvotes away and places 1 well performing delegate into suitable position so that LAZIES' autovote for that delegate. (using his stake)
4 LAZIES abandon the misbehaving delegate and vote for EVIL's delegate from 3.
5 EVIL carefully removes his stake so that ALL LAZIES' votes are cast on his delegate from 3. (This might require following each block's vote changes and making sure the delegate remains on autovoting position)
6 if delegatesEVILControls < 51 repeat else ShowWhyEVILisEvil();

Using the above mentioned "algorithm" an entity with small stake could "redirect" much of the LAZIES autovote.
Title: Re: Attack scenario
Post by: emski on June 21, 2014, 06:15:15 pm
And as bytemaster proposed hardfork with removal of balances voting for misbehaving entity => this might affect LAZIES which are presumably normal lazy users who let the software autovote for them. Hardforking without their stake might be something even more evil than EVIL's initial plan.
Title: Re: Attack scenario
Post by: Agent86 on June 21, 2014, 10:35:47 pm
What problem will your proposed voting scheme solve ?
All of them :) including the ones you've already brought up and more:

*Autovoting algorithms that can be gamed
*Cat and mouse of trying to vote down delegates
*Delegates buying votes
*Downvoting has too much opportunity cost
*Large shareholders profit from voting themselves to be delegate or negotiating kickbacks.
*Small shareholders most likely don't get these benefits or can't negotiate kickbacks
*No incentive for delegates to reinvest profits to help the DAC
*Attacking entity can buy 50+ delegate positions through kickbacks
*Delegates don't need/have broad community support
*Shareholders can't vote for all delegates they trust (must pick 1 at time)
*Person with 3-4% has lots of power (can basically vote in or out a handful of delegates at will)
*Pulls community and shareholders apart instead of bringing them together.
*Is confusing and not intuitive
*Ruins our one chance to make a great 1st impression on 1st time users.

I'm sure there's more but that's some of them.  When something's broken there tends to be a lot of ways of seeing how it's broken.
Title: Re: Attack scenario
Post by: bytemaster on June 21, 2014, 10:54:12 pm
When the only thing at stake is whether or not blocks get produced the existing algorithm is probably sufficient. 

When we make the role of delegate profitable via dilution then the game changes dramatically.  Some of your concerns are not valid:

1) Cat & Mouse is costly (delegate registration fee)
2) Buying votes would likely result in down votes and thus not get you anywhere.
3) Voting yourself to be delegate is just another way of stating #1....
4) Lots of incentive... assuming people vote against bad delegates.
5) Down voting does not have opportunity cost... it is effectively a vote *for* anyone "but" the bad guy.  This is generally a more powerful way to express your opinion.
6) Kickbacks is just another form of #2

You have a very large list... but 99% is just rephrasing the same thing a different way.   

I think it comes down to this:
1) can someone with a couple of percent play the 'cat and mouse' game to effectively earn a profit while doing nothing?

I think the answer is no because it only takes one honest person of equal weight to vote against them every time they move *AND* large players have more to gain by having the network be a success.   
Title: Re: Attack scenario
Post by: Agent86 on June 22, 2014, 12:11:27 am
I agree the existing algo is probably sufficient if we don't dilute to pay delegates.  I also know a lot of things I listed are different ways of looking at the same issue.  I'm not trying to be difficult, I just believe approval voting is a real improvement and feel a certain obligation to advocate for it.

I just want us to hold ourselves to a higher standard.  I'm anxious for us to be able to leverage the power of reinvestment through dilution.  I think this is a big opportunity and the quicker we get there the better.  I don't want us to spend a ton of energy tweaking something to make it sufficient if there is a better option.  If there's something more future proof and better than sufficient that's what I want!
Title: Re: Attack scenario
Post by: toast on June 22, 2014, 12:12:45 am
Dan and I talked some more over dinner today and I think we have won him over.

Once he was convinced that there is unlikely to be a large honest stakeholder who does nothing but downvote bad delegates at huge opportunity cost then cat&mouse becomes unsolvable and that is the core issue behind all the reasons Agent86 listed. After thinking through some possible transaction compression techniques and realizing that it only makes the transaction about 3x as large, I am happy to announce that we are probably going to go with approval voting.

Some things to discuss: Should you still be able to downvote delegates with your stake? We are leaning towards yes but have not thought through it very carefully.
Title: Re: Attack scenario
Post by: liondani on June 22, 2014, 03:18:42 am
Facebook uses only up voting too (likes) for a reason... we talk about different things but maybe their approach can help us too...  marketing wise I mean... the idea is that :  "our network has only good delegates we are not full of scammers or bad actors or low quality delegates  ... " hope you understand what I mean... the feeling the community will have about "our" delegates... so for marketing only reasons I am against down voting... for security reasons you guys know better  ;)

Sent from my ALCATEL ONE TOUCH 997D using Tapatalk
Title: Re: Attack scenario
Post by: emski on June 22, 2014, 06:58:07 am
*Autovoting algorithms that can be gamed
Autovoting algorithm exploitation depends on the predictability of the voting algorithm not on the voting system. One can still exploit it even in approval voting.

*Cat and mouse of trying to vote down delegates
Yes. Having exclusive voting system (able to vote for only one entity) and ability to switch vote, enables a lot of vote-switching scenarios.

*Downvoting has too much opportunity cost
As I said I don't like exclusive vote - if you downvote you should still be able to upvote. However this particular moment needs more research.

*Large shareholders profit from voting themselves to be delegate or negotiating kickbacks.
The idea in DPOS is - shareholders elect delegates. If there is a large shareholder he will elect his own delegate(s).
As the votes are public negotiating will be always possible. Imagine the deal: You vote for me, I vote for you, none of us vote for anyone else.

*Small shareholders most likely don't get these benefits or can't negotiate kickbacks
This is correct in both systems. Negotiating efforts should produce value - you dont negotiate for 10 units but you will do it for 10 mil.

*No incentive for delegates to reinvest profits to help the DAC
Votes are always incentive. Most people will elect delegate that helps the system. These just for profit might not stay unless backed by large shareholders.

*Attacking entity can buy 50+ delegate positions through kickbacks
Where is that explained?

*Shareholders can't vote for all delegates they trust (must pick 1 at time)
Yes! This could be an issue. (although you can spread your stake by % )

*Person with 3-4% has lots of power (can basically vote in or out a handful of delegates at will)
Correct! And even such person could manipulate the autovote easily as I stated initially.

*Delegates don't need/have broad community support
Yes, but they must not irritate a lot of people because they could downvote them. Which is costly (unless upvoting/downvoting is not exclusive)

*Pulls community and shareholders apart instead of bringing them together.
*Is confusing and not intuitive
*Ruins our one chance to make a great 1st impression on 1st time users.
... cant comment on this.

It looks like approval voting is better. Although there are still things to consider.
Title: Re: Attack scenario
Post by: Agent86 on June 22, 2014, 09:07:53 am
we are probably going to go with approval voting.

Some things to discuss: Should you still be able to downvote delegates with your stake? We are leaning towards yes but have not thought through it very carefully.
+5% +5% +5% +5%
That's great!  I think this is a very good decision.  Downvoting is not at all needed and will only cause problems.  I think if you think about it you will come to same conclusion.
Title: Re: Attack scenario
Post by: xeroc on June 22, 2014, 09:45:34 am
+5% for the simplicity

Will I be able to remove my + 1 vote later on

Are we going to have a weighted approval internally for the wallet .. so that I can tell him .. A is better then B but i support both?
Title: Re: Attack scenario
Post by: Agent86 on June 22, 2014, 10:00:30 am
Emski, some comments where we may have disagreed:
*Autovoting algorithms that can be gamed
Autovoting algorithm exploitation depends on the predictability of the voting algorithm not on the voting system. One can still exploit it even in approval voting.
Approval voting (AV) is a different animal.  You don't need a computer algo to help you vote, just select some delegates you like and trust or seem to be doing good things for the community.  You can adjust it if others come along you like better or if someone you voted for can't get their act together.  Network statistics will be readily available and will inform your decision but we shouldn't encourage autovote algorithms imo.  I'm not voting for any delegate just because of network stats; I need to know what forum member or who is claiming to run the delegate.  Otherwise no dice for "mystery delegates" sockpuppets? with favorable network stats.  I'm sure we'll find plenty of good candidates so we don't have to get desperate.

Edit: if there is no autovoting for, but only automatically removing support for someone you've voted for that does something wrong, I think this should be fine.

*Large shareholders profit from voting themselves to be delegate or negotiating kickbacks.
The idea in DPOS is - shareholders elect delegates. If there is a large shareholder he will elect his own delegate(s).
As the votes are public negotiating will be always possible. Imagine the deal: You vote for me, I vote for you, none of us vote for anyone else.
Assuming approval voting is in use, If I see someone negotiating a deal on the forums saying "you vote for me, I vote for you, we don't vote for others."  There is no way I'm voting for this person, not to mention blasting them so no one else does.  They are not going to get elected using only the votes of themselves and some friends they've made deals with.  To be competitive in AV you need LOTS of support, maybe upwards of 50% of stake voting for you, not some stupid backdoor deal you negotiated.

*Small shareholders most likely don't get these benefits or can't negotiate kickbacks
This is correct in both systems. Negotiating efforts should produce value - you dont negotiate for 10 units but you will do it for 10 mil.
In "AV" there is no need for these negotiations and if they are discovered you have probably just blown your chance to ever be a delegate.  You need BROAD support to win, if you try to negotiate "you scratch my back I scratch yours" with individuals, the broad community whose back you are not scratching will reject your candidacy.  Delegates must act in the best interests of the DAC to appeal to the most people rather than just trying to appeal to those who voted for them.  The small guy will benefit just as much because delegates are looking out for the whole DAC and also courting small voters.

*No incentive for delegates to reinvest profits to help the DAC
Votes are always incentive. Most people will elect delegate that helps the system. These just for profit might not stay unless backed by large shareholders.
This is based on my contention that selfish voting would predominate (self voting, kickbacks etc.)  It's hard to convince someone to vote for you because of all you do for the community when they get a direct kickback elsewhere.

*Attacking entity can buy 50+ delegate positions through kickbacks
Where is that explained?
Basically, if you can encourage support with kickbacks people will look for delegates that offer the best kickbacks… take it from there, it's a slippery slope.