Self-sustainable Decentralized Governance by Blockchain

[TaoOfSatoshi]

That's why I added the part about it possibly just being honest ignorance... Money doesn't come from nowhere... He tried to present his argument as better by flopping that lie up on deck. Duh. Of course it would be better to get money from nowhere. That's how you win the argument... But there is no such thing as getting money fromnowhere. It's just like the gun control argument. "IF bad people can't get them becasue of a law..." Oh yeah, cuz that always works, I guess there's no such thing as weed cuz there's a law...

The point is, to propose an impossible solution that cannot exist and cannot work is no argument at all. I propose that we shut off gravity so we don't need cars anymore, and we can all just flap our arms and fly around everywhere... Gravity is a republican conspiracy, hate the republicans!

It's easy to suggest impossible crapola when you're too clueless to realize that it's impossible. Of course it sounds like a good idea, it's the best idea! It wins all arguments! Lets all just get money from nowhere! Whee! Free money spewing from my pockets, I voted for it! Anyone who is against free money pants pockets is a dirty republican asshole!

I get that, but at the end of the day there is no perfect system, and the priority ATM is to have a steady stream of funds to improve the project. The scenarios you speak of will likely not happen for years, due to the sheer number of possible projects. What is important is how we deal with the adjustments, and make it the most efficient (though flawed) system it can be.

 

[camosoul]

I think you raised some valid concerns, I just disagreed with some of the proposed solutions for those concerns. I think the development and promotional fund could have a cap, so that it is not open ended. A good amount that allows to cover the development needs of the project. If that cap is reached the excess could go back to miners(where it is now) to secure the network. That is where I think we see it differently, I totally disagree about it going back to masternodes, as they are the ones voting and that would create a huge conflict.

Also any project that is executed from the reserves would need the approval of all masternodes, so there will be controls in place. What do you think about something like that?

The problem I have with your perspective:

It's impossible to put it back accurately and fairly once you take it.

The MNs are responsible for the vote. They're the ones involved. It should come from their piece of the pie.

It makes absolutely no sense at all for the MNs to pay it, but it "go back" to anyone other than themselves. They paid it, it wasn't used, it should "go back" to them.

But that comes back to the first flaw in your proposal. You can't give it back properly. So, you suggest that the pork barrel be miner welfare, taxed from the MNs and then paid to the miners for doing nothing...

It just doesn't make sense, and makes you look like you're porking for the miners in a very transparent and not at all clever way...

The bottom line is; you're right. Which is why it shouldn't be done that way! We don't need a slush budget. We have tech to do better than that. You dont have to undertake the impossible task of putting it back accurately, or funneling funds from the MNs to the Miners for no reason at all... Why all this fooling around, witht he only result being a misappropriation of funds and arguments, when we can just not make the mess in the first place? See how easy that is?

 

[camosoul]

LOL! I just miss your posts...good to see you back! You have a way with words that's nice to read.

I just lurk until I see that my planet needs me...

 

[Minotaur]

The problem I have with your perspective:

It's impossible to put it back accurately and fairly once you take it.

The MNs are responsible for the vote. They're the ones involved. It should come from their piece of the pie.

It makes absolutely no sense at all for the MNs to pay it, but it "go back" to anyone other than themselves. They paid it, it wasn't used, it should "go back" to them.

But that comes back to the first flaw in your proposal. You can't give it back properly. So, you suggest that the pork barrel be miner welfare, taxed from the MNs and then paid to the miners for doing nothing...

It just doesn't make sense, and makes you look like you're porking for the miners in a very transparent and not at all clever way...

The bottom line is; you're right. Which is why it shouldn't be done that way! We don't need a slush budget. We have tech to do better than that. You dont have to undertake the impossible task of putting it back accurately, or funneling funds from the MNs to the Miners for no reason at all... Why all this fooling around, witht he only result being a misappropriation of funds and arguments, when we can just not make the mess in the first place? See how easy that is?

Well that is a way to see it, I guess the fundamental disagreement is that in my opinion the development funds would not belong to the masternode operators, this is not a donation model, so they should not go back to them, as they are the ones voting and that would create a conflict. I know we see that differently but I reconfirm my position on that.

I do agree on the system not being open ended, I think a reserve amount could be defined and the excess (goes back to) stays with miners. Where it is coming from already, you seem to keep ignoring the fact that the miners are still mining the coins and the current rewards are 42.5% MNs and 57.5% miners. Also I liked the idea of a periodic revision of the program, maybe every 12 months could work.

So a reserve with a cap would avoid excess or the system being open ended, a yearly revision of the reserve amount to consider price appreciation and revise the results of the program in general. I think that could be a good way to address your concerns. I don't think we will agree on where the excess goes after the reserve amount is reached, I don't see that going to masternodes as they are the ones executing the budget, and that creates a loop-hole and a conflict. I believe it could just stay with the miners that are generating the coins, so if the reserve is met the coins stay securing the network. Just an idea.

 

[camosoul]

If there are too many projects voted yes for the 15% cap, then there would a project priority vote.

I was just about to post something like this. We need to select inclusion, funding rate, and priority.

1) Are we doing this shit?
2) How much funding do we want to divert to this shit?
3) Is shit A more important than shit B? No? OK, Shit B is more important than shit A.

 

[camosoul]

Well that is a way to see it, I guess the fundamental disagreement is that in my opinion the development funds would not belong to the masternode operators, this is not a donation model, so they should not go back to them, as they are the ones voting and that would create a conflict. I know we see that differently but I reconfirm my position on that.

I do agree on the system not being open ended, I think a reserve amount could be defined and the excess goes back to miners. Where it is coming from already, you seem to keep ignoring the fact that the miners are still mining the coins and the current rewards are 42.5% MNs and 57.5% miners. Also I liked the idea of a periodic revision of the program, maybe every 12 months could work.

So a reserve with a cap would avoid excess or the system being open ended, a yearly revision of the reserve amount to consider price appreciation and revise the results of the program in general. I think that could be a good way to address your concerns. I don't think we will agree on where the excess goes after the reserve amount is reached, I don't see that going to masternodes as they are the ones executing the budget, and that creates a loop-hole and a conflict. I believe it could just stay with the miners that are generating the coins, so if the reserve is met the coins stay securing the network. Just an idea.

I see your perspective, but I fundamentally will always disagree with socialism.

I see your point about a donation model, but that is a misrepresentation. MN operators aren't just hodlers. Its not just wisdom of the hoarde. It's a specific demographic with a specific intent.

Budgets always get abused. Especially in crypto... We don't need one. We're beyond that level of handling money here... The best way to clean up a mess is to not make the mess in the first place.

I realize that you see a conflict f interest in MNs voting the money back to themselves. Which is why I say that shouldn't exist.... By virtue of only allocating funds as needed and as voted upon. We don't need too create abuse-able funds.

A reserve with a cap may mean very expensive projects exceed the cap and never get done.

The bottom line here is that doing it your way is really damn complicated and has a few problems that have no solution. I suggest it be controlled from the front end instead of the back end. we have a cap on the flow, not the total amount. This is essentially unlimited funding while also not being open to abuse. If we can vote in priority, fund rate, and whether a project is to be funded at all, then it's all handled on the front end and we don't have any impossible mess to clean up.

This way funds are only collected if they;re needed and there's no pork barrel to abuse, manage, re-apportion back to where it came from, etc... Don't make the mess in the first place.

Budgeting; we can rebuild it, we have the technology... We don't have to keep doing it the old, flawed way. The only people who want the old, flawed way are those who use those flaws to their advantage...

I'm not trying to prevent a specific person from doing a specific thing. The fact is, if there's a piece of cheese, a mouse will find it. Don't create the piece of cheese. It doesn't matter if you think a welfare brat will abuse it, or the MNs will abuse it. Don't create "it" and there's noting to abuse in the first place.

 

[Solarminer]

Maybe others have not had the experience in the corporate world at the end of the year, "Spend it or you lose the budget next year." Really, is this not just the most wasteful allocation of company funds!

Taking rewards for masternodes or miners will have detrimental consequences. Whether it be a less secure blockchain, slower transactions, or less investment into masternodes. The money from these rewards is not FREE.
(just so I am not misunderstood - I still believe it is valuable to for a certain amount to go to R&D and Marketing as long as the project makes sense, the best gauge in my eyes would be a MN vote.)

Tao/Minotaur
I understand there are a lot of people working in the background and they should be compensated for the work done. The "steady stream of funds" and "returning funds" are not the language of an efficient organization. Specific projects and specific funding amounts need to be voted in. Heck, if there was anti-troll project it may even fly.

This is like a business starting out. The owners don't get paid at first. Once the company starts providing value to customers and is profitable, then the owners are compensated. This isn't the corporate world where you have a 9-5 job and get paid for being present and acting like you are working.

 

[Minotaur]

Maybe others have not had the experience in the corporate world at the end of the year, "Spend it or you lose the budget next year." Really, is this not just the most wasteful allocation of company funds!

Taking rewards for masternodes or miners will have detrimental consequences. Whether it be a less secure blockchain, slower transactions, or less investment into masternodes. The money from these rewards is not FREE.
(just so I am not misunderstood - I still believe it is valuable to for a certain amount to go to R&D and Marketing as long as the project makes sense, the best gauge in my eyes would be a MN vote.)

Tao/Minotaur
I understand there are a lot of people working in the background and they should be compensated for the work done. The "steady stream of funds" and "returning funds" are not the language of an efficient organization. Specific projects and specific funding amounts need to be voted in. Heck, if there was anti-troll project it may even fly.

This is like a business starting out. The owners don't get paid at first. Once the company starts providing value to customers and is profitable, then the owners are compensated. This isn't the corporate world where you have a 9-5 job and get paid for being present and acting like you are working.

Please don't confuse the fact of Tao quoting me, with me sharing his opinion. I do believe there are people on the team that should be compensated, but you can count me out of that list. I don't want the added responsibility of being paid to do this, as I currently very much enjoy it as a volunteer.

On the other hand, we very much need to have funds for execution, I don't want 1 DASH for myself, but I really need a developer PHP/Node JS/ Java, etc that can work with me on the integration of services. I often talk to companies like exchanges, crypto atms, merchants, etc. That say they would allow us to integrate Dash but we need to do the work of integrating their platform. I was looking forward to proposing having an integration developer on the team I could work with without bothering our core developers.

Solarminer Also, could you check my proposal to camo a few posts above this one? About executing a budget so you get funding next year it would not be the case as we would have a reserve(warchest) of a reasonable amount that rotates and the masternode operators as a whole execute. What do you think of that?

 

[Solarminer]

I was just about to post something like this. We need to select inclusion, funding rate, and priority.

1) Are we doing this shit?
2) How much funding do we want to divert to this shit?
3) Is shit A more important than shit B? No? OK, Shit B is more important than shit A.

I think this gets really ugly with a simple yes/no vote. Maybe the runoff for priority will be something like this with the 10 highest and 1 lowest:
ProjectA-10
ProjectB-8
ProjectC-1
So lets say there is only funding for the ProjectA and ProjectB. ProjectC was still voted in as a yes on the first vote so it will be put in a queue and will start when the funding is open.
There could be something in place where the project owner could reject their project and submit again with a different funding amount.

 

[camosoul]

Maybe others have not had the experience in the corporate world at the end of the year, "Spend it or you lose the budget next year." Really, is this not just the most wasteful allocation of company funds!

Taking rewards for masternodes or miners will have detrimental consequences. Whether it be a less secure blockchain, slower transactions, or less investment into masternodes. The money from these rewards is not FREE.
(just so I am not misunderstood - I still believe it is valuable to for a certain amount to go to R&D and Marketing as long as the project makes sense, the best gauge in my eyes would be a MN vote.)

Tao/Minotaur
I understand there are a lot of people working in the background and they should be compensated for the work done. The "steady stream of funds" and "returning funds" are not the language of an efficient organization. Specific projects and specific funding amounts need to be voted in. Heck, if there was anti-troll project it may even fly.

This is like a business starting out. The owners don't get paid at first. Once the company starts providing value to customers and is profitable, then the owners are compensated. This isn't the corporate world where you have a 9-5 job and get paid for being present and acting like you are working.

I want to add on tot he end of this to give more perspective.

PEople with no experience in money handling see cookie-cutter businesses and want to emulate them by doing dumb things off the bat. Usually, borrowing money in an effort to do everyting at once. Then the payments and interest bury them before thery get off the ground.

I see that same attitude here. They want a big slush fund topay for stuff. No. Pay as you get the money.

With this proposal befre DASH, we dont hve payments or interest, but we do have a much more prone to abuse environment. This is crypto. It's the scum of the earth. We have a much better reason to avoid a pork barrel than anyone else. IT's MORE important not to make that mistake because abuse is a guarantee, not a maybe.

 

[Minotaur]

I think this gets really ugly with a simple yes/no vote. Maybe the runoff for priority will be something like this with the 10 highest and 1 lowest:
ProjectA-10
ProjectB-8
ProjectC-1
So lets say there is only funding for the ProjectA and ProjectB. ProjectC was still voted in as a yes on the first vote so it will be put in a queue and will start when the funding is open.
There could be something in place where the project owner could reject their project and submit again with a different funding amount.

If you read the OP it already more or less works like this, I am sure it can be refined, but the proposals are ordered by percentage of approval so something that gets 80% approval would have higher priority than something that gets 55% approval as an example.

 

[camosoul]

I want to mention, about 4-5 MNs are crashing every 24 hours in the last week... If the daemon won't stay running, how will the votes get counted?

 

[Minotaur]

I want to mention, about 4-5 MNs are crashing every 24 hours in the last week... If the daemon won't stay running, how will the votes get counted?

Votes are messages that propagate through the network, just like a masternode start message, the wallet does not need to stay open after the vote is cast. I guess the vote would need to expire if the collateral is sold or something. Udjin or Evan could better explain how that works.

 

[camosoul]

Votes are messages that propagate through the network, just like a masternode start message, the wallet does not need to stay open after the vote is cast. I guess the vote would need to expire if the collateral is sold or something. Udjin or Evan could better explain how that works.

Sure, but what uptime do I need to establish the validity of my vote? Surely I can't jsut tart a node, vote, move the funds to a new address, start that one, vote again... As the democrats say; vote early, vote often... I the damn thing won't run long enough to even get a payment, can it still vote? Is that good or bad?

 

[Solarminer]

Please don't confuse the fact of Tao quoting me, with me sharing his opinion. I do believe there are people on the team that should be compensated, but you can count me out of that list. I don't want the added responsibility of being paid to do this, as I currently very much enjoy it as a volunteer.

On the other hand, we very much need to have funds for execution, I don't want 1 DASH for myself, but I really need a developer PHP/Node JS/ Java, etc that can work with me on the integration of services. I often talk to companies like exchanges, crypto atms, merchants, etc. That say they would allow us to integrate Dash but we need to do the work of integrating their platform. I was looking forward to proposing having an integration developer on the team I could work with without bothering our core developers.

Solarminer Also, could you check my proposal to camo a few posts above this one? About executing a budget so you get funding next year it would not be the case as we would have a reserve(warchest) of a reasonable amount that rotates and the masternode operators as whole execute. What do you think of that?

I think the idea of a developer to grow integration services is fantastic. This could easily be put in a project and voted in. Maybe this starts as a short term project like 3 or 6 months to see what can get accomplished. Maybe these merchants will provide some matching funds too. The market will also need to fairly decide if a mobile wallet is more important and/or developer is more important now. Or maybe you put a project contingent on another. You will need the mobile wallet first before you can develop and test a crypto ATM.

I really don't want to consider a master budget with votes on funding to go up or down. This to me adds a ton of overhead. With the world of crypto I see no reason to pay for a treasurer, accountant, escrow wallet management(Warchest), manager to return funds, This should be simple. Project funded = % of rewards goes to the project owner. No 3rd party, no meetings. Why wait a year to get a project started - just submit it and go when funded. And if the 15% cap needs to change, vote on it - don't wait until the end of the year.

 

[Solarminer]

And I will also add that if we are seperatly funding each project and any specific project is under budget, Great! the owner has a profit. Let him/her keep it or donate it. If a project is over budget then a revised project with round 2 funding will need to get voted on. This keeps an incentive for the project owner to be efficient. It also encourages a low project cost to get voted in.

 

[Minotaur]

I think the idea of a developer to grow integration services is fantastic. This could easily be put in a project and voted in. Maybe this starts as a short term project like 3 or 6 months to see what can get accomplished. Maybe these merchants will provide some matching funds too. The market will also need to fairly decide if a mobile wallet is more important and/or developer is more important now. Or maybe you put a project contingent on another. You will need the mobile wallet first before you can develop and test a crypto ATM.

I really don't want to consider a master budget with votes on funding to go up or down. This to me adds a ton of overhead. With the world of crypto I see no reason to pay for a treasurer, accountant, escrow wallet management(Warchest), manager to return funds, This should be simple. Project funded = % of rewards goes to the project owner. No 3rd party, no meetings. Why wait a year to get a project started - just submit it and go when funded. And if the 15% cap needs to change, vote on it - don't wait until the end of the year.

About the integration of services, at the beginning we will have to do a lot of the work because we don't have much leverage, but as adoption grows then businesses would integrate Dash without any help more often and we can concentrate ourselves in looking for key partners. We can discuss that one later, just one of my ideas for the program.


About mechanics of the project, I think we have discussed very interesting ideas, it is hard for me to go deeper right now as I am not entirely aware about how plausible the implementation of any of these ideas is from a technical perspective. There may be a great idea that would produce forks or another idea that we did not consider that is technically viable. I am sure Evan will read this thread, so right now I am inclined to wait for technical feedback on what we have discussed so far, to be sure that the discussion remains within what is possible to implement.

 

[Minotaur]

Sure, but what uptime do I need to establish the validity of my vote? Surely I can't jsut tart a node, vote, move the funds to a new address, start that one, vote again... As the democrats say; vote early, vote often... I the damn thing won't run long enough to even get a payment, can it still vote? Is that good or bad?

That does not seem hard to avoid, maybe it requires a certain age for the collateral funds to start voting, if you move to a new address you would lose that. Just one idea.

 

[Darkuopm]

In my opinion, pulling a set amount from the blockchain for future spending encourages frivolous spending. I would instead say that the blockchain amount changes only when there is a need. For example, a proposed video to support Dash needs a 6 month take of 1%. MNs vote and then after approved the split changes. After 6 months the split reverts. We could do the same for new features, wallets, etc. I would encourage each funding proposal to expire after a set time. Putting a permanent 'development tax' on the blockchain sounds really bad to me.

There are other funding opportunities that could return an income. An exchange could be funded that would profit from transaction fees. The profit could go to management, funding other projects, or even paying back the amount funded.

I think you have some interesting thoughts on the subject but nothing is set in there to stop the masternodes form voting for a disbursement of funds to be split among the masternodes. So if through careful diligence and oversight there grows an excess of funds, in theory they could be returned to the current masternodes.

 

[TanteStefana]

I would like to see the setup of this project as simple as possible, but no simpler So what are the inherent flaws in this setup - and can they be overcome by oversight? DAO = Distributed Autonomous Organization


15% of block rewards are awarded the DAO. The Masternodes approve payments requested from the core developers and marketing sections of DASH working under the Foundation's oversight.


Projects may be submitted by developers or created by the community and sent out to bid. Masternodes vote on these projects and if approved AND funds are available, the projects get the green light.


At the end of each year, funds that are not used up are set aside in another account and distributed back into the network 1/210240 of the total at each block reward, redistributing it fairly back into the system.


Or this could be done every 2 years if a back up savings account is desired. This way there is a small but not huge incentive to save money, especially when dash becomes worth so much that it would be wasteful to spend it all.


Masternode voting, for practicality, would be at least 2/3 of masternodes participating and 51% or more yays to approve a project. There probably should be a way for masternode owners to give their votes to trusted entities, if they are not willing to study the propositions and vote. They could designate a person whom they trust and have them vote for them.


This would be desirable if we can't get 2/3 of the voting shares to participate. It's not easy to keep up on projects and be aware of all considerations. Perhaps the trusted voter could be the foundation (your shares would go whichever way the foundation is swinging? I suggest this option only because I see MN owners not keeping up with what is going on? I may be wrong here??