Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: Proposal to enhance delegate pay/subsidy mechanic  (Read 380 times)

0 Members and 1 Guest are viewing this topic.

Offline toast

Proposal to enhance delegate pay/subsidy mechanic
« on: October 12, 2014, 09:04:47 PM »

Right now:

1) Each block has a maximum possible subsidy which is a fixed % of the difference between current_shares and max_shares
2) Your pay_rate determines what % of normal transaction fees *and* what % of the subsidy you want.

This leads to us burning through the delegate subsidy very fast as nobody is taking a high pay rate.

I propose:

1) pay_rate only determines how much of "normal" transaction fees you take (the rest are burned).
2) subsidy_rate determines what % of the max possible subsidy you take.
3) subsidy_burn_rate determines what % of max possible subsidy you burn.
   so subsidy_rate + subsidy_burn_rate <= 100   


Thoughts? The idea is to allow us to "save up" the delegate subsidy while still giving the stakeholders the option to burn through the subsidy if they want to.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12176
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BTS: xeroc
  • GitHub: xeroc
Re: Proposal to enhance delegate pay/subsidy mechanic
« Reply #1 on: October 12, 2014, 09:07:39 PM »
Thoughts? The idea is to allow us to "save up" the delegate subsidy while still giving the stakeholders the option to burn through the subsidy if they want to.
+5% ... makes sense to me
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline cube

  • Hero Member
  • *****
  • Posts: 1404
  • Bit by bit, we will get there!
    • View Profile
  • BTS: bitcube
  • Witness: bitcube
Re: Proposal to enhance delegate pay/subsidy mechanic
« Reply #2 on: October 13, 2014, 01:42:07 AM »
Thoughts? The idea is to allow us to "save up" the delegate subsidy while still giving the stakeholders the option to burn through the subsidy if they want to.
+5% ... makes sense to me

Yes, I agree to "saving up" the delegate subsidy too.  But I wonder how would a stakeholder decide if and what level of subsidy burn rate.  Would it be something easy for them?
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: Proposal to enhance delegate pay/subsidy mechanic
« Reply #3 on: October 13, 2014, 02:36:02 AM »
Thoughts?

Honestly? All I see are inelegant hacks tweaking a flawed foundation.

First, I think it is a mistake to "burn" the subsidy. The way I look at it is that the DNS DAC currently has defined the total supply to be 10 billion with about 5 billion currently in a reserve fund held by the DAC. I suppose you can move (or "burn") the money by moving some of it from the reserve fund to the untouchable fund, thereby providing investors with a monotonically decreasing total maximum supply (assuming no future hard forks changing the rules), but I think that entire concept is stupid and misguided especially in this early stage when we would like to have as much of the hard-limit supply available to grow the DAC and reach its potential. In other words I think the subsidy_burn_rate variable should be zero and any parts of the transaction fees or subsidy that aren't used to pay the delegates (determined from pay_rate and subsidy_rate) should be recycled back into the reserve fund. Then, much later in the future, we can hard-fork if desired to reduce the maximum supply limit to less than 10 billion if there really isn't anything valuable to spend those shares on (which would essentially act as a huge dividend at that time, however, most of the value of that dividend would have been already factored in the price of DNS since shareholders would be expecting that max supply reducing hard-fork well in advance).

Second, everything I said in the previous paragraph isn't how I would ideally do it. I haven't been shy about discussing how I would ideally structure these systems. But the previous paragraph is IMHO a sane way of quickly restructuring the existing system if you are unwilling/unable to implement the proper foundation of delegate proposals ratified by shareholder vote.


Offline toast

Re: Proposal to enhance delegate pay/subsidy mechanic
« Reply #4 on: October 13, 2014, 03:14:44 AM »
Thoughts?

Honestly? All I see are inelegant hacks tweaking a flawed foundation.

First, I think it is a mistake to "burn" the subsidy. The way I look at it is that the DNS DAC currently has defined the total supply to be 10 billion with about 5 billion currently in a reserve fund held by the DAC. I suppose you can move (or "burn") the money by moving some of it from the reserve fund to the untouchable fund, thereby providing investors with a monotonically decreasing total maximum supply (assuming no future hard forks changing the rules), but I think that entire concept is stupid and misguided especially in this early stage when we would like to have as much of the hard-limit supply available to grow the DAC and reach its potential. In other words I think the subsidy_burn_rate variable should be zero and any parts of the transaction fees or subsidy that aren't used to pay the delegates (determined from pay_rate and subsidy_rate) should be recycled back into the reserve fund. Then, much later in the future, we can hard-fork if desired to reduce the maximum supply limit to less than 10 billion if there really isn't anything valuable to spend those shares on (which would essentially act as a huge dividend at that time, however, most of the value of that dividend would have been already factored in the price of DNS since shareholders would be expecting that max supply reducing hard-fork well in advance).

Second, everything I said in the previous paragraph isn't how I would ideally do it. I haven't been shy about discussing how I would ideally structure these systems. But the previous paragraph is IMHO a sane way of quickly restructuring the existing system if you are unwilling/unable to implement the proper foundation of delegate proposals ratified by shareholder vote.

It seems reasonable not to have a subsidy_burn variable and simply save everything and hard-fork the max supply down if that's ever deemed the right thing to do.

I agree shareholder ratification for "worker"-style expenditures/dilution is ideal.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline ripplexiaoshan

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 1982
    • View Profile
  • BTS: xiaoshan
Re: Proposal to enhance delegate pay/subsidy mechanic
« Reply #5 on: October 13, 2014, 03:24:05 AM »
 If I understand correctly, subsidy_rate + subsidy_burn_rate should be always equal to 100, right?  But it seems not, then in which case, it will be < 100? Let's say subsidy_rate is 50%, subsidy_burn_rate is 20%, then where does the rest 30% go?
BTS ID:xiaoshan                   www.yoyow.org      www.btsabc.org      www.openledger.info

Offline pc

  • Hero Member
  • *****
  • Posts: 1034
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BTS: cyrano
  • Witness: cyrano
  • Payrate: 100%
Re: Proposal to enhance delegate pay/subsidy mechanic
« Reply #6 on: October 13, 2014, 07:17:29 AM »
If I understand correctly, subsidy_rate + subsidy_burn_rate should be always equal to 100, right?  But it seems not, then in which case, it will be < 100? Let's say subsidy_rate is 50%, subsidy_burn_rate is 20%, then where does the rest 30% go?

The rest is saved for the future.
Please vote for my BitShares witness "cyrano" and for my STEEM witness "cyrano.witness"!
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

 

Google+