Mastering Approval Voting

[sittingduck]

Have people vote on threshold.

[xeroc]

Tiered threshold makes sense for me. However we need to define the tiers in detail, and identify which feature is on which tier, it's a bit hard imo.

Thats why I think we should not use this solution until we gathered some experience with hardforking proposals ..
i *personally* prerfer option 2

[abit]

Tiered threshold makes sense for me. However we need to define the tiers in detail, and identify which feature is on which tier, it's a bit hard imo.

[xeroc]

It's still a draft .. I want to reach out to the community to get more input ... you know .. more eyes can improve proposals better ..
the whole idea (and we haven't been very consequent yet) is to have the proposal leave "draft" and enter "accepted" before the worker goes out ..

[abit]

I wrote a quick BSIP-draft for this:
https://github.com/bitshares/bsips/issues/4

Input appreciated

Thank you.
Have you created a worker for this BSIP? I'll approve it asap.

By the way, why not use a push request instead of an issue?

[xeroc]

I wrote a quick BSIP-draft for this:
https://github.com/bitshares/bsips/issues/4

Input appreciated

[xeroc]

The threads purpose was not about HOW votes are valued .. but how we interpret votes given the different kinds of decisions that have to be made!
Solving the voting apathy will not help figure this out!

[Pheonike]

I had an idea awhile about called influence voting, I think it could work with a little modification. A person who locks in a certain amount of BTS for a period of time gets more voting power for those shares.  A timer starts and proportional brings down the value of the votes until they again 1:1 For example,

I have 10,000 bts. If I lock 5000 shares up for 30 days, I will get 3x the voting power for those BTS.  They voting power for those 5000 BTS will go down 3.333% a day until the 30 days is over.  I can have the option that the 3x influence resets to 30 days every time I vote. I re-lock mine shares up.
We can have set parameters that the longer you lock up the funds, the more influence your vote has. Maybe 10x if I lock shares up for a year.

[Empirical1.2]

dPoS will continue to be broken as long as there is no incentive to vote or penalty for not voting. At this point, I think the only way to fix it is by providing a penalty if you don't vote every so often, then your stake should be confiscated by the blockchain and burned. Kind of off topic from OP.. my bad.

So, to avoid penalty or earn incentives,  former non-voters would just vote randomly without thinking.
"Too lazy to vote, too lazy to think about a coerced vote."

Result: there are now a bunch of random votes blocking new decisions and making it hard for dedicated thinkers to respond quickly when issues do arise.  Therefore the project wanders adrift at sea without a rudder.

How would that do anything but harm?

BTS shareholders (or shareholders in any company) have made a capital investment in the future of that company.

Unlike centralized companies that require a vote as little as once per year, A decentralized company requires shareholders to engage in frequent voting which requires additional 'work'  & as Bytemaster correctly states in his latest blog imo...

Many people vote once and then forget to change their vote or they vote for a proxy and then forget to follow up. The usual end result is that it becomes difficult to vote out incumbents or vote in new individuals. The presence of voter apathy is a sign that incentives are not properly aligned in the system.

http://bytemaster.github.io/article/2016/01/04/The-Benefits-of-Proof-of-Work/

By incentivising voting and penalising non voting you are aligning incentives so that the small BTS shareholders are now paid for the additional 'work' and as they are BTS shareholders who have made a capital commitment to the success of the project, it is likely the majority of votes will not be random but considered.

Imo, either the majority of small BTS shareholders will vote responsibly if given an incentive & if not, then it means BTS is the most insecure blockchain on the planet and can be attacked with 0.05% of BTS.

So it stands to reason small BTS shareholders may be willing to proxy their vote for an annual  paid monthly even ultimately to the detriment of their investment, especially if they thought the pools/proxies intentions were good.

So an example of an attack...

'Hi guys, I think BTS should incentivise voting and give those that vote up to  a year funded through an annual inactivity fee for those that don't vote. Please proxy your vote to me, to give me more impact in making this change that will get more people to vote and make BTS more secure.. To demonstrate how effective this is, I will fund the  initiative myself and pay everyone that proxies their vote to me  p.a paid monthly. If I run out of money or fail in my attempt to help influence this positive change, please feel free to remove your vote. '

Then I may be able to acquire 13% stake for a monthly cost of 0.05% of total BTS. Then once acquired I elect witnesses who block new votes and if it's not possible to print BTS and send it to the exchanges for sale, I will at least short BTS while the network is being attacked.

Like BTC, there may also be outside influences, like .gov or banks or competitors that would like to target BTS for 0.05 - 0.13%  of stake. We already saw how Rune wanted to perform a hostile takeover of Bitcoin.

[Stan]

dPoS will continue to be broken as long as there is no incentive to vote or penalty for not voting. At this point, I think the only way to fix it is by providing a penalty if you don't vote every so often, then your stake should be confiscated by the blockchain and burned. Kind of off topic from OP.. my bad.

So, to avoid penalty or earn incentives,  former non-voters would just vote randomly without thinking.
"Too lazy to vote, too lazy to think about a coerced vote."

Result: there are now a bunch of random votes blocking new decisions and making it hard for dedicated thinkers to respond quickly when issues do arise.  Therefore the project wanders adrift at sea without a rudder.

How would that do anything but harm?

[TravelsAsia]

At this point, I think the only way to fix it is by providing a penalty if you don't vote every so often, then your stake should be confiscated by the blockchain and burned.

It's hard enough to attract users, this would be a PR nightmare.

[CoinHoarder]

dPoS will continue to be broken as long as there is no incentive to vote or penalty for not voting. At this point, I think the only way to fix it is by providing a penalty if you don't vote every so often, then your stake should be confiscated by the blockchain and burned. Kind of off topic from OP.. my bad.

[sittingduck]

Great ideas

[xeroc]

Thinking about the future of BTS I realized that quite some homework has to done first.
What is still unclear to me are the requirements for 'approval'.
I came to the conclusion that we probably want to distinguish different thresholds for different objectives.

First of all, an approval needs to be a binary decision. The, what we already have by now is approving a worker to be paid by the blockchain. The approbal here is reached if the worker proposal is upvoted enough to receive a pay (either above the current refund400k or above any of the other refund/burn workers later). So that is already fine, shareholders know the drill and have several options (upvote/downvote).

What is left is a consensus about how a hard fork proposal delegate should be dealt with and how to reach consensus about it.

My first thought would be to set the threshold for approval to exactly zero net positiv votes. Here shareholders compete with pro and contra votes. If the net vote result is negative, the proposal is rejected. If it is positive, the proposal is accepted. That would give everyone a 'fair' share in the decision but of course has (arguable) drawback that whales' decisions are difficult to prevent. (Arguable because of "shareholder"!!! consensus) ..

To relax the rule, we could have a threshold worker (zero pay) so that shareholders can define the threahold as well ... The interessting consequence would be that those that dont want to see ANY change to the protocol can upvote the threahold while thoae that want a flexible protocol can downvote it ... This worker would then correspond to refund worker for hired positions.

To extend the idea, we could (maybe) characterize different BSIPs into categories (tier-1, tier-2..) and have a distinct thrshold for them.

But the leads to the question whether we. (Not necessarily the shareholder) can find a specification for the categories.

And then of course we can combine them. A hard threshold which must be passed by ever soft threshold and a successfully approved proposal must surpass the hard threshold AS WELL as the category-specific soft threshold.

Discuss!