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

Self-sustainable Decentralized Governance by Blockchain

IMHO

Most of us have said: "Dash should become Cryptocurrency number 1!"
That is, its price has to grow at least 200 times (in current prices) ...

Do you think it will happen by itself?
Or miners can somehow will magically mine it?
Or MN operators can somehow magically do it?
Or ingenious Evan&team needs to do a miracle for everyone else?

No, of course by itself occurs only bad, but all is well - are earning with appropriate effort. In the case of DASH - efforts to develop and promote. Something that now gets the minimum of DASH resources.

Some of us think that spending 15% of the new coins for development - is "too much" to implement long-term plans to increase the price on 20,000%. I believe this is a good deal and 15% is opposite - too little. :)

You just think on today's level of abilities and levels of expenditure. But we must think about perspectives and appropriate levels of efforts and levels of expenses - multiply them in 20, 200 times (in USD)... Not from the very beginning, but as a result.

If greed will not allow us to invest in the development - there will appear other more reasonable projects that implement this model and will implement it effectively - so the best people and so on will go there.

Therefore Dash community should reject greed and reinforce their ambitions by real actions and decisions.

Let's offer to MN ops 1-2-3 models and let them vote for the best model. After some "testing period" we will see the result of that decision and could vote if any correction needed and so on - not so complicated.
 
Last edited by a moderator:
If everyone else wants to keep jerking it, I've already spent too much time explaining that imaginary advantages are imaginary. Imaginary advantages are not worth having a fatal flaw.

The answer is on page 11... I trust the current devs to be smart enough to see it.
 
Fixed your attack for you.

Also,

Already explained it several pages ago, before all these off-topic distractions of budgeteers who can't wrap their head around the fact that their suggestions are imaginary and detrimental.

It's been at least 3 pages of herding cats with the palsy since I nailed it.

Ok: "So in point form and without hyperbolic bilious examples how would you do it." :)

Gaddammit you made me read through it all again.

Ok so this:
1) Vote for inclusion in queue.
2) Vote for block percentage to be put into queue.
3) Prioritize projects in queue.

Ok. Makes sense. Could work.

I imagine at the end of this rambling thread it will come down to a vote - the test of the voting system perhaps.
 
Last edited by a moderator:
Ok: "So in point form and without hyperbolic bilious examples how would you do it." :)

Gaddammit you made me read through it all again.

Ok so this:
1) Vote for inclusion in queue.
2) Vote for block percentage to be put into queue.
3) Prioritize projects in queue.

If queue is empty, nothing gets diverted in the first place.

Work queue is the key, the percentage and priority are useful tools under it.

Keep MN reward schedule as it was defined previously.
 
So what if the majority of MN owners vote no to everything to keep the queue empty?
I already address this argument.

They would have to be retards, which they're not, becasue they're MN operators. They want projects of actual merit to be funded because it moves the decimal point tot he left.

By all means, I will spend 15% for a few weeks to increase my fiat exchange from $3 to $300. Fucking duh. I have how many masternodes? I have way more reason to want it than you do! I hold over 50K DASH worth of MNs at this time. When the decimal point moves for me, it means a fuckload more than it does for you... I have MORE motivation, not less. I want to piddle around on $3 DASH forever by voting no on everything? Where does the idea come from? How can you suggest that MN operators hate money so much, when they already have more than you do? It makes no sense at all. Maybe you only have 12 DASH in your wallet, and it's really no big deal if that changes from $36 to $3600. I have over $150,000 in it. Do the math. $15,000,000 in the same scenario. Are you really suggesting that I would want to prevent that from happening? What are you smoking and where can I get some?

MN operators are not miners... You're trying to apply a false argument, on top of applying that false argument to a demographic that doesn't fit...
 
I'm neither attacking nor arguing with you.

They would have to be retards was a sufficient answer for me.
 
I'm neither attacking nor arguing with you.

They would have to be retards was a sufficient answer for me.
I was just providing details... Don't take it so personally, it isn't stated personally.

This is a public forum, not a PM. Bystanders sometimes need help...
 
Last edited by a moderator:
Alright it's time for me to put my 2 duffs in...



This reimbursement method could cause trouble. Think about it... There's a scheduled "bonus" for 500/1000/however many blocks, this attracts multipools and other exploitative miners who are just looking for the best $/day they can get. These miners are the most likely to cash out of their mining proceeds ASAP which could cause a downswing in price. These miners on our network reduce our DASH income and it's fiat value simultaneously. These miners have no interest in the project, just their own immediate profit, so why are we going to give them a piece of the pie that was set aside for the long term good of our currency? These are some of the dreaded "freeriders" we've been worrying about the past few pages. The only way to implement this plan successfully would be to make the disbursement amounts so negligible it wouldn't attract these types of miners, which would essentially just make the remaining balance a "delayed" payment for long term miners and node operators.

In regards to the original debate, I am with thelonecrouton on this one... I see zero reason to allocate funds before we have a purpose for them. There is no need to create any excess funds that we have to worry about returing "fairly" when we could just avoid that situation altogether. Why couldn't we set a premise to allow a maximum of 15% to be diverted if there are enough (a set number) projects to utilize it? Example: fund a maximum of 10 projects that collect 1.5% each. 1.5% gets diverted directly from block reward once the vote to fund it passes, and not a moment sooner. This can be split up to fund smaller projects too... Example 2: 5 major projects claiming 1.5% each, and 10 lesser projects claming 0.75% each. Or 5x1.5%, 5x0.75%, 10x0.375% or something along those lines. With a little prioritization we can negate the whole "fair wealth redistribution" problem every other governing body on the planet has.

If there are any typos please forgive me, I'm on mobile.
That's why I was suggesting that any unused funds over and above the accpted savings account should be distributed yearly with each block getting 1/#of_blocks/year and the same thing is done each year automatically. There wouldn't be a huge pile of coins sitting in the blockchain not doing anything and the insentive for MN voters to vote against everything because it gives them more coins would be minimal and delayed.
 
I was just providing details... Don't take it so personally, it isn't stated personally.
No offence taken.

crowning this is my summation of camo's proposal:

1) Vote for inclusion in queue.
2) Vote for block percentage to be put into queue.
3) Prioritize projects in queue.
4) If queue is empty, nothing gets diverted in the first place.
5) If queue deliberately kept empty MN owners are stupid as they are shooting work key to value increase in the foot.
 
No offence taken.

Crowning this is my summation of camo's proposal:

1) Vote for inclusion in queue.
2) Vote for block percentage to be put into queue.
3) Prioritize projects in queue.
4) If queue is empty, nothing gets diverted in the first place.
5) If queue deliberately kept empty MN owners are stupid as they are shooting work key to value increase in the foot.
6) MN owners are less stupid than traders and miners, so that won't happen.
 
5KMI: Agreed. Just trying to figure out how such a reimbursement would work which indeed highlights how difficult such a thing would be. To me any excess should be just go to the dev fund.

No, I think when we're running with a lot of excesses, which probably won't happen for at least 5 years, IMO, that the 15% should be reduced to something closer to what is being used, and it should be re-evaluated each year. Because think of it.... then number of coins taken will be the same less 7% each year, yet the value taken could be 1000X more. Funding should probably be converted to real money each month, with the developers/workers getting better value at the end of the month enjoying it as a bonus for a job well done. Eventually this will slow down, but if we're successful, there will be too many coins being withdrawn. Those funds, at some point, might be better used for more masternodes or miners at that point.
 
They would have to be retards, which they're not, becasue they're MN operators. They want projects of actual merit to be funded because it moves the decimal point tot he left.

I agree with you, but this will end exactly where a publicly traded company normally ends: only projects are supported which increase the value of a company.

What do Masternode owners do when Dash and crypto-currencies in general are in a long-term decline (see Bitcoin 2014 - 2015)? There's no incentive to spend money because the decimal point moves to the left anyway.
 
I agree with you, but this will end exactly where a publicly traded company normally ends: only projects are supported which increase the value of a company.

What do Masternode owners do when Dash and crypto-currencies in general are in a long-term decline (see Bitcoin 2014 - 2015)? There's no incentive to spend money because the decimal point moves to the left anyway.
Working as intended. There is no problem. If there is no need to spend money, don't. Are you suggesting that we spend money for no reason, and that it is good to do so?
 
Working as intended. There is no problem. If there is no need to spend money, don't. Are you suggesting that we spend money for no reason, and that it is good to do so?

Assume a project with is technically necessary, but may (or may not) only influence the value after a year or two when certain other factors apply.
A Masternode owner will do the 0.5 DASH per Node/day * 365 days math and come to the conclusion that he most probably get more money by not supporting it.

After all, NOT giving money is the save bet.
 
Camosoul, I really think there is a big advantage to having a fund up front, and returning excesses. It allows us to pay in a timely manner and get projects started right away. I don't think a proposal should be given the entire budget to do the job, but rather, get paid as each milestone is met. We should not have to trust our contractors, especially if some of them want to be anonymous. But when a portion of the work is completed, sure, we can pay for it. But it's easier to work this when you have the funds ready to go. The excess can be returned later, and in fact, the amount taken in the first place can be re-set as the value of the coin goes up.

I really think that waiting to put funds aside until after a project is decided upon is far too clunky. That's my only objection. I totally agree that we can't have a boondoggle sitting out there for scammers to collect on, but we need to be nimble, we need to be able to move on things when the opportunity comes up. Otherwise we'll be as sluggish as Bitcoin still, and somebody else will pass us by.
 
Also worth noting, anyone trying to compare this to failed government budgeting programs is making a seriously flawed comparison. This program would be more akin to what we see in large publicly traded companies like Apple or Microsoft that have budget committees.

http://www.investopedia.com/terms/b/budget-committee.asp

The key difference is that in government programs voting parties don't have a financial stake in the outcome. In our program the votes are done by the masternodes, who happen to be those holding larger financial stakes. Large coin holders need prices to move an order of magnitude to justify their risk/reward, which typically results in them taking a longer view on things. Where as smaller holders can exit on any move. And to suggest that they are just going to vote something wasteful into existence or to continue to let them operate in a wasteful manner is just silly.

So it should be obvious the long term goals of Dash are most aligned with it's largest holders (the masternodes). Much like a publicly traded company that has a budget committee that consists of the top management (who also tend to have some of the largest financial stakes in the company) deciding on how money is spent, our program will be doing the same.

-EM

Read more: http://www.investopedia.com/terms/b/budget-committee.asp#ixzz3YLr0B5aY
Follow us: @Investopedia on Twitter
 
Last edited by a moderator:
I agree with you, but this will end exactly where a publicly traded company normally ends: only projects are supported which increase the value of a company.

What do Masternode owners do when Dash and crypto-currencies in general are in a long-term decline (see Bitcoin 2014 - 2015)? There's no incentive to spend money because the decimal point moves to the left anyway.

The only projects we should be promoting are core development, marketing and projects that either need to use the masternode system to function or are so basic to everyone's needs. After that, I see sub companies developing based on what we have here.
 
Assume a project with is technically necessary, but may (or may not) only influence the value after a year or two when certain other factors apply.
A Masternode owner will do the 0.5 DASH per Node/day * 365 days math and come to the conclusion that he most probably get more money by not supporting it.

After all, NOT giving money is the save bet.
I see it more like this, pardon the total change of venue.

BitCoin surged to $1200. For no reason. It was noting but hype pump.

Who was there to fill in REAL support so it would stay there? The value was present. It was squandered.

BitCoin ATMs to band-aid the block wait problem? We see how well that's turned out...

It's not just moving the decimal point, but filling in REAL things like ADOPTION that keep it there. MN operators are vested in this in a key way that has never existed in crypto before.

So, that answers your question from the other end. MN operators will not be solely concerned with doing the math, but filling in the infrastructure by using value that is already there. They won't just want to, they'll be foaming at the mouth to do it! What good is it if your MN is worth a quarter million for a day, then goes back to nothing again? M operators will be voting yes on every project that expands the input potential. Like jumping in the air ad having someone pile 2 feet of dirt under you so you don't come back down. Do it again, and again...
 
Instead of posting options and rehashing all the options I have laid out the the 3 different mechanisms and potential options to make this happen:

Voluntary Donation Model – This is what we have now

Each donator(Mastermode owner or anyone) determines how much and which project to contribute to.
Voting is purely based on how many donations are provided to each project.
Pros
Only the donators that want to donate need to.
There isn’t any special voting system needed.​
Cons
Projects are not prioritized
Projects are not guaranteed to be fully funded even though donations are sent.
Possible to fund 10 projects and have each only have ¼ funding needed and none of them can be completed.
Donators may not want to donate if there is a possibility the projects won’t be fully funded.​

Mandatory Donation Model

15% of block rewards are put into a ‘fund’.
Projects are voted on by masternodes and winning projects get funding from the fund.
The fund could be:
DAO(digital autonomous organization)
multisig wallet with founders with keys or triggered by masternode vote​
Pros:
More control by fund managing members
Forced donations(benifitial to founders/developers)​
Cons:
Forced donations (masternodes have no control)
Fund will always be either under and over funded
Likelihood of a loss/theft however funds are stored
Projects don’t start until funding has accumulated
Once all good projects are complete, the funds may be going to useless projects.
The managing members of the ‘fund’ will have an incentive to spend them.
Funding is provided based on project, not based on if a project is worth the cost)
A budget, budget review meetings, fund manager, accountant, and other activities will be needed.
The 15% block rewards might be better used for encouraging mining(securing the block chain), encouraging masternodes(faster transactions, DASH investment).
The 15% block rewards might be small now, but in 10+ years this could be a significant amount.
Once a fixed donation amount is in place, it is unlikely to be reduced.​
Variations:
Review block rewards % as needed (each year) to compensate for under/over funding projects.
Return unused block rewards to masternodes or miners
Instead of storing funds the highest priority project would get the full 15% of the block rewards until complete, then block rewards are passed to next project.​

Vote per Project Donation Model

15% Cap on Donations from Block Rewards
Projects are submitted with a funding % and time that amount is needed.
Masternodes vote on each project.
Core projects can go forward automatically, unless a vote no threshold is achieved
Other projects are assumed no go, unless voted to go forward by a certain vote yes threshold.
Projects are funded directly from the block rewards.
15% cap can be voted on to increase/decrease as needed.
Pros
No ‘fund’ to manage, or risk with loss/theft/taxes. No budget, fund manager, accountant, etc.
Instant ability to start project contributions
Only valid and effective projects will get voted forward – decided by the best voters 1000 DASH investors.
Masternode owners have an interest in keeping DASH value as high as possible. They should vote projects forward that will increase DASH value.
Block rewards are used as needed. No inefficient use of funds.
Easy to scale for the future. If DASH changes in value the project % changes.​
Cons
Projects don’t get fully funded upfront on vote approval but get a long term distribution of funds.
Possible that masternodes may not vote any project forward, in favor of immediate rewards.​
Variations:
If full funds are needed to start a project, an investor could front the full amount in return for the distribution of funds, which may include an extra fee for the service.
Masternodes could vote on % block rewards removed from to miners only to encourage more positive votes(less incentive to a MN to vote for personal gain).
Masternodes could vote with % block rewards removed from masternodes making it more fair for miners.​

Voting Methods
Majority vote – 51% yay to pass
Majority vote with Limited Nay – 51% yay to pass, but only if less than 10% Nay
Supermajority vote – 66% Yay to pass
Unanimous – 90%+ Yay to pass
Voting time length – 1 week or 2 weeks
Priority of project to start first based on the most yes votes.
Projects that are voted in but above funding cap will be put in a queue until when funding available.
Voting with yes/no (Question matrix required)
Voting with a variable-yes/no. (masternode vote Blinding-Y or masternode vote BLY)

Block reward options per project:

Amount: 1% -15%
Time length: 1mo, 3mo, 6mo, 1year, 2 years

Project submittal options:
Project entered on a website or emailed, with Block reward %, Time, and activity name, and DASH address.
Project entered into wallet. Maybe the command masternode create project(2,12,Blinding, DASH address) for a 2% reward, 12 months, called Blinding.
masternode list projects would list all available projects to vote on.
Masternode remove project or revise project could also be added. Might require a wallet signature from the wallet with the DASH address. Or verify by IP address.
Website or a forum post would provide further details on the project goals.
There would need to be a check to ensure duplicate projects are not entered and values don’t exceed acceptable limits.

So laying this out, here is what I would propose.

  • Vote per project donation model
  • 15% cap on rewards, which only come from masternode share of block rewards.
  • Majority vote – 51% to pass or 51% to stop (but I don’t have much of an opinion on the %) with 2 week time limit for voting
  • Projects prioritized by amount of yes votes, and put in queue any project voted with majority that can't fit under 15% funding cap.
  • Modify Voting from Yay/Nay to voting with a “Project Name”-Y/N
  • Modify wallet to include the masternode create project(2,12,Blinding, DASH Address) and masternode list projects.
  • Details about each project posted by the owner in a forum post.
 
Last edited by a moderator:
Back
Top