Self-sustainable Decentralized Governance by Blockchain
- Thread starter eduffield
- Start date
Hell, even fiat currency requires continual development. Have you seen the new hundred dollar bills? Lots of security enhancements needed due to counterfeiting.
I don't agree that the unused 15% should automatically go to miners. We should give miners enough to provide the level of security the network needs... not more. I would rather see the block reward size drop by 15% so that holders of the coin aren't "taxed through dilution" more than they need to be. Why incentivize more mining at great expense beyond the level needed while diluting all holders of DASH? A lower block reward would in turn provide less supply of the coin to the markets, which would support the price (or at least dilute it less).
By pushing future funds out of miners, the network hash rate will be reduced causing a less secure coin. As the % allocated to masternodes drop, the less masternodes will be created, reducing the transaction speed and reducing the supply held in masternodes pushing down DASH value. It isn't like there is no consequence for allocating these block rewards to development. I am in favor of development, but not an indefinite fixed %.
I think we all see the benefit of voting via masternodes. The problem is that any funds that are in escrow without a reason will not be spent efficiently. And for long term stability of a coin do we really want 15% to go to unknown future causes forever? In 5 years when that 15% is an enormous amount and there are no new features/bug fixes are needed, what then? Maybe private investment will be coming in and no DASH specific development will be needed. I certainly don't want to pay for an accountants salary to manage writing checks and expenses for projects. I also don't believe that if an amount is set at 15% now it will ever be reduced.
I propose the best approach is the allocate a certain amount for a specific time. That way each project will need to stand on it's own. Projects will get funded from block rewards directly(some split from miners or MNs). Maybe each project would specify if it is funded from miner blocks or masternode blocks. Personally, I would give up a large percentage of block rewards from my masternodes for all these features, as it will grow DASH and increase my masternode value. The funding limit would be capped at 15%, but that wouldn't mean each project would have to use the full amount. Just to list a couple to give some ideas:
- Long term planning and core development 1% for 2 years, and autorenews with voting, default vote of yes.
- Mobile wallets 10% for 1 month, default vote of no
- Blinding 5% for 1 month, default vote of no
- 2FAE 5% for 1 month, default vote of no
- Video 1% of 6 months, default vote of no
- Secure messaging 1% for 2 months, default vote of no
Why would you not touch supply? Would love to debate based on your reasoning rather than your position.
The more I think about it, supply should attempt to match the needs of the network. You need enough to provide a sufficient hash rate (we've already incorporated variable increased supply when there isn't enough network hash rate, so we are ALREADY doing this with miners). You need enough to support a healthy MN network (this is illogically linked to hashrate rather than the number of masternodes we are targeting). And you need enough for development.
We already have variable rewards based on our targeted hash rate. Why not introduce into the protocol a total supply and split for all three numbers independently targeting our desired network hash rate, MN count, and dev / marketing support level? Anything beyond what is needed is waste.
The network could then vote on things like increasing or decreasing the targeted hash rate, the targeted number of MNs (if say transaction volumes increase), or higher or lower dev / marketing budgets.
I agree with those who say that we can't have a system like this running indefinitely. At the present, there are literally thousands of potential projects we could need funding for, and would keep the need for funds for years.
However, there will come a time that either through appreciation of Dash value, or lack of quality project options, that we will need to reevaluate the program.
Solution: Don't make the program open-ended. Treat it like a contract, in one or two year blocks. Around the time of expiry, re-evaluate percentage/details, vote and continue. It is understood that 15% shall be the max required. Decide based on pending projects how much will be needed for the coming year, and set that percentage based on the exchange rate at the time.
Keep re-evaluating that way.
Our needs will change, this fund must be flexible.
However, there will come a time that either through appreciation of Dash value, or lack of quality project options, that we will need to reevaluate the program.
Solution: Don't make the program open-ended. Treat it like a contract, in one or two year blocks. Around the time of expiry, re-evaluate percentage/details, vote and continue. It is understood that 15% shall be the max required. Decide based on pending projects how much will be needed for the coming year, and set that percentage based on the exchange rate at the time.
Keep re-evaluating that way.
Our needs will change, this fund must be flexible.
The most fundamental property of a coin is how many will be put into circulation. If you change this after a coin is released it causes uncertainty about future coins in circulation and loss of value. What you are proposing is interesting, but would need to be started with a new coin.
On a lighter note, I propose a Tao fund for getting people to #DashIntoDigitalCash each day... 
If the time ever comes where money is no longer needed for development, the Dash code can be updated to remove the 15% and the community can choose to accept/reject that update.
While I submit that the time we will not need any money for development will more than likely never come, this is the idea of re-evaluating after contract expiry. Needs change, and available money should be flexible to meet those needs, and no more.
I disagree for several reasons. What has gotten us where we are is willingness to take risks and incorporate good ideas. When this coin started, there were no masternodes. We have changed the split of that reward to miner (which decreases the incentive to mine and results in a higher reward needed to incentivize miners, thus changing the supply)... that took place after launch and increases overall supply.
Secondly, I don't think the most fundamental property of a coin is how many will be created. If that were true, this coin would be a failure because there literally is no cap on our supply... it is totally dictated by the hash rate, so if the value of the coin drops, and hash rate drops, we will start spilling out coin to attract miners again. This community is very much driven by innovation, not coin supply. Sure if you flood with new coin nobody anticipated, it would dilute the value and create uncertainty, but...
...we are talking about REMOVING supply, not adding to it. Any reduction is supply has a POSITIVE impact on value, not negative. A reduction in supply vs. what was promised is hardly something that would upset anyone.
That is a great suggestion Tao, I like it It can be revised every 24 months. Dash should be able to reach milestones in that period of time. Evaluate the success of the program, vote for adjustments, and continue. Beautiful.
I agree with Solarminer and is not the point here, since emission and inflation remain the same. We are just discussing how to distribute rewards. Another great advantage of reinvesting in the ecosystem is it can greatly help with adoption and to build the economy. This is going to be really exciting and give Dash a fair chance of success and avoiding the issues we already see in older coins like BTC and LTC.
Also, block rewards adjust from hashrate so the coin would always find its balance.
If you can remove from the supply, you can also add to the supply. It still causes the same problem. The same issue comes up with the question of rolling back a block to stop coins from getting stolen. You do it once and save the coins, but now the precedent is there to do it again and the coin is worthless.
No one is removing or adding to the supply either, the emission and inflation remain the same. The coins go to the market, but in a different way that develops the ecosystem. Services are contracted, people provide services, is a real economy. It is exactly the same thing we did for the introduction of masternodes and that is why this coin has value. Innovation and doing things differently.
Everyone is forgetting about the end users, our goal is to create decentralized financial services for people, that are user friendly and safe and that they actually use not as an investment but as a service. To produce that portfolio of added value benefits and educate and attract the public we need funding.
It is not about setting percentages and constantly add new investors to absorb the emission, that would just be a bubble and it would eventually fail. Our top priority should be the end user and producing services that people actually use. Am I missing something?
I'm a lucky one in that I have MN ownership. I wonder though in the interest of inclusion should we provide the option for parties to contribute and vote from their wallet. If a holder of dash feels really strongly on a project they could have the option to donate and then vote accordingly. Not sure how this could be built (or what the takeup would be) but it would a potential voice for everyone not just the MN holders.
Just thinking out loud !!
Just thinking out loud !!
You can accomplish this through Shared Masternodes
, I think in the future we should finally introduce some sort of trust-less masternode pooling it would really give people more options of participation.
- Apr 8, 2014
- 1,971
- 1,339
- 1,283
If some positive feedback is enough for you you can try one of these shared MN services:You can accomplish this through Shared Masternodes
https://dashtalk.org/forums/marketplace.9/
Shoot, I had you agreeing with me on this already.
I am with you on not changing the supply. Changing block reward % allocation (temporarily per project) is the best way to do this.
Where's strix? He always has intelligent comments for times like this....
https://twitter.com/TaoOfSatoshi/status/591370363948380161?s=09
It makes sense. Nothing is forever, and this is a solution that accommodates change.
Totally agree with everything said here. What's best for the end users is best for the investors, generally. A better product creates more demand creates higher prices which rewards investors, and it's a continuous cycle. This is just a fantastic idea.
https://twitter.com/TaoOfSatoshi/status/591370363948380161?s=09
Last edited by a moderator:
Unless development brings even more money... Duh. The balance point here is "Will the proposal actually do anything useful?" And that is negated by being paid no matter what.
I don't get a paycheck for quitting my job. I don't get a piece of the block reward when I shut down my MN and unplug my miner. The standing proposal fails to address welfare/pork for non-contributors taken by force with no option to vote "no."
There is no such incentive and the argument is empty.
There is a need to balance pork with productivity and have the option to pull the plug on non-contributory members, just like unplugged miners or MNs that don't MN.
MN operators, and everyone hodling, want the decimal point to more left. But presuming that there wil always be a worthy project is short-sighted. Evan is talking about an ecosystem that outlives him. You can't hand that ecosystem over to a know pork death already exemplified by government. We know for absolute certainty that this doesn't work, we're surrounded by it every day, and is the very driving force for why crypto came into being... So we scuttle the ship in the very thing we're trying to avoid? in 20 years, what do we need this for? Why is it still being skimmed off and handed to devs/foundation for no reason?
Entitlement brats don't ever think ahead. They just squander their welfare and party on the moon until it's gone and then they want more handed to them, oh, look, a pork barrel, lets pretend to do work so we can mooch it...
Last edited by a moderator:
Now we're getting somewhere... The entitlement brats will eventually give way to the brains... Either in conceding reality, or succumbing to it...
This conversation makes my solar panels pretty...
All these "run a masternode for me because I'm too lazy and stupid" services; How will their non-votes be tallied?
Since all they did was throw money in a pot, do they really get to vote? Aren't the actual operators the ones providing service? Shoudn't they get the vote since they're the ones actually doing something?
Since all they did was throw money in a pot, do they really get to vote? Aren't the actual operators the ones providing service? Shoudn't they get the vote since they're the ones actually doing something?
To say that 15% of each block will be diverted to a project queue, as long as such queue exists, is a much, much, much better solution. We vote on whether a thing gets added to the queue. If the queue is empty, 15% is not diverted. Simple, elegant, closed-ended by virtue of not creating an open end in the first place... Cap is instated by virtue of 15% being the maximum... Self-solving paradox, just like crypto is meant to be...
A second layer of fund-rate could be added. A project queue vote, and a vote on 1%, 5%, 10% or 15% being diverted to accomplish it. This helps with non-urgency, and in price changes. It also forces voters to put their money where their mouth is. If it's so damn important, pay up, bitch! Can't force your way into other peoples' wallets.
If 1% is elected, and an individual operator feels fit to give 15% of his piece, he may do so, but cannot force anyone else to do so.
Since miners aren't voting, their piece of the pie should not be affected. They aren't giving up a part of their lives to study the proposals and make the decisions, so they neither gain nor lose their portion of the block reward in this process. It comes solely from, or not, those actually involved; the MN operators.
Fuck, I'm awesome.
A second layer of fund-rate could be added. A project queue vote, and a vote on 1%, 5%, 10% or 15% being diverted to accomplish it. This helps with non-urgency, and in price changes. It also forces voters to put their money where their mouth is. If it's so damn important, pay up, bitch! Can't force your way into other peoples' wallets.
If 1% is elected, and an individual operator feels fit to give 15% of his piece, he may do so, but cannot force anyone else to do so.
Since miners aren't voting, their piece of the pie should not be affected. They aren't giving up a part of their lives to study the proposals and make the decisions, so they neither gain nor lose their portion of the block reward in this process. It comes solely from, or not, those actually involved; the MN operators.
Fuck, I'm awesome.
Last edited by a moderator:
I kinda thought of the same thing last night.
Alot of the masternode owners are using masternode services.
Will there be any method for the actual owners to vote, or is voting only possible from 'command line' on the actual masternode?
Maybe we should find a way to vote without actually having cli access to your masternode ? Somekind of webinterface might be easiest(?).
Camosoul is putting this into perspective. Each project needs to be sold to the masternode voters. If it isn't any good it doesn't fly. If it is, it gets funded. This also opens the door for anyone to contribute - not just foundation members. It also shouldn't be a "start with x% and look at it again every 2 years if it should change". Funding should expire and need to be sold again as another project and voted on - or at least be able to get a vote no and unfund it. If we are hitting the cap vote on raising the cap, but I see no reason to wait 2 years to make a decision - that is what? 20 years in dollar terms.
I still see no reason to start with 15% take like in your first paragraph with projects rotating. This only allows one project to get completed at a time. Each project with have a length and funding that is best. Fixing bugs is an ongoing project so it would be a low reward but maybe 2 year length, where a video or wallet feature might be better as a 10% for 1 month to get it going quickly. This also opens the door for more projects, and ability to start them faster.
Interesting idea to allow different donation amounts per masternode. I don't know about this, might be better just to pay through a donation address instead and keep the voting to one % / time length.
I'll agree with you on this, but just because you said solar panels in your post above.