Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Agent86

Pages: 1 ... 16 17 18 19 20 21 22 [23] 24 25 26 27 28 29 30 ... 32
331
General Discussion / Re: Attack scenario
« 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.

332
General Discussion / Re: Attack scenario
« 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

333
General Discussion / Re: DAC employees
« on: June 19, 2014, 09:45:36 pm »
You can vote against any of the initial delegates to abstain.
I know.  This is true for current DPOS voting.
Sorry if it wasn't clear.  I proposed a different voting system to be used to elect DAC employees.  In that voting system (approval voting) the absence of a vote for is a vote against.  A person trying to get elected as a DAC employee would essentially have to get over 50% of the stake to actively approve him/her so anyone who isn't aware of this person's candidacy is a default "no" vote.  Abstaining allows that person to remove themselves from these votes.

334
General Discussion / Re: Delegated Proof of Stake (DPOS) White Paper
« on: June 19, 2014, 09:15:19 pm »
How do you vote if you do not have transaction? What I am missing?
You don't, voting requires a transaction.
(you make a transaction to yourself)

335
General Discussion / Re: Delegated Proof of Stake (DPOS) White Paper
« on: June 19, 2014, 09:13:32 pm »
Ok, my solution to "lazy" voters.  Voters should have: THE RIGHT TO ABSTAIN.

For instance: I am a shareholder but I know that I'm a busy guy with other things going on and there are other shareholders who are more on top of things.  I am going to put my shares in cold-storage for a year.  I should have the right to send those shares to cold storage in a state of abstention where I am removed from the voting process.  It doesn't make sense to have your shares voting for a particular delegate when your shares are in cold storage and you have no idea what the delegate you are voting for is doing.  I think this is especially useful for approval voting.  I think it will make the system more reactive and efficient.

In the current implementation you could probably just downvote an untrusted delegate on purpose (of course I'm not a fan of current implementation for many previously mentioned reasons.)

You need them to vote by default so that the network is optimized on performance metrics.

What do you think about giving everyone a downvote and an upvote ?  You're the one that realized that downvoting has a large opportunity cost if we start to pay delegates much.  So what would happen if they added a vote in both directions?  I am not pushing the idea, but it is one possible solution.  Make either vote optional and independent of each other.  It would increase the complexity of the type of games that could be played with voting, but it does remove the one problem of downvotes having opportunity cost.

Gamey, I encourage you to think about how approval voting works and what the ramifications are.

I thought about giving every share a vote in both directions some time ago:
https://bitsharestalk.org/index.php?topic=4660.msg60688#msg60688
I think it's an improvement but it just doesn't solve the problem.

Quote
You need them to vote by default so that the network is optimized on performance metrics.
I agree that you want to encourage participation and informed voting (client watches delegate performance and gives voting alerts or auto votes)
But, people with large shares in cold storage are not "optimizing the network" one way or another.
And their misplaced votes can make the network much less optimized.

336
General Discussion / Re: Delegated Proof of Stake (DPOS) White Paper
« on: June 19, 2014, 08:44:40 pm »
Ok, my solution to "lazy" voters.  Voters should have: THE RIGHT TO ABSTAIN.

For instance: I am a shareholder but I know that I'm a busy guy with other things going on and there are other shareholders who are more on top of things.  I am going to put my shares in cold-storage for a year.  I should have the right to send those shares to cold storage in a state of abstention where I am removed from the voting process.  It doesn't make sense to have your shares voting for a particular delegate when your shares are in cold storage and you have no idea what the delegate you are voting for is doing.  I think this is especially useful for approval voting.  I think it will make the system more reactive and efficient.

In the current implementation you could probably just downvote an untrusted delegate on purpose (of course I'm not a fan of current implementation for many previously mentioned reasons.)

337
General Discussion / Re: DAC employees
« on: June 19, 2014, 08:33:29 pm »
Ok, Another optimization to the voting algorithm:  THE RIGHT TO ABSTAIN.

A voter should have the ability to abstain.  For instance: I am a shareholder but I know that I'm a busy guy with other things going on and there are other shareholders who are more on top of things.  I am going to put my shares in cold-storage for a year.  I should have the right to send those shares to cold storage in a state of abstention where I am removed from the voting process.  This way I'm not gumming up the works for other shareholders trying to accomplish things by being a default "no" vote on everything.  I'm also not voting for somebody (employee/delegate) without keeping an eye on things so I might be voting for them after they have proven themselves unworthy of votes.

338
General Discussion / Re: Delegated Proof of Stake (DPOS) White Paper
« on: June 19, 2014, 04:04:19 pm »
It should not result in the majority dictating the rules on who all delegates should be or those with a minority opinion will have no representation among the delegates.
Recognizing this reality, we can embrace it fully and allow 51% of the delegates to fire any other delegate… All networks are only as secure as the trust you place in the 51%.

339
General Discussion / Re: Delegated Proof of Stake (DPOS) White Paper
« on: June 19, 2014, 04:02:46 pm »
1) most users are lazy and will not vote, if they did vote most users wouldn't know how to evaluate delegate performance.  This means the voting process needs to be simple with a reasonable automatic voting algorithm based only on statistical data about a delegates performance.
Bytemaster, the users you're calling "lazy" are the shareholders and this community! If the shareholders don't care who does?  I think you'll find people care more than you think, especially if delegates are paid well.   Ignoring poorly designed incentives means you rely on writing a client that votes in a sort of automated altruistic way and hoping people don't care enough to change it.  It's like having no mandatory transaction fees but writing a client that pays them by default and hoping people are too lazy to change the default.

My voting proposal is more simple, can also be automated, and critically, the automated voting aligns with the interests of the shareholder.

I agree a lot of effort has gone into coding this and we are perhaps close to a product that could be released and for some investors that's all they care about now.  So if we have to release this to satisfy the calls for immediate product than it is what it is.  But I think it's short sighted.
3) Voting is a way of exercising your influence over a percent of the block production proportional to your stake via a delegate.  It should not result in the majority dictating the rules on who all delegates should be or those with a minority opinion will have no representation among the delegates.
I think this tyranny of the majority fear is a misunderstanding.  All these institutions and DACs are "majority rules."  They are all subject to 51% attacks by the majority.  DACs are great in that they allow very low barriers to entry/exit and everyone is part of the DAC by their own volition; it's a free market with lots of options.

340
General Discussion / Re: Delegated Proof of Stake (DPOS) White Paper
« on: June 19, 2014, 11:38:46 am »
Quote
More importantly, storage requirement (not the blockchain, the constructed chain DB) increases to the same amount as it would be if you put the entire new vote set in each transaction.
I'm not sure I agree with this either.  The constructed database doesn't even have to specify which particular stake each vote comes from, it just needs to collect the aggregate votes for each delegate and then add or subtract from that accordingly.

No, I think you can't get around storing the votes because you have to know who to subtract the vote from (or with diffs, who you are allowed to subtract from). I think it is amortized w.r.t. transaction fees paid but it will still increase our max blockchain size by a large constant factor, terabytes instead of 100s of GB
Toast is right you need to store who everyone is voting for (multiple delegates instead of 1),  If you make a transaction that says I only want to vote for delegate 4, You need to know that your stake was previously voting for delegates 1,2,&3 to know who to take votes away from.  (sorry, I posted without thinking)

Maybe people would have less reason to split up their stake to vote for different people?
I think people have to pay an annual registration fee for delegates so maybe this keeps people from registering junk delegates?

341
General Discussion / Re: Delegated Proof of Stake (DPOS) White Paper
« on: June 19, 2014, 02:15:38 am »

No, I think you can't get around storing the votes because you have to know who to subtract the vote from (or with diffs, who you are allowed to subtract from). I think it is amortized w.r.t. transaction fees paid but it will still increase our max blockchain size by a large constant factor, terabytes instead of 100s of GB.

Let's try to think of a solution to the storage requirements for approval voting.
+5%

342
General Discussion / Re: Delegated Proof of Stake (DPOS) White Paper
« on: June 19, 2014, 12:40:32 am »
it is very easy for an attacker to max out the bandwidth, forcing other people to pay a higher transaction fee once they want to vote using the stake they received from him (trx fee is per-byte).
I think I addressed this by allowing a transaction to simply state "all prior delegate selections are void"  It doesn't need to individually specify to not vote for each delegate that was previously selected.
More importantly, storage requirement (not the blockchain, the constructed chain DB) increases to the same amount as it would be if you put the entire new vote set in each transaction.
I'm not sure I agree with this either.  The constructed database doesn't even have to specify which particular stake each vote comes from, it just needs to collect the aggregate votes for each delegate and then add or subtract from that accordingly.

A bad delegate can:
* exclude transactions
* miss blocks on purpose (delay confirmations)
* exacerbate an current fork by a block
* pay only his supporters out of his income

The last one is the only one that could complicate things. The only stable situations I can imagine are if he would always get voted out in favor of someone paying normal dividends, or if every delegate is paying only his supporters and the situation looks almost identical.

I think "approval voting" will not reward vote buying.  So I'm not worried about delegates only paying their supporters using approval voting.  Bad delegates will get voted out even if it isn't immediate and it doesn't seem like they have much to gain by misbehaving.

If all delegates only pay their own supporters the situation is not at all "almost identical."  It means that delegates can't give money to a developer or spend money on a marketing campaign that benefits everyone, because their voters just want as much of a kickback as they can get.  It's not a good situation.  If delegate positions can be bought than someone can buy over 50% of the delegates.

I would be very surprised if we don't eventually move away from the current voting proposal or get out-competed by someone else who does it right.  I'm not saying it would be an immediate disaster because there probably isn't anyone interested in creating problems.

Also from a user experience perspective it is way easier to just select the delegates you like, rather than having these trust scores and balancing which stake goes to which delegate and when to downvote etc. It's a turn off, hard to understand, and is flawed anyway.  Why try to get people used to it?

343
General Discussion / Re: DAC employees
« on: June 18, 2014, 12:07:15 pm »
I am updating the voting method and I believe this voting method can be robust and fair, it also requires broad consensus (over 50%):

The voting method for employees I propose to be "approval voting."  There are no down-votes and no restriction on how many different employees you can vote for using your stake.  Not voting for an employee indicates you do not support that employee.  Along with your vote for an employee you indicate an appropriate annual salary in bips (gets paid out daily).  Only an employee with over 50% support from the DAC will end up being paid.  Their salary is the median voted by stake (people who did not vote for the employee are included in the median as voting for a "0" salary).

Any "inactive stake" (no transactions for over 1 year and paid inactivity penalty) should be removed from the voting algorithm.

344
General Discussion / Re: Help on an unimportant topic
« on: June 18, 2014, 10:13:26 am »

345
General Discussion / Re: Delegated Proof of Stake (DPOS) White Paper
« on: June 17, 2014, 11:30:42 pm »
Yea, I guess my voting proposal is called "approval voting"
Regarding multiple-winner approval voting:

Quote
Approval voting can be extended to multiple winner elections. The naive way to do so is as block approval voting, a simple variant on block voting where each voter can select an unlimited number of candidates and the candidates with the most approval votes win. This does not provide proportional representation and is subject to the Burr dilemma, among other problems.

Other ways of extending Approval voting to multiple winner elections have been devised. Among these are proportional approval voting[48] for determining a proportional assembly, and Minimax Approval[49] for determining a consensus assembly where the least satisfied voter is satisfied the most.
So the wiki has a sentence that says it's not good for multi-winner voting (without citation).  However following their links shows that multi-winner approval voting is the preferred method of:

American Statistical Association (ASA)
Game Theory Society (GTS)
American Mathematical Society (AMS)
Mathematical Association of America (MAA)

Maybe these guys are on to something?

I think doing our homework on voting theory is well worth the time but we also need to look at how it relates to our unique application with unique attributes.  For instance, our elections are "real time" so everyone can see who everyone else is voting for and the system has a chance to come to "equilibrium."  I think this is potentially a huge advantage over systems with a single time point vote.

Ranking is not needed because ranking is used for "instant run off" elections.  You need this because if you voted for a candidate that didn't stand a chance you only find out later and wish you could have put your vote to better use.  But with "real time" voting you can look at the layout and vote accordingly.  No one has more info than anyone else.

The main complaint against approval voting seems to be that it doesn't provide "proportional representation."  For instance if 60% of population is Repubican and 40% is Democrat and they elect reps by nationwide approval voting, all the winners could be republican.  And I guess the idea is that congress should have 40% democrats if 40% of population is democrat.  Personally, I don't agree with the premise.  The point of voting is to come to a consensus and your 40% democrats aren't going to get their way when anything is voted on in congress anyway. "proportional representation" seems chaotic.  This way you can have a congress with a single digit approval rating and everyone gets voted back in because they only have to aggressively court their own constituents by doing things like sending pork barrel projects back to their districts and they don't give a rat's a$$ what the rest of the country thinks of them.  Do we need to make sure there is a rep in congress to represent the interests of the 5% of the population that are extreme racists?  Do they need proportional representation?  What other subgroup of extremists need to have their views "represented"?  It's silly IMHO. Perhaps the existence of 2 political parties in the first place is an indication of a broken system.

The other complaint I found against approval voting (for single position election) is that it could advantage a strategic voter with better info.  For example, approving of your second choice could cause your first choice to lose when they otherwise wouldn't, but if you had good polling data you would know who to support.  I think this is solved by the fact that we vote in "real time."

Anyway, approval voting seems significantly more robust to me than current implementation, easier to understand, and MUCH more useful if we hope to put money into the hands of delegates who advance the interests of the DAC in other ways.

Reaction time may be worth discussing because a lot of people will have large stakes in cold storage, not everyone is ready to voice an opinion and vote out a bad actor on the drop of a hat.  How much damage can a delegate that turns bad do if they aren't voted out instantly?  I feel like bytemaster has said a bad delegate can't do much damage and can't gain much but I would like clarification.  BM?

Sidenote suggestion:
When somebody gets assessed a 5% one year inactivity fee, their stake votes should automatically be removed from the voting algorithm because they are clearly "asleep at the wheel" assuming they haven't lost their private keys.

Pages: 1 ... 16 17 18 19 20 21 22 [23] 24 25 26 27 28 29 30 ... 32