• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Proposal: Adaptive Proposal Fees

Vedran Yoweri said:
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.
Click to expand...

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:
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.
 
UdjinM6 said:
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.
Click to expand...

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.

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:
GrandMasterDash said:
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.

Btw, thank you for chiming in, it's much appreciated.
Click to expand...
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).
 
UdjinM6 said:
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).
Click to expand...

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.
 
UdjinM6 said:
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).
Click to expand...

You just need to implement some kind of timestamp and keep the vote history. That way you always know whether someone was legitimate at whatever time.

The proposer accepts the proposal fee at the time of the proposal submission, and the rest masternodes validate this by watching the "proposal fee" vote history.

demo said:
So when we keep the vote history, we preserve the consistency of the decisions of the community. And also, whithin the examined time frame, we can say whether someone's actions were against the will of the community or not.
Click to expand...
 
Last edited:
By the way, the unreasonable behavior of the MNOs continue. Have a look.

@nudfelsyoshy said:
nudfelsyoshy said:
"Can someone please tell me why they are voting no. Because I cannot hear a single reason why this would not be a wonderful solution.
Can someone please say: "I voted no, and I did it because...""
Click to expand...

And their response to this question? Silence and downvote.

https://dashvotetracker.com/history.php?ProposalID=271

It is the stupids and the spies again. We already know them.:(:cool:
 
Last edited:
demo said:
You just need to implement some kind of timestamp and keep the vote history. That way you always know whether someone was legitimate at whatever time.
...
Click to expand...
Yep, timestamping means that current proposal fee should be written in blockchain as a part of budget finalization process - an OP_RETURN output of superblock's coinbase would be the most straightforward solution. This can break p2pool however (it uses coinbase OP_RETURN for its internal operations), need to investigate this further but should be solvable. Like I said, my post doesn't mean voting can't be implemented, it just might be that manual adjustment is not the best way to solve the issue.
 
UdjinM6 said:
Yep, timestamping means that current proposal fee should be written in blockchain as a part of budget finalization process - an OP_RETURN output of superblock's coinbase would be the most straightforward solution. This can break p2pool however (it uses coinbase OP_RETURN for its internal operations), need to investigate this further but should be solvable. Like I said, my post doesn't mean voting can't be implemented, it just might be that manual adjustment is not the best way to solve the issue.
Click to expand...

Of course writing in the blockchain is the best solution, but the blockchain is not the only database you have.
As a quick and dirty fix, you have also the sentinel database, and you may want to keep there the vote history, until a better solution is coded.
 
Last edited:
demo said:
Of course writing in the blockchain is the best solution, but the blockchain is not the only database you have.
As a quick and dirty fix, you have also the sentinel database, and you may want to keep there the vote history, until a better solution is coded.
Click to expand...
No, sentinel is not enough - every full node must verify proposals/superblocks, not only MNs.
 
Vedran Yoweri said:
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.
Click to expand...
The Core team works for us... not the other way around. I'm pretty sure everyone here realizes governance questions are not something to be toyed with. That's why we've had very few in the history of the proposals. Projects and most functionality should be handled by Core, however, there always going to be questions that pop up which would require a code change that should be asked to the community, regardless of where they come from. I believe this to be one of them.
 
UdjinM6 said:
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.
Click to expand...

Hi @UdjinM6, nice of you to comment. Of course the subtleties of voting in a distributed network makes all this harder. I have to admit I did not consider this. But is it really necessary to wait a business cycle? Can't we try to update this on every block, and update this every blocktime (1m 30s)? After all synchronising values through blocks is the key magic of the blockchain. One thing I can assure you is that the median moves slowly, it is not the average. No one can just vote some crazy numbers and get the median to do what they want. And of course the system would have to keep an histoy of all the previous values in the blockchain. And if something passes the threashold at one time, it is valid even if the threashold changes later.

I asked some of my friends what according to them should have been the politicians revenue. And I extracted the median. You can see the results here: https://www.dropbox.com/s/9fzttnmdomxdzre/MPSalaries.png?dl=0 In particular see how the median reached stability very early. And nearly never changed. And when it did it was for small values. On the other side the average changed every new vote, and mostly it was trying to balance some crazy high votes.

Maybe each masternode would have a value associated with it. And every time they want they can change their value. Which gets sent to the network and processed parallel to the payments informations from the wallets.

Finally, I am a mathematician, a researcher that studies eDemocracy. You can find my work at http://pietrosperoni.it . My speciality is making sure that voting systems are mathematically fair. I have also collaborated with the Italian government and some local initiative. I am very interested to collaborate with the core team. Is there an official channel to propose oneself?
 
UdjinM6 said:
No, sentinel is not enough - every full node must verify proposals/superblocks, not only MNs.
Click to expand...

Well in that case a quick and dirty fix is to ignore the full nodes. After all, how many full nodes do you have in the Dash network? One? Two? Ten? The big majority of the network are the MNs, the full nodes are a tiny minority. This requires of course for the code to recognise whether someone is a full node or a masternode. I think you can easily recognise this by watching the sentinel version.

And after all, all this has to do about voting! So why let the full nodes to confirm something that is not relevant to them? Leting the full nodes verify something accosiated to the votes, is a bad idea in the very first place. This may lead to a bug. I subscribe a lot of full nodes, and I deliberately not verify the votes, thus I disturb the network that way. Think about it.
 
Last edited:
demo said:
Well in that case a quick and dirty fix is to ignore the full nodes. After all, how many full nodes do you have in the Dash network? One? Two? Ten? The big majority of the network are the MNs, the full nodes are a tiny minority. This requires of course for the code to recognise whether someone is a full node or a masternode. I think you can easily recognise this by watching the sentinel version.

And after all, all this has to do about voting! So why let the full nodes to confirm something that is not relevant to them? Leting the full nodes verify something accosiated to the votes, is a bad idea in the very first place. This may lead to a bug. I subscribe a lot of full nodes, and I deliberately not verify the votes, thus I disturb the network that way. Think about it.
Click to expand...

I think he means the proposals need to be submitted by anyone and sit on the blockchain.. that requires a full node.. anyone running the core wallet is also running a full node
 
You must log in or register to reply here.
Back
Top