Quote from: MeTHoDx on November 13, 2014, 06:15:05 pm

Here's a concern that's been on my mind lately: if a shareholder with a large stake (let's say 7%) were to either die unexpectedly or lose access to his private keys, would the delegates he voted for have 7% approval forever? If true, I propose votes expire after a year.

Vote decay has been suggested here and it looks like it was declined by BM on the next page of the thread:
https://bitsharestalk.org/index.php?topic=10937.msg144860#msg144860

I think the general consensus has been that we assume people have lost their keys if they don't make a transaction at least once per year...  This was part of the idea behind the inactivity fee and I think it holds true for votes also.  I think BM opposed the "vote decay" mostly because of calculation expense but I don't think that means he opposes votes expire after one year.  I support votes expire after one year and stake is considered "inactive" if it hasn't moved in one year.

I want to see what people think of an idea to throttle approval of delegates.  The point is to allay fears that some entity accumulates a large secret stake and then quickly votes in otherwise unknown delegates before anyone has time to react.   Throttling could allow time to publicly demand an explanation if unknown delegates start getting huge support.  It would give time to "get out the vote" to coalesce around more well known delegates so the offending delegates don't get in or even prepare to consider the extreme measure of hard forking out stake if no one knows why these delegates have any support.  Basically there is no restriction on a delegate losing approval but a delegate can't gain more than X% approval in a 24 hr period or similar rule.  Kind of like the idea that trust takes time to gain but is quick to lose.

What do you guys mean by "non binding"?
Is voting in or out a delegate non binding?  How about voting to dilute to pay for a marketing / recruitment move?...

By "non binding" I just mean that there is no direct consequence of the vote/poll, like an opinion poll.  Voting for delegates or pay rates is binding.

Agent86, at least some things need to be done off chain, right?  For example who/how are survey question designed, and can they be modified, or improved to achieve more consensus after voting starts?

You could register survey questions on the chain.  You wouldn't be able to modify the question/statement retroactively.

The limitation has to do with transaction bloat rather than whether the proposals are binding or not. My proposals on this topic for on-chain proposals involve only 5 additional bytes but have the limitation that delegates must be the ones to submit the proposals to the blockchain (not just any user) and there can only be up to 4 proposals to be voted on at any given time.

I meant non-binding proposals reduces need for delegate processing/database and I thought this would be the more important issue.  I'm not suggesting increasing max transaction size.  Voting for a ton of things would require paying for multiple transactions.  I'm also not saying you can't enforce reasonable limits.

I don't like limiting proposals to only delegates.  The on-chain solution still seems easier for the user to me.  Is it really much "cheaper" for someone to go to the trouble to manage this off chain?   What do you think of identifiable balances in transactions can be used to poll? I'm proposing to implement polls in an analogous way.

And I can't then take my stake and vote twice?  If the amount of the transfer is is the stake amount, what prevents me from voting and moving my stake and voting again?  Is this case detectable within the blockchain? 

Sorry I still don't understand TITAN ins and outs.  The answer would be obvious to someone who understands this part of the product.

To be clear, even though you can't vote twice for the same issue with same stake, you could use the same stake to vote on 1000s of different issues at the same time and you can change your vote on any issue at any time.  We could even agree on a number that "clears" all prior votes, but really I think there should just be formal polling implemented on chain in the long run.

Maybe this works as a fast hack for stake polling?

Just say, if you agree with "X" send a transaction to yourself with an amount ending in 5.6243 BTS (or other random small amount).  If you disagree the amount should end in 5.6244.  To vote on issue "Y" send transaction ending in 5.6345 for "yes" or 5.6346 for "no".  The total amount moved is the stake voting (combine inputs).

The balance is validly voting unless any of those shares are subsequently used to vote in the other direction on the same issue and are not counted twice if they vote same direction on same issue.

Then all you need to do is look at the BTS transaction history to add up the votes.

the other thread it polling was recently discussed: https://bitsharestalk.org/index.php?topic=10879.0

Bytemaster, you still haven't explained why the "delegate proposal ratified by shareholder vote" proposal I made doesn't scale (or if it does scale, then what the other reasons are for why you are still against it). I discussed the important technical parts here, here, and here. The implementation I described only adds 5 bytes to each transaction (which is not a big deal, especially considering more than that amount of space will be freed thanks to removing the memo field with the new lightweight client mail system), and I am fairly confident it doesn't need to add much in transaction processing time. If I am wrong I would appreciate an explanation of why.

On the other hand, if you are against this proposal for other reasons (philisophical, you think it is socially a bad way to manage a DAC, etc.), then I would like to hear a clear reason behind your opinions. The main difference that I see is that it forces the stakeholders as a collective to come to a consensus before any change in worker payments gets implemented (so it is an atomic action). In the delegate system, the approval of a single delegate candidate can gradually rise until it crosses the threshold into the top 101 and the delegate starts getting paid. In my system, enough stakeholders would need to agree before a new worker could be hired, fired, or have their salary changed. Obviously requiring 51% approval for this would be a bit too much and would result in gridlock.

My suggestion around this gridlock is to use the following rule for decisions that involve changing workers and their pay (other more important DAC decisions could have stricter rules). The fraction of total stake in approval of a proposal is define as A. The fraction of total stake in disapproval of that proposal is defined as D. The remaining fraction of stake, N = 1 - A - D, has to be neutral on that proposal. For these worker-related proposals to become ratified and thus activated the following conditions need to be true as of the latest block:

• The proposal needs to be older than 24 hours (to give some time for stakeholders to even see there is a new proposal).
• At least 15% of stake needs to be voting on the proposal, or V = A + D >= 0.15.
• The net approval, A - D, must be sufficiently large, which is define precisely as A - D >= 0.15 * (1 - A - D).

Working out the math, one can find that the ratio between approval and disapproval, A/D, needs to satisfy the inequality A/D >= 2/(1 - 0.15*(1/V - 1)) - 1 for the third requirement to be satisfied. I plotted the right hand side of that inequality over the domain [0.15, 1] over which it is valid due to the second requirement. This plots the minimum ratio between approval and disapproval needed for the worker-related proposal to be ratified as a function of voter participation. At the minimum participation level of 15%, there needs to be at least 12.4 yeas to every nay, which is unlikely to happen unless the proposal is very uncontroversial. For a proposal to be ratified with only a 2:1 ratio between yea:nay, the DAC would require at least 31% of stake to participate in the vote. And clearly if everyone participates in the vote, the proposal can be passed if there is even just a tiny extra bit of stake in approval of the proposal compared to the stake in disapproval of the proposal.

I think taking the attitude that we will never get 51% approval on anything is defeatist.  I think it reflects an unwillingness to do the work/system design/creative problem solving needed to get there.

My view is if your system can't reach 51% consensus on anything it is one of two problems:

   1) The system design, user interface, or incentives are flawed.
   2) You may need to reconsider the group of people you have chosen as your fellow shareholders
   
Of course you don't write off people as lazy until you have very carefully examined everything in point #1.  #2 might seem harsh but I think of these systems like businesses and if you can't agree on anything with your co-owners or they have "checked out"  you may be forced to consider parting ways… (maybe this possibility will be part of their motivation).

Quote from: alphaBar on November 03, 2014, 05:37:35 pm

I hate to be "that guy" but I want to point out that delegate pay should probably not be treated as a reward for "past" work (although that can help to establish the trust that you need to get "hired" initially). I think of your past work as your resume for getting the job. In order to be voted in you should publish a list of projects or features that you'd like to implement, budget, timeline, and key results. Then once you are voted in you should commit to regular status updates, milestones, metrics, open source development, and anything else you can do to give shareholders confidence that they are getting their money's worth.

Lastly I'll just say that this is one of the main pitfalls of the dilution proposal. Personally I think the threshold for ongoing performance evaluation and management is too high for the average stakeholder. We already have very low vote participation, and the only thing we're managing is block production. What will inevitably happen is that people will trust their votes to third parties who have the time and expertise to evaluate the performance of a given delegate. Those people then become yet another "layer" of separation from the stakeholders, which in turn potentially impacts security since we've conflated the rewards for block production and literally everything else the "company" does. /rant

I agree, if you want my vote there needs be a roadmap for future work and not compensation for past work.

It is a complex system and an experiment... I think that major stake holders will act to get things done.

I want to say that I totally disagree with this philosophy/attitude.  Why shouldn't we compensate svk for past work?

We are going to ask him to open source his work and then tell him he deserves no compensation for his past work except a pat on the back, and then ask what else can he do for us?  Just because the work is done so maybe he doesn't have much "room to negotiate"?  I think it's a bad attitude that serves to discourage others from freely contributing and shows a lack of appreciation.

Do we want to reward results or just "work"?  I'd rather reward and encourage results.

These systems codify a "fair" or socially agreed distribution of stake.  I think to get "buy in" we should cultivate a sense of fairness.  I think it is ridiculous to expect people will contribute anything of significance if we take this attitude and I think it encourages competition.  I'm not saying we reward things of questionable value but bitsharesblocks was a legit contribution.