Author Topic: Momentum Approval: Solving problems in inflation and voting  (Read 3169 times)

0 Members and 1 Guest are viewing this topic.

Offline bytemaster

"kinds of delegates" is merely a matter of perspective and not any kind of technical change in the code.

We are planning an ability to specify a separate "signing key" that is different than the delegate "master key".  Pay would go to the "master key", but signing authority will be assigned to the "signing key".

Anyone trusted with the purse can be trusted to nominate someone to do signing for a fixed fee.   

From a "voting perspective" the code is identical... and of course we are limited to 101 delegates by transaction size and performance considerations.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
This means I dislike bytemaster's proposal as well. So far I have had very little luck trying to push that philosophy to the community. Everyone seems to want to shoehorn delegates to every possible role that can benefit the DAC, which I think is a big mistake.

Actually I do believe quite a few people dislike mixing the pure block signers with the rest of the paid positions on the blockchain (call them workers/business delegates/ whatever). I personally am not so much opposed to 'delegates for all paid positions' idea, as I like the flexibility the other decision provides as in:
- unlimited number of business delegates;
- specific rules for electing as well as removing them (example some people might think twice if the pay, if elected, is not guaranteed for some min time period; or might accept  only  higher pay rate, due to the threat of being removed at any point in time)

to name a few.

+5% It is the flexibility that is key. Once we have a group of non-colluding delegates who are paid just enough to reliably run the consensus engine, we gain the ability to implement any form of governance we want on top.
Though it's getting a little off-topic here .. I'd like to express that I like the idea of two different kinds of "delegates" on the blockchain (tech and business)

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Thank you for the insightful comments. I believe you are right about the 2nd term needing to be multiplied by I_d as well, not sure how I overlooked that. I think the graph's y-axis is correct though. The graph's max of 1 is basically representing a delegate asking for 100% dilution pay, but the max will always be I_d.

What does a 100% dilution pay mean? Does it mean the delegate gets the maximum 50 BTS per round? Does it mean they get the maximum I_d that they requested? And what are the units of I_t and I_d. The way I understood it is that the units of I_t and I_d are in BTS/block or something equivalent. Thus if you want a unitless metric for the y-axis spanning from 0 to 100%, it would technically be I_t/I_d. Meaning your formula is I_t/I_d = P  + N * (8*P^3) = P + (1 - P) * (8*P^3), since N = 1 - P by definition. If I plot that formula, I get something which appears to be identical to the blue curve in your plot.

Also it appears that the calculations of the percentage of their stake that nonpatrons pay in the numerical examples are not done correctly. You appear to be using 2*N*(8*P^3)*I_d when I believe you should instead be using (8*P^3)*I_d. You can see it is not right because if you take the fraction of patrons multiplied by the percent they pay (10%) and the fraction of nonpatrons multiplied by the percent they pay, you do not get total percent the delegate receives (which as far as I can see is calculated correctly and matches the blue curve of the first plot). So for example, when delegates have approval from 5% of stakeholders, the nonpatrons are only paying 0.01% of their stake (not 0.019%), and the total that the delegate receives is 0.05 * 0.10 + 0.95 * 0.0001 = 0.005095, or 0.5095%. The rest of the values for the percentage of their stake nonpatrons pay and the percentage of all stake that the delegates receive for the given numerical examples is calculated here. The multiple of 2 mistake also appears to be in the second plot. I believe the second plot should look like this.


I'd be interested in any comments you have about the Voter Rebates system as well, once you've taken the time to analyze it more closely.

There seems to be an inconsistency here:
Increase supply, distribute to Nonpatrons and Delegate
PATRONS: No change in number of shares
NONPATRONS: Number of shares increased ( stake + (stake * * ) )
DELEGATE: Number of shares increased  ( stake + (supply * ) )
TOTAL SUPPLY: Increased ( supply + (supply * ) )

You claim the total increase is (supply)*I_t but then say that same amount is paid just to the delegates. That does not include the additional amount created to pay the nonpatrons (also the formula of increasing nonpatrons stake by (stake)*2*N*(8*P^3)*I_d seems wrong to me).

One way of correcting this is to take the total supply increase to be (supply)*I_t but only give the delegate (supply)*P*I_d, not (supply)*I_t. This leaves N*(8*P^3)*I_d left over for voter rebates, which means a nonpatron that is able to claim the voter rebate gets an additional (stake)*(8*P^3)*I_d. But this may not be exactly what you want since I_t is only greater than (8*P^3)*I_d for P < 0.5. That means after the peak of P = 31.5%, the dilution disadvantage for voter rebate claiming nonpatrons becomes progressively less bad, and when the majority support a delegate, the minority that do not would not be diluted at all assuming they can claim the voter rebate.

So from my understanding of what you are trying to accomplish, perhaps what you meant instead was that the delegate receives (supply)*I_t and the total increase in the number of shares is actually more than (supply)*I_t in order to make room for voter rebates. Let us say that the total increase is (supply)*I_d. Then the amount left for voter rebates is (supply)*(I_d - I_t) = (supply)*I_d*(1 - I_t/I_d) = (supply)*I_d*(1-P)*(1-8*P^3). Which means that each nonpatron can claim up to (stake)*I_d*(1-8*P^3). This makes more sense. It also means that the dilution penalty for nonpatrons grows from zero (when no one is voting for the delegate) to the same as patrons (when more than 50% are voting for the delegate) in a manner that follows the curve of the second (fixed) plot I linked to above.

I really like using the nonpatron rebate as a way to motivate people to vote (or at least propagate their vote updates from the local client to the blockchain). I had suggested earlier to use the BitAsset yield type of method of distributing dividends to incentivize BTS holders to vote as a condition of collecting their dividends. Your proposal is a similar kind of idea but it has the benefit that the incentives still exist even when the DAC is operating in an inflationary mode rather than a deflationary mode. So good idea.

I still need to think about the specific conditions necessary to be allowed to claim the voter rebate. In particular I wonder how the selection of these criteria will influence game dynamics on delegate selection. Will there be a lot of low quality delegates that do not dilute just so that nonpatrons to the diluting delegates who don't like dilution of their stake can vote for those low quality delegates merely as a means to satisfy the requirements for claiming their rebates? There is a lot to think about here and I think it is important to design the conditions well to not create negative side-effects for the DAC.


As far as conflating roles are concerned, this proposal can apply to a separate 'business delegate' tier, it is not tied to the 'one kind of delegate to rule all' paradigm.

That is a good point. These are in theory orthogonal issues. Although the workers idea I had required delegate proposals to be either approved or disapproved by shareholders. It didn't allow approval voting for each of up to N candidates using stake. The approval voting of delegates already requires considerable extra data added to every transaction, I wouldn't want to add more blockchain bloat for a different class of workers. This is why I had designed a system where stakeholders could either say yea/nay on proposals; it only required 5 additional bytes to each transaction, but provided a lot of flexibility. So perhaps your proposal is best suited for the current delegate system.


I'm still ambivalent on whether it is a good idea to force people to come to a consensus on how much a worker / business delegate is worth and pay them that amount (a binary decision), or to use a system where their pay rate gradually rises as more stakeholders are in agreement that the worker is worth it. The good thing about the former is that the worker gets some certainty regarding their position and budget, but on the other hand it might be more difficult for them to get anything if the threshold for consensus is too high. Also, there is a possibility that if the threshold is not high enough then shareholders might change their mind back and forth and create an unstable environment for the worker. It's a tricky problem.

But I do like your proposal, especially because of the voter rebate incentives. Still, I need to spend more time thinking through the incentives and other details.

Edit: I also want to mention that what you are attempting to do here is find a balance between the free rider problem (Singular Patrons) and the tyranny of the majority (Majority Approval). The particular cubic function you have chosen is one of infinite possible compromises on the spectrum between these two extremes. One thing I am concerned about is that it gives too much benefit to the people who don't want to dilute but still reap the benefits of the growth in the value of BTS. Perhaps a linear function that grows to 100% as approval goes to 50% would be a more appropriate compromise. The other argument that can be made is that we might as well just go with the extreme of a binary decision (maybe Majority Approval or maybe something else like the rule I described in the last sentence of this post) since there isn't really a tyranny of the majority; stakeholders are always free to sell their BTS and move their wealth into a competing fork.
« Last Edit: October 28, 2014, 05:53:10 am by arhag »

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
arhag,

Thank you for the insightful comments. I believe you are right about the 2nd term needing to be multiplied by I_d as well, not sure how I overlooked that. I think the graph's y-axis is correct though. The graph's max of 1 is basically representing a delegate asking for 100% dilution pay, but the max will always be I_d.

As far as conflating roles are concerned, this proposal can apply to a separate 'business delegate' tier, it is not tied to the 'one kind of delegate to rule all' paradigm.

I'd be interested in any comments you have about the Voter Rebates system as well, once you've taken the time to analyze it more closely.
« Last Edit: October 28, 2014, 03:00:52 am by fluxer555 »

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
This means I dislike bytemaster's proposal as well. So far I have had very little luck trying to push that philosophy to the community. Everyone seems to want to shoehorn delegates to every possible role that can benefit the DAC, which I think is a big mistake.

Actually I do believe quite a few people dislike mixing the pure block signers with the rest of the paid positions on the blockchain (call them workers/business delegates/ whatever). I personally am not so much opposed to 'delegates for all paid positions' idea, as I like the flexibility the other decision provides as in:
- unlimited number of business delegates;
- specific rules for electing as well as removing them (example some people might think twice if the pay, if elected, is not guaranteed for some min time period; or might accept  only  higher pay rate, due to the threat of being removed at any point in time)

to name a few.

+5% It is the flexibility that is key. Once we have a group of non-colluding delegates who are paid just enough to reliably run the consensus engine, we gain the ability to implement any form of governance we want on top.

Offline tonyk

  • Hero Member
  • *****
  • Posts: 3308
    • View Profile
This means I dislike bytemaster's proposal as well. So far I have had very little luck trying to push that philosophy to the community. Everyone seems to want to shoehorn delegates to every possible role that can benefit the DAC, which I think is a big mistake.

Actually I do believe quite a few people dislike mixing the pure block signers with the rest of the paid positions on the blockchain (call them workers/business delegates/ whatever). I personally am not so much opposed to 'delegates for all paid positions' idea, as I like the flexibility the other decision provides as in:
- unlimited number of business delegates;
- specific rules for electing as well as removing them (example some people might think twice if the pay, if elected, is not guaranteed for some min time period; or might accept  only  higher pay rate, due to the threat of being removed at any point in time)

to name a few.
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
Rune, care to address any of the current problems with Majority Approval, such as no stimulation for shareholder involvement, not holding apathetic shareholders accountable, failed-delegate risk mitigation, or anything else I mentioned in my proposal?

What will happen when a delegate flickers between <50% and >50%, when the community is divided? Might we hire/fire the same person many times per week? If I was that delegate, what should I do?

If no-one else sees the problems I do now, I hope it's because they don't exist. If they do exist, I'll probably be bumping this thread in a couple months...

There will both be internal and external forces in play that determines the sitting delegates and their policies. Delegates sponsor each other through their slates. They will be able to control who are in the "safe jobs" (that professional developers and marketers need), with the stakeholder community essentially functioning as an emergency veto and setting the long term trends and attitudes of the DAC.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Nice work. I like to see more discussion on the best way to do dilution for funding projects. I have a few comments.

First, I think the "Singular Patron" model is a non-starter because of the free rider problem. You can achieve similar results by just donating money to a delegate or anyone else, which is already possible now. And I realize that you mostly just included it in order to compare it and "Majority Approval" to your proposal.

Second, the current proposed system is not actually what you describe as "Majority Approval". There is a hard cap on the dilution rate (actually more precisely there is a hard cap on the maximum per block BTS payment). To change that hard cap requires a hard fork. Getting shareholder approval of a hard fork will eventually require at least 75% consensus according to bytemaster's proposal, not at least 50%. So it is actually more difficult to achieve change than what you are claiming here. Now whether 75% is good or it should be less, it doesn't really matter on deciding who gets the diluted pay and how much they should get, since the 75% consensus is only to change the hard cap. The way the amounts are decided on a per delegate basis is through another mechanism. Originally, I think the plan was for the delegate to set their own pay (within limits) and burn a fraction of it as a registration fee. I don't know if that is still the proposed plan. I believe the plan now is to just let the pay rate percentage determine what fraction of the up to 50 BTS per block reward the delegate will get. Some clarification from bytemaster would be helpful here. The point is that the delegates can control what fraction of the diluting pay they desire and they can receive it if they get enough approval rating to be in the top 101 ranks. Considering the current approval ratings in BitShares X, this is much easier to achieve than greater than 50% consensus.

Third, I still need to look into your "Momentum Approval" proposal more carefully. I can see what you are attempting to do with it, which may or may not be an improvement (I would have to more carefully analyze it), but my first impression is that I don't like the way it is done. But that is mostly because I really dislike mixing delegates with other workers that should be paid to improve the BitShares ecosystem. This means I dislike bytemaster's proposal as well. So far I have had very little luck trying to push that philosophy to the community. Everyone seems to want to shoehorn delegates to every possible role that can benefit the DAC, which I think is a big mistake. Specifically regarding your proposal, your formula seems like it has a mistake in it. Isn't the second term also supposed to be multiplied by I_d? Also, I believe the vertical axis is supposed to be labeled I_t/I_d, not I_t. I'll add more thoughts after I think about it more.



Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
Rune, care to address any of the current problems with Majority Approval, such as no stimulation for shareholder involvement, not holding apathetic shareholders accountable, failed-delegate risk mitigation, or anything else I mentioned in my proposal?

What will happen when a delegate flickers between <50% and >50%, when the community is divided? Might we hire/fire the same person many times per week? If I was that delegate, what should I do?

If no-one else sees the problems I do now, I hope it's because they don't exist. If they do exist, I'll probably be bumping this thread in a couple months...
« Last Edit: October 28, 2014, 12:42:01 am by fluxer555 »

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
I think it should just be like delegates are now. Delegates who are inefficient, dishonest or non-transparent should be publicly campaigned against to ensure they're kicked out swiftly.

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
After posting this thread, I have come up with some ideas that should help address problems associated with inflation and voter turnout. I will review three inflation models: Majority Approval (the current proposed inflation implementation), Singular Patrons (opposite end of the spectrum), and Momentum Approval (my proposed implementation). I will also propose something called Voter Rebates, which fits into the Momentum Approval model.

(NOTE: Stan has said to stop using the word 'inflation' when referring to how we pay hired delegates. I'm using it anyway, but please know that I am not thinking in terms of 'currency inflation'. You can replace it with 'capital infusion', 'dilution', 'pay rate', or whatever you want. Inflation is just the most clear word to use in the context of this proposal.)


I. MAJORITY APPROVAL
">50% of total stake needs to be for supporting an Inflation Delegate."

It is going to be extremely difficult to achieve >50% voter turnout, even with I3 voting with their large stakes. What this means is that we're going to have to lower the threshold to <50% for inflation to kick in, and this would give major stakeholders a large disproportional voting advantage. On the other hand, if we refuse to lower the threshold within this inflation scheme, then we will have slow or halted capital infusion.

The binary nature of this implementation makes it simple, but not very intelligent.


II. SINGULAR PATRONS
"All the stake (and only the stake) that votes for an Inflation Delegate pay that delegate."

There are two equivalent ways to do this:

1. Transfer stake from those who voted for the inflation
PATRONS: Stake lowered (transfer a percentage of their stake to delegate)
NONPATRONS: No change
DELEGATE: Stake raised (receive a percentage of every Patrons' stake)
TOTAL SUPPLY: No change

2. Add stake to those who did not vote for it
PATRONS: No change
NONPATRONS: Stake raised (inflation amount spread out over all Nonpatrons)
DELEGATE: Stake raised (inflation amount added singularly to delegate)
TOTAL SUPPLY: Increased (Nonpatron inflation amount + delegate inflation amount)

Pros and Cons for Singular Patrons when compared to Majority Approval:

PROS:
- Each shareholder is in full control of their stake.
- Large stakeholders do not hold disproportional advantage.
- Risk of failure of delegate rides solely on those who voted for them.
- Higher diversification of funds casts a larger net when acquiring talent/capital
- Minimum approval does not inhibit anyone from being funded. If one stakeholder wants to fund a project/individual/group, they can.

CONS:
- Low voter turnout results in low capital infusion rate (which is still actually better than no capital infusion with Majority Approval in this situation).
- In the event of high voter turnout (>50%), this method doesn't have as much 'firepower' as Majority Approval.
- Diversification of funding may be too extreme; we may end up doing many things badly rather than a few things well.
- Free rider problem exists; there may be incentive to not vote, thus creating a 'tragedy of the commons'


IIIa. MOMENTUM APPROVAL
"As approval rate for an Inflation Delegate approaches 50%, the Inflation Delegate's inflation approaches their desired rate."

To gain the benefits of both the original Majority Approval scheme and the Singular Patrons scheme, we can blend them together.

This can be achieved through the following equation,



where

= Percentage of stake approving Inflation Delegate (Patrons)
= Percentage of stake not approving Inflation Delegate (Nonpatrons)
= Delegate's desired inflation
= Total Delegate Inflation

All approving stakes automatically give the delegate his total desired inflation, . All stake not approving give the delegate a partial amount of their desired inflation, , which starts at 0 and accelerates towards the full amount as approval approaches 50%. Their sum is the effective inflation pay rate for the delegate.

After approval rate is >50%, it is equivalent to Majority Approval.

Here is a graph comparing the three different methods:



Here is a graph showing the percentage of the delegate's max inflation that Nonpatrons pay as approval increases:



As you can see, even at 5% Approval (approximate amount of I3's stake), there are negligible effects on the rest of the stakeholders.

Some numerical examples:

1. Delegate has approval from .05 of stakeholders
Delegate is asking for 10% max inflation
Patrons give 10% of their stake
Nonpatrons give 0.019% of their stake
Delegate gets 0.5095% inflation

2. Delegate has approval from .12 of stakeholders
Delegate is asking for 10% max inflation
Patrons give 10% of their stake
Nonpatrons give 0.243302% of their stake
Delegate gets 1.32165% inflation

3. Delegate has approval from .25 of stakeholders
Delegate is asking for 10% max inflation
Patrons give 10% of their stake
Nonpatrons give 1.875% of their stake
Delegate gets 3.4375% inflation

4. Delegate has approval from .33 of stakeholders
Delegate is asking for 10% max inflation
Patrons give 10% of their stake
Nonpatrons give 3.85245% of their stake
Delegate gets 5.22622% inflation

5. Delegate has approval from .45 of stakeholders
Delegate is asking for 10% max inflation
Patrons give 10% of their stake
Nonpatrons give 8.019% of their stake
Delegate gets 8.5095% inflation


IIIb. VOTER REBATES

Consider this redistribution implementation for Momentum Approval:

Increase supply, distribute to Nonpatrons and Delegate
PATRONS: No change in number of shares
NONPATRONS: Number of shares increased ( stake + (stake * * ) )
DELEGATE: Number of shares increased  ( stake + (supply * ) )
TOTAL SUPPLY: Increased ( supply + (supply * ) )

(NOTE: Just to be clear, even though Nonpatrons get their number of shares increased, since the total supply is increasing, their percentage of total is still lower.)

Voting incentive #1
In order for Nonpatrons to receive their stake increase, they must vote 2 delegates for every 1 delegate they are getting an increase for (with a maximum of 101). Let's call this stake increase the Voter Rebate.

Voting incentive #2
If the stakeholder doesn't vote for 2x Delegates and/or redeem the Voter Rebate in 90 days, then the it expires and automatically goes to its corresponding Delegate.

What this means is that if you don't support a delegate to be payed, you have to come up with at least two alternatives within 3 months, or you will end up giving up your extra shares to the Delegate. Since you're voting for twice as many as you're receiving for, and voting for delegates may mean becoming a Patron for those delegates, this puts pressure on stakeholders to constantly invest money toward growth, as well as incentivize Delegates to put up bids for election. Additionally, the two delegates you vote for create more incentive for others to redeem their Voter Rebate, thus creating a viral effect.

You can always redeem your Voter Rebate from as many as 1/2 of the number of Delegates you are currently voting for, prioritizing the largest rebates first, within a rolling 90-day period.

What if a lazy BTS holder doesn't want to vote? They will be giving up part of their voting power, being less of a drag on capital infusion. Since this demographic's percentage stake would drop the fastest out of everyone, they would also be less and less of a burden over time. Meanwhile, price appreciation is still likely, making this a viable option for many speculative investors who are not interested in becoming involved in company politics.

--

In summary:

- Majority Approval model is simple but unintelligent, which makes it inefficient at balancing capital infusion, stakeholder consensus, and stakeholder apathy.
- Singular Patron model solves certain problems, but overall, since it has no way to leverage the whole company's stake, it is too weak to give the company the competitive advantage that it needs to survive.
- Momentum approval model brings Majority Approval and Singular Patron model together to get the best of both worlds.
- Voter Rebates involve all stakes in the voting process (whether they vote or not), incentivizes stakeholders to participate, and holds shareholders accountable for the success of the company.


Tell me what you think, suggestions / improvements / modifications, or pointing out flaws in my logic or math are strongly encouraged!