Trusting core obviously doesn't meen i always agree or default to a yes vote. They usually provide solid arguments. Silence from them contains no arguments.
Proposal: Adaptive Proposal Fees
- Thread starter GrandMasterDash
- Start date
From my observation, core have very much been taking a back seat regarding other people's proposals. I sometimes think this is intentional; they want to see if we can self-organise. That's entirely inline with Evan's vision and hence why he sold most of his masternodes.
I don't think so, there's nothing to 'organize'.
I read it as decency, they let the MNO discuss and form opinions without throwing their weight around to much. I salute them for it.
If we pass this proposal and then core is unwilling to implement it because of *reasons*, then so be it. I am sure the MNs would understand if the experts say it is infeasible or too high a security risk. This proposal does not force anyone to do anything. But absent any present objections to the concept I think it is fair to use this proposal to inform them what the Masternodes would like to see happen.
I'm not against having a vote, but informing core can be done by just posting a strongly argument-ed proposal for discussion and inviting someone from core to join the discussion.
I am against the notion that the budget system should be a tool to change the code as if it's some kind of democracy. I'm invested in dash because i trust core to build a kick ass crypto. Why should i trust MNO with that? They have no experience in creating or coding a currency. They are savvy investors. They could convince me only by creating a better coin. I'll jump ship and inform them of my errors in judgement.
As we have seen, a strongly argumented proposal for discussion could have the support of only a vocal minority of "5 guys" making trouble and there would be no way to prove that it has the support of a plurality of stakeholders. Using the budget is the only way to demonstrate that. As it is, anyone from core team is welcome to join the discussion but so far they seem to be holding back.
This, to me is a clear indications of the answer. If one want's to ignore this and spend 5 dash to force a vote, be my guest.
Think, what is a DAO? And what potential do they hold?
A Distributed Autonomous ORGNAISATION. I say core's lack of involvement is a test for self-organisation, whereas you say it's "decency". But regardless of who is correct, you, me and everyone else here has this opportunity right now to try and take some steps forward in self-determination. You say you would jump ship to another coin if it proved "better", but why do that when you have the opportunity to participate and bring about the changes you would desire?
I understood you were trusting Evan and the core team.Now I am confused, are you saying that the 5 dash fee is legitimate because the majority of people would prefer 5 dash than any other value? Because if this is the reason, let me assure you that thanks to the theorem of Duncan Black, the median of the votes is the Condorcet Winner. Which means that is the winner of all pariwise comparison. In other words, the median will extract that one value that the majority will prefer against every other value. So if you think this value is 5 and you want it to be 5, then you should not be afraid. The median would be 5.
You, me, everyone here has the potential to take some responsibility and to try and make this our DAO.
And that's exactly what we have here.
We wouldn't want to be asking core to waste their time on every little 5 guys thread would we
IMO, the arguments for doing this have been laid out sufficiently from the OP. This solution puts to rest a contentious issue, allows the fee to scale long term (we do not know yet whether the fee will need to rise proportionally to the size of the network, or higher or lower than that), the core team would still have heavy influence over the fee if they felt they needed to by recommending a value and reasoning to the Masternodes. It would mean changing the fee if needed would no longer require a big deal hard fork or masternode upgrade. Outside of feedback from core why would this not be a good idea?
I liken this to a business that has a choice of losing ground to the competition or the stakeholders becoming partners in the business. Look at the model of John Lewis department store; every employee is a stakeholder and they work hard to maintain things. They don't just make profits, they maintain good work ethics.
No, you're dreaming. The only options you have is investing or not.
It would be pretty stupid for me to invest in a coin and then trying to change it. I don't know sh*t about creating and coding a crypto coin, you neither.
Then sell one of your dash nodes and buy pivx nodes while you wait for another "better" coin to be created by someone else (not you or us).
Because principle.
MNO don't code or build coin, core does. We should let them and not bother them with pressure from votes to do stuff they don't want to or don't agree with.
I don't agree that the core team should be an island. MNs are the ones who fund them, they should be made aware when the MNOs have an interest in doing something and should dialogue with them especially when there is something with a good amount of demonstrated support. Doing so helps maintain a positive relationship between MNOs and core, and improves job security for core
In my opinion it has to be both. The vote is the mechanism for filtering out spam (proposal fee) and vocal minority trolls (negative support from MNOs). If there is no proposal or if the proposal has negative support then what reason does anyone have to waste time discussing on the forum? It is a fair way to call attention to a particular topic and a way to reasonably show that it deserves the core team's time of day relative to other ideas that have not gone through the trouble.
Last edited:
If we allow votes to influence the coding we expose core to the other side of the blade. It's double edge sword.
What happens if core say's "No, we won't do this because.."? Crisis in dash DAO! Will MNO fire core? Who will replace core!!!.
That's pressure we ( and core ) can do without.
Already addressed this. If it turns out core is unable or unwilling to do it because of *reasons* then so be it. If the reasons are good (which they probably would be), then I doubt the MNs would try to punish them for it. Especially if those reasons were not previously expressed by the core team, it would mean that the MNs voted with incomplete information. This is *not* a mandate. It is a barometer.
Last edited:
Let me ask you @Vedran Yoweri if you invested in another coin and that coin subsequently implemented APF, would you sell your investment?
I hear you. Perhaps something can be done to even further clarify the function of the proposal. Will think about this
Chiming in to confirm that the topic is very interesting and is not ignored I'm following all ideas about fee adjustments closely (you can see my comments in previous proposals) and I like the idea of this one too (which I see as a step in "give MNs power to directly adjust some network params" direction) but I have few concerns. Changing proposal fees on the fly is a bit tricky - you can't do this in some random period of time as this could invalidate old proposals for example. It should be at least synchronized with budget cycles. You could then try to store a history of such adjustments somehow (locally and sync among nodes or in some new data structure on the blockchain) but that's another moving part and this can become way to complex and fragile very quickly if you try to follow that path further imo. Having deterministic way of calculating smth using data we already have buried in the blockchain is much more robust and requires no deep changes, that's why I personally prefer smth closer to diff adjustment as I mentioned earlier. This does NOT mean that voting for fees can't be implemented, I just think that there is probably an algoritmical solution to this issue which removes the burden of manual adjustments.
I'm following all ideas about fee adjustments closely (you can see my comments in previous proposals) and I like the idea of this one too (which I see as a step in "give MNs power to directly adjust some network params" direction) but I have few concerns. Changing proposal fees on the fly is a bit tricky - you can't do this in some random period of time as this could invalidate old proposals for example. It should be at least synchronized with budget cycles. You could then try to store a history of such adjustments somehow (locally and sync among nodes or in some new data structure on the blockchain) but that's another moving part and this can become way to complex and fragile very quickly if you try to follow that path further imo. Having deterministic way of calculating smth using data we already have buried in the blockchain is much more robust and requires no deep changes, that's why I personally prefer smth closer to diff adjustment as I mentioned earlier. This does NOT mean that voting for fees can't be implemented, I just think that there is probably an algoritmical solution to this issue which removes the burden of manual adjustments.I'm not entirely sure I understand the sycncronization to budget cycles. Can you expand? If I pay, say, a 5 dash proposal fee, how does it become invalid later if the price changes? The proposal fee was valid at the time of purchase.Chiming in to confirm that the topic is very interesting and is not ignored
Btw, thank you for chiming in, it's much appreciated.
@GrandMasterDash yeah especially with udjin's input above, I think maybe this proposal still appears too narrow with the appearance of a specific implementation recommendation. If you can manage to generalize it enough, to the point where it might also encompass possibility of something like what udjin suggested, then it might have a better chance. To me, the main point of this is the "adaptive proposal fee", not so much the way that this is achieved. Although if you think that the masternode median is a necessary condition then that would diverge a little.
Last edited:
Well, every proposal has fee-tx associated with it and each fee-tx is validated by each node at the time this node sees this proposal for the first time. So if there is a multi-months proposal which was created when proposal fee was lower and fee was bumped to a higher value later, this proposal will suddenly become invalid for new nodes if you can't 1) get "old" (low) fee value from somewhere and 2) verify that it was indeed the real proposal fee at some specific budget cycle (i.e when this proposal was submitted).
Couldn't you just sign the proposal and the fee as valid so that it's locked in? If the proposal fee goes up or down, it's of no relevance; the proposer accepted the price at the time of submission. But I'm probably not understanding the process well enough.
I will take a break from this for a while, give us a chance to think on it. Thanks for your input.