I see one block signed by my delegate. And the same block missed by another one of my delegates.

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.

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.

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....

There are delegates with negative "VOTES FOR".
66          unelected-testz1         -885053986          106224251086        -1.071245313 %      0               4

Some of the initial delegates lack unelected prefix.
41          crazybit                 9215                106210341099        -1.06225431 %       2               2
40          coolspeed                0                   109830374550        -1.09845984 %       0               4
28          delegate-alt             6927                104666022311        -1.046808958 %      3               1
https://raw.githubusercontent.com/BitShares/bitshares_toolkit/master/libraries/blockchain/genesis.json

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?

The primary thing we are trying to avoid is giving the initial delegates undo advantage of votes from those who lost their keys, donated from an exchange, or are too lazy to get involved.  For this reason starting all votes as 'negative' votes means that the real names with real votes will get in priority over those we assign.  It also removes any accusations of bias in initial delegate selection. 

Changing the name to be 'unelected-your-name-x' allows people to see your performance and thus vote for 'your-name-x'. 

We could give you just 'your-name-x' but if we start you out with negative votes from passive users it may end up poorly for you.

Thanks for the explanation!


One more thing... I've seen somewhere comments about enabling "no-vote" state. Isn't this contrary to the idea in the DPOS whitepaper? Will this be implemented?
Here is the quote in question:

This sounds like a good idea. I'd modify it in that after shares start paying inactivity fees they should no longer vote, which means we need a no-vote state anyway, instead of generating fake delegates to sink votes.

Is it normal for me to see that much difference on this message:
--- syncing with p2p network, XXX blocks left to fetch
--- syncing with p2p network, 4523 blocks left to fetch
--- there are now 23 active connections to the p2p network
--- syncing with p2p network, 3762 blocks left to fetch
--- syncing with p2p network, 387 blocks left to fetch
--- there are now 22 active connections to the p2p network
--- in sync with p2p network
--- there are now 23 active connections to the p2p network
--- in sync with p2p network
--- there are now 24 active connections to the p2p network
--- syncing with p2p network, 4527 blocks left to fetch
--- there are now 25 active connections to the p2p network
--- there are now 24 active connections to the p2p network
--- there are now 23 active connections to the p2p network
--- there are now 24 active connections to the p2p network
--- syncing with p2p network, 4528 blocks left to fetch
--- there are now 23 active connections to the p2p network
emski (unlocked) >>> get_info
{
  "blockchain_head_block_num": 22474,
  "blockchain_head_block_time": "20140619T083400",