Proposed details for BSIP-22 specifications (vote decay) #153

MichelSantos · 2019-03-06T15:37:20Z

These are proposed details about vote decay

Code specifications can be added if these details are acceptable to @grctest

… vote decay for some referendum categories

MichelSantos · 2019-03-06T15:58:22Z

@grctest The original specification for "Accounts blacklisted from voting (exchanges/services/scam accounts)" was temporarily removed with the idea that it might be better addressed with its own BSIP unless you think that it is critical to include as a part of this BSIP.

The original specification also suggests that work proposals are not affected by vote decay at all. Does that match your vision, or do you have something more nuanced in mind?

grctest · 2019-03-09T00:16:25Z

I agree with the removal of vote blacklists from the BSIP. Regarding worker proposals, since they have a short fixed duration of payment I don't think they need vote decay.

bsip-0022.md

pmconrad · 2019-03-10T11:04:40Z

bsip-0022.md

-} else {
-    decaying_vote_weight = original_vote_weight - ((original_vote_weight/max_days_decay)*days_since_decay_began)
-}
-```

 # Discussion



The calculations to be performed will significantly increase the duration of the maintenance interval, and with it replay time. I would like to see some numbers on the effect of the proposed changes assuming they had been activated at the beginning of our history (1. with the assumption that proxies are never updated, and 2. with the assumption that proxies are regularly updated).

To avoid increasing of maintenance period, it would be better just assume that accounts with the last outgoing transaction(or other initiated by user operation) more than 1 year ago have zero vote power. imho.

If the last account activity was more than 1 year ago (for example), it means that the holder has died, lost his keys or simply doesn't participate in the community now, therefore we can't consider his voting power to be actual.

To avoid increasing of maintenance period, it would be better just assume that accounts with the last outgoing transaction(or other initiated by user operation) more than 1 year ago have zero vote power. imho.

I think that this suggestion can be an optimization that can avoid some of the arithmetic overhead. The original BSIP did have this optimization.

I would like to see some numbers on the effect of the proposed changes assuming they had been activated at the beginning of our history (1. with the assumption that proxies are never updated, and 2. with the assumption that proxies are regularly updated).

I will make sure that someone follows up on this.

To avoid increasing of maintenance period, it would be better just assume that accounts with the last outgoing transaction(or other initiated by user operation) more than 1 year ago have zero vote power.

I think this suggestion side-steps the original intent of this proposal. In my understanding, the idea is that users must actively participate in our governance model, by regularly updating their votes. Activity unrelated to voting should not prevent decay.

pmconrad · 2019-04-05T07:51:43Z

bsip-0022.md

@@ -87,15 +87,15 @@ A voter changes their vote for witnesses on December 31, 2019 20:00 UTC.  This v

 ![Qualitative decay of voting power](bsip-0022/general-vote-decay.png)

-The voting power of an [account's voting stake](#account-voting-stake) shall be set to full voting power whenever an account's vote is re-cast for _any_ [referendum category](#referendum-categories).  The voting power shall remain at 100% for each of the referendum categories for the entire ["full-power period"](#vote-decay-parameters).
+The voting power of an [account's voting stake](#account-voting-stake) shall be set to full voting power whenever an account's vote is re-cast for _any_ [referendum category](#referendum-categories) or is re-delegated to a voting proxy.  The voting power shall remain at 100% for each of the referendum categories for the entire ["full-power period"](#vote-decay-parameters).  _Retracting the delegation from a voting proxy without also casting a vote does not reset the voting power to 100%_.


Retracting the delegation from a voting proxy without also casting a vote does not reset the voting power

Right now it is technically not possible to change/unset the voting proxy without also specifying a (possibly empty) list of votes. This could change in the future, so maybe leave this in.

Note that with the proposed explicit voting operation, not changing anything does reset the voting power. This is a contradiction.

bsip-0022.md

clockworkgr · 2019-04-05T08:02:31Z

I mentioned the following in TG the other day:

Alex M - clockwork, [03.04.19 13:08]
wouldn't per votable object proxying make more sense?
If I want to proxy my voting stake to someone
it kinda makes sense that some proxies will be more appropriate than others
e.g. I'd probably trust Abit to pick witnesses
but Bitcrab for governance
and someone else for Budgeting (workers)

It could be a different BSIP, but possibly also part of this as part of a general voting "overhaul" hence why I thought I'd mention it.

@MichelSantos thoughts?

MichelSantos · 2019-06-02T16:48:07Z

The voting stake of the BitShares blockchain was analyzed at the start of every month since November 2015.

Voting Stake

This plot shows the voting stake split into two categories. The first category called "Direct" (shown in blue) is the voting stake that is directly voting for any referendum category. The second category called "Delegated" (shown in gold) is the voting stake that is delegated to any proxy.

Commentary

This plot demonstrates an interesting decrease in the delegated voting over most of 2018, and a sharp increase in the delegated voting stake after 2019-03-01. This latter increase is mostly drawn from stake that had not been voting at all.

Voting Participation Rate

This plot visualizes how much of the voting stake is participating in governance of the blockchain. The voting stake is expressed relative to the circulating supply at the start of every month. The "Direct" line (shown in blue) is the voting stake that is directly voting for any referendum category. The "Delegated" line (shown in gold) is the voting stake that is delegated to any proxy. The "Total" line (shown in black) is the summation of the direct and delegated voting stakes.

Commentary

This plot demonstrates an interesting decrease in the delegated voting over most of 2018, and a sharp increase in the delegated voting stake after 2019-03-01. The 2019-06-01 participation rate of 46% is the highest rate in the history of the blockchain.

Relative Weight of Direct versus Delegated

This plot visualizes the direct and delegated voting stakes relative to each other. The "Direct" fraction (shown in blue) is the voting stake that is directly voting for any referendum category. The "Delegated" fraction (shown in gold) is the voting stake that is delegated to any proxy.

Commentary

This plot demonstrates the predominant tendency of approximately 80% of voting account holders to delegate their voting stake to another account.

Decayed Voting Stake

This plot visualizes the same voting stakes decayed by different durations and conditions. The "Direct" line (shown in solid blue) is the voting stake that is directly voting for any referendum category. The "Direct 90" line (shown in dotted blue) is the voting stake that is directly voting for any referendum category within the prior 90 days. The "Direct 360" line (shown in dash-dot blue) is the voting stake that is directly voting for any referendum category within the prior 360 days. The "Delegated" line (shown in solid gold) is the voting stake that is delegated to any proxy. The "Delegated 90" line (shown in dotted gold) is the voting stake that is delegated to any proxy and where the proxy has voted within the prior 90 days. The "Delegated 90 by Active Delegation" line (shown in solid green) is the voting stake that is "actively" delegated to any proxy and where the proxy has voted within the prior 90 days. ("Active" delegation is a delegation by an account after account creation.) The "Delegated 90 by Active Delegation 360" line (shown in solid green) is the voting stake that is "actively" delegated to any proxy within the prior 360 days and where the proxy has voted within the prior 90 days.

Commentary

This plot demonstrates how decaying votes reduces the amount of voting stake over time.

The Direct 90 and Directo 360 voting stakes are less than the full-power direct but they do not exhibit any major or sustained changes with the possible exception around 2019-09 when Direct 360 suddenly approaches the Direct voting stake.

The Delegated 90 voting stake is mostly identical to the Delegated voting stake until 2018 when it begins to slightly diminish.

The Delegated 90 by Active Delegation 360 voting stake exhibits the most dramatic changes in voting stake. One year after the start of the blockchain, this voting stake begins to deviate significantly from Delegated 90. It exhibits a significant decrease after 2018-02-01 and then a sharp increase after 2019-04-01.

Relative Weight of Decayed Direct versus Decayed Delegated

This plot visualizes an arbitrary selection of decayed voting stakes relative to each other. The "Direct 360" fraction (shown in blue) is the voting stake that is directly voting for any referendum category within the prior 360 days. The "Delegated 90 by Active Delegation 360" fraction (shown in gold) is the voting stake that is "actively" delegated to any proxy within the prior 360 days and where the proxy has voted within the prior 90 days.

Commentary

This comparison of an arbitrarily decayed direct and delegated stake is intended to be compared against the un-decayed relative weight to give some idea about how decaying voting stake can give certain stake more or less voting weight relative to the other. This comparison is for voting data in BitShares where there is no vote decay and it might not reflect how account holders will behave under a regime of vote decay. But it does demonstrate the potential effects of activating vote decay in BitShares.

pmconrad · 2019-06-03T11:14:18Z

Excellent report, thanks!

Some observations:

People who vote on their own seem to vote more or less regularly (compare blue lines)
Most proxies seem to be voting regularly as well (compare yellow lines)
People rarely switch their proxy if they have set one (compare yellow / dotted green)

It follows that vote decay would not have a very large (in the sense of damaging or dangerous) effect on voting, whereas proxy decay would. IMO it would be important to notify users of their vote decay in the UI to mitigate the possible effects.

oxarbitrage · 2019-06-08T12:44:38Z

Found some issues in the Rationale section of this BSIP that i think can be updated in the context of this pull request:

There are 4 items in "Campaigning efforts since the upgrade from BTSX (0.9x) to BTS 2.0 have drastically stagnated. ".

There were plans for a 'DPOSHub' to stimulate campaigning efforts, this has yet to materialize.
DPOSHub link is not working anymore.
Elected witnesses rarely make an active effort to attend BeyondBitcoin hangouts nor hold their own scheduled hangouts, they are largely a silent group of individuals.
Not valid anymore, beyond bitcoin hangouts do not exist since a while and witnesses are not a silent group anymore.
The 'Stakeholder proposal' subforum on Bitsharestalk is not as active as it should be; many elected witnesses haven't provided a discussion URL and many such threads on bitsharestalk haven't received a new post/update in months/years.
Majority of active witnesses do have an url.
The list of active witnesses/committee members rarely changes.
Not so true in this days IMO.

MichelSantos · 2019-06-19T00:20:08Z

I mentioned the following in TG the other day:

Alex M - clockwork, [03.04.19 13:08]
wouldn't per votable object proxying make more sense?
If I want to proxy my voting stake to someone
it kinda makes sense that some proxies will be more appropriate than others
e.g. I'd probably trust Abit to pick witnesses
but Bitcrab for governance
and someone else for Budgeting (workers)

@clockworkgr Please see #177

pmconrad

IMO (an excerpt of) your excellent report at #153 (comment) should be included in the discussion section.

bsip-0022.md

pmconrad · 2019-08-07T15:14:33Z

bsip-0022.md

@@ -87,15 +87,15 @@ A voter changes their vote for witnesses on December 31, 2019 20:00 UTC.  This v

 ![Qualitative decay of voting power](bsip-0022/general-vote-decay.png)

-The voting power of an [account's voting stake](#account-voting-stake) shall be set to full voting power whenever an account's vote is re-cast for _any_ [referendum category](#referendum-categories).  The voting power shall remain at 100% for each of the referendum categories for the entire ["full-power period"](#vote-decay-parameters).
+The voting power of an [account's voting stake](#account-voting-stake) shall be set to full voting power whenever an account's vote is re-cast for _any_ [referendum category](#referendum-categories) or is re-delegated to a voting proxy.  The voting power shall remain at 100% for each of the referendum categories for the entire ["full-power period"](#vote-decay-parameters).  _Retracting the delegation from a voting proxy without also casting a vote does not reset the voting power to 100%_.


Note that with the proposed explicit voting operation, not changing anything does reset the voting power. This is a contradiction.

bsip-0022.md

…power

MichelSantos added 4 commits March 6, 2019 09:45

Comparison to vote decay on some other blockchains

3245988

Removal of old specifications

7f7674e

Proposed specifications: full voting power period followed by stepped…

97def82

… vote decay for some referendum categories

Graphics for proposed specifications

fb4b71d

pmconrad reviewed Mar 10, 2019

View reviewed changes

bsip-0022.md Outdated Show resolved Hide resolved

pmconrad reviewed Mar 10, 2019

View reviewed changes

bsip-0022.md Outdated Show resolved Hide resolved

pmconrad reviewed Mar 10, 2019

View reviewed changes

bsip-0022.md Show resolved Hide resolved

pmconrad reviewed Mar 10, 2019

View reviewed changes

MichelSantos added 3 commits April 4, 2019 09:57

Clarification of voting power for worker proposals

fea6011

Schedule of voting power tallying

3828c6c

Distinction between referendum categories and proxy delegation

7ab1497

pmconrad reviewed Apr 5, 2019

View reviewed changes

bsip-0022.md Outdated Show resolved Hide resolved

pmconrad reviewed Apr 5, 2019

View reviewed changes

bsip-0022.md Outdated Show resolved Hide resolved

MichelSantos added 2 commits April 6, 2019 13:17

Fix typos

206ba34

Clarification of voting power for worker proposals through a proxy

af07036

abitmore closed this May 21, 2019

abitmore reopened this May 21, 2019

add software specs

a2d1e59

MichelSantos mentioned this pull request Jun 19, 2019

Vote Proxies for Different Referendum Categories #177

Closed

MichelSantos mentioned this pull request Jul 27, 2019

BSIP47 - Vote Proxies for Different Referendum Categories and explicit voting operation #114

Merged

Updates to Rationale, Discussion, design, and software specifications

4713b9d

MichelSantos marked this pull request as ready for review August 6, 2019 23:18

pmconrad suggested changes Aug 7, 2019

View reviewed changes

abitmore changed the title ~~Proposed details for BSIP-22 specifications~~ Proposed details for BSIP-22 specifications (vote decay) Aug 7, 2019

MichelSantos added 4 commits August 12, 2019 19:36

BSIP22: Historical voting

04ab115

BSIP22: Refinement of voting power in software specs

79f6642

BSIP22: Addressing community feedback

7b05107

BSIP22: Removal of implementation details from calculation of voting …

1eb62ac

…power

pmconrad approved these changes Aug 17, 2019

View reviewed changes

ryanRfox merged commit 5721233 into bitshares:bsip22 Aug 22, 2019

MichelSantos deleted the bsip22-patch1 branch August 22, 2019 23:41

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Proposed details for BSIP-22 specifications (vote decay) #153

Proposed details for BSIP-22 specifications (vote decay) #153

MichelSantos commented Mar 6, 2019 •

edited

Loading

MichelSantos commented Mar 6, 2019

grctest commented Mar 9, 2019

pmconrad Mar 10, 2019

dexy-dex Mar 10, 2019

MichelSantos Mar 15, 2019 •

edited

Loading

MichelSantos Mar 15, 2019

pmconrad Mar 16, 2019

pmconrad Apr 5, 2019

pmconrad Aug 7, 2019

clockworkgr commented Apr 5, 2019

MichelSantos commented Jun 2, 2019

pmconrad commented Jun 3, 2019

oxarbitrage commented Jun 8, 2019

MichelSantos commented Jun 19, 2019

pmconrad left a comment

pmconrad Aug 7, 2019

Proposed details for BSIP-22 specifications (vote decay) #153

Proposed details for BSIP-22 specifications (vote decay) #153

Conversation

MichelSantos commented Mar 6, 2019 • edited Loading

MichelSantos commented Mar 6, 2019

grctest commented Mar 9, 2019

pmconrad Mar 10, 2019

Choose a reason for hiding this comment

dexy-dex Mar 10, 2019

Choose a reason for hiding this comment

MichelSantos Mar 15, 2019 • edited Loading

Choose a reason for hiding this comment

MichelSantos Mar 15, 2019

Choose a reason for hiding this comment

pmconrad Mar 16, 2019

Choose a reason for hiding this comment

pmconrad Apr 5, 2019

Choose a reason for hiding this comment

pmconrad Aug 7, 2019

Choose a reason for hiding this comment

clockworkgr commented Apr 5, 2019

MichelSantos commented Jun 2, 2019

Voting Stake

Commentary

Voting Participation Rate

Commentary

Relative Weight of Direct versus Delegated

Commentary

Decayed Voting Stake

Commentary

Relative Weight of Decayed Direct versus Decayed Delegated

Commentary

pmconrad commented Jun 3, 2019

oxarbitrage commented Jun 8, 2019

MichelSantos commented Jun 19, 2019

pmconrad left a comment

Choose a reason for hiding this comment

pmconrad Aug 7, 2019

Choose a reason for hiding this comment

MichelSantos commented Mar 6, 2019 •

edited

Loading

MichelSantos Mar 15, 2019 •

edited

Loading