It is like political parties.  I can't see anyone seriously argue this doesn't increase centralization.

The guy who mentioned Ripple is off base, but that is the criticism we are going to see.  This definitely has upsides, but meh.

Giving it a different name (RDPOS) isn't a good idea.  You guys had problems with the weird BitShares X branding.  Now we'll have RDPOS and DPOS.  Explaining how RDPOS improves anything will not be an easy sale.  In fact, "recommended" psychologically frames the whole process negatively in terms of what crypto people are wanting.

The basic problem is that the motivations of stake holders are not the same for Delegates.  Delegates are in it to profit off transaction fees by being elected.  Users are in it to profit of appreciation or the burn rate.  Delegates aren't necessarily looking after users.

Delegates will provide a self-serving slate that end-users will not easily be able to discern.  In addition, we may end up with a lot of nastiness. "Such and such was removed off slate GOOD GUYS for petty reason #4923".  It just won't look good.  You are centralizing things on different levels, allowing more gamification of the system.

"RDPOS" is not a good idea.   I don't know if I have the energy to argue about it anymore though.

What specifically is the flaw in approval voting that is bothering you so much??  Give people a chance and some time, this is new to everyone and is just released.   Why not wait until we have a working windows wallet before declaring shareholders too lazy to vote?  Not everyone will drop what they're doing and download a buggy client to participate on day 1.

We are putting more and more pressure on voting. What are the incentives to vote again?

I don't mind expecting delegates to provide price feeds because it's a simple task to do and is easy to verify they are doing it.  It requires similar competencies as writing blocks: reliably perform a simple task with great up-time.  Either they are doing it or they are not and it's easy to see which ones are.  So voting is easy and if a couple delegates are messing up it's not the end of the world because the others pick up the slack until they are removed.

I share your concern with regard to the "soft approach" as I think it is expecting a lot out of the voting process.  You are now expecting delegates to all make good "judgement calls" about selectively excluding transactions and then expecting voters to judge their judgement... this makes me nervous.

The incentives to vote are similar to shareholders of any company.  But voting in our system is easier; you can do it with a couple mouse clicks.  Info/data to make good decisions will be readily available.  (contrast this with people standing in line to vote in a presidential election, ostensibly the only incentive is the 1 in a million chance that you are the deciding vote between corrupt politician A vs corrupt politician B.)

When we implement dilution I can easily see requiring 50% approval of a delegate to receive the dilution pay.

As delegates already set their pay rate, it would be a negotiation between the potential worker/delegate and the masses. 

This may be a superior alternative to saying all delegates get paid via dilution.

I think this is workable but my preference would definitely be to have workers be separate and directly voted on.

Of course I3 is way too busy at the moment, but maybe down the line if I could get enough investment on board, I could get a quote from I3 for how much you would charge to implement this?  Then I could contract DACs Unlimited to launch it with an agreed distribution and see if the investors agree to the price estimate and go for it.  (or maybe we have luck finding other competent developers & DAC launcher)

Do you imply that the shareholders of this DAC get a (fixed?) percentage of all the DACs that are funded this way? If not where does this "crowd funding DAC" get its value from?
And do you mean that the majority of the shareholders decide on which dev team to fund?
An issue might be that the funds the dev teams receive are not as liquid.... Invictus had the problem that PTS are not very liquid I think.
Also I would have to trust the judgement of the other shareholder which is can be good and bad.

I believe in shareholder controlled spending, whether that is determining dividends, or dilution, or determining where the money goes.  This is how real companies work and I think if we want to appeal to serious investors this type of arrangement will be most appealing.  The more stake you own the more power you have over how the company allocates resources.  With this in mind, the idea of the social consensus is perhaps not as cut and dry and maybe the social consensus doesn't fully account for distribution via dilution.  But that doesn't mean it shouldn't be done or that the market won't accept it.

My first approximation would be that we give a good amount in the original DAC to AGS/PTS, maybe 35%/35% with 30% to initial investors.  We need active shareholders for this to work, so people must actively claim their stake or after a certain reasonable time it expires.  This way we don't give too much stake to those who have no interest.  I think the market would accept this as honoring the social consensus.  From there we could see this DAC as primarily a ProtoDAC for a new family of DACs that honor the original.  There would be no specific obligation to further honor AGS/PTS in DACs that were funded by this DAC.  That said, there still may be a reason to do so and it is not precluded, and in some situations there might be better distributions than completely honoring the ProtoDAC.

As far as the shares not being liquid, I think you would be pleasantly surprised.  We may need to bring in new investment capital as we grow, but I would be happy to take a lead in finding investors and making sure that developers who need money to pay their bills have investors ready to buy their shares.  Most startups don't have super "liquid" shares but they still find eager investment capital as they grow and prove themselves.

I think there are some great ideas for DACs that I3 may or may not implement.  They don't have the time and resources to do everything.  With this in mind, I want to reach out to potential developers who are interested in creating DACs and to people who may be interested in investing.

If there is enough interest I would like to propose a DAC that is essentially the bitshares toolkit with one change. In addition to voting on delegates, shareholders can vote on a separate class called "workers".  Workers are paid via issuance of new shares and must have support from over 50% of the stake.

This allows the DAC to fund the development of new DACs that honor the shareholders.  It will be a more compelling case for our shareholders to be honored in new DACs when we are funding the development.  It is also easier to fund development over time rather than all at once and therefore protects investors.  If this DAC was successful, more ambitious DACs would be worked on.

This DAC would require active shareholders to be most successful so initial distribution should be handled carefully. 
Unfortunately I'm not in a position to create this DAC but I would be happy to invest to fund its creation with anyone who is convincingly able to do it.

Thoughts?

I have some bad news for you:
http://en.wikipedia.org/wiki/Voting_paradox
http://en.wikipedia.org/wiki/Arrow%27s_impossibility_theorem

Neither of these limitations relate to our application.  These describe single time point elections; we vote in real time.  Approval voting works great for our application.

Approval voting made a lot more sense when there was talk of delegates being able to give back to those who vote for them.  If delegates can see who voted for them and can utilize kickbacks then that is when approval voting would become useful.

Delegates can still see what addresses are voting for them.  Do you think something has changed?

Quote from: merockstar on July 10, 2014, 10:02:00 pm

Quote from: bytemaster on July 10, 2014, 09:45:40 pm

Can someone explain the process, risks, rewards, etc of delegating your forging power in NXT?

havent studied it in depth, but from passing glances at the nxt forum people talk like "leasing" your forging power to somebody else is risk free. you still hold your coins, the only risk is that the guy running the pool could run off with tx fees (forged nxt).

wanting a comparison?

EDIT: durr. yes you are, "the scalability of DPOS vs POS vs POW when it comes to decentralization"

Thus the process of leasing is like dpos prior to approval voting.   At scale the pools will have to eliminate kickbacks to cover costs and remain compatible. 

Question:  can you lease your stake to more than one pool? 

No, with leasing in NXT you can only lease to one account and that account gets the forging rewards.  The only benefit of a pool is really to get a more consistent reward in small increments but you would have to trust the pool to send the payments back to you.

I suspect most smaller holders won't bother with forging because they have to run their computer all the time to do it, even though they don't need to risk their key.  If people end up using pools, there is no size limit, and that could also be a centralization problem.  This can also lead to controlling the network by giving nice rewards to people who lease their forging power to you.

The other problem is their source of randomness... I think they were trying to depend on the "random" act of people stopping and/or starting forging in a 24hr period to get a random number to determine the order of forging.  I think they have considered moving to a source of randomness like ours but haven't done so.  I think they recognize some weaknesses and want to switch to "transparent forging" but again still haven't officially done so.  I'm no NXT expert and if I get time I could look into it more but they are sure to correct us if we make a comparison.

I believe there were some other issues at other points such as the probability to forge a block isn't exactly proportional to your balance and slightly favors larger balances.