BitShares Forum
Other => Graveyard => KeyID => Topic started by: toast 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.
-
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
-
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?
-
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 (https://bitsharestalk.org/index.php?topic=9603.msg125130#msg125130) these systems (https://bitsharestalk.org/index.php?topic=9452.msg123045#msg123045). 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.
-
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 (https://bitsharestalk.org/index.php?topic=9603.msg125130#msg125130) these systems (https://bitsharestalk.org/index.php?topic=9452.msg123045#msg123045). 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.
-
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?
-
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.