Self-sustainable Decentralized Governance by Blockchain

[crowning]

+1
I hope eduffield is reading these posts from both angles... And if he still thinks he needs to allocate a large portion of funds to marketing... please, Evan, read the Dash sections for wallet/daemon support and guides...

I'm sorry to state the obvious, but it will not be up to Evan to decide if and how much funds will be used for what...

 

[Solarminer]

How about MNvoting for the percentage? We start at 1% and after each round of voting where the YES is >50% the percentage goes up 1% and the voting starts again until YES is <50%.
Then that percentage is used for projects.

I just put some numbers together so we could look at this in a rational way. Assuming DASH is $3 US and 1% is 1 out of 60 MN payments of 2.8 DASH.
1% Project would pull in $2,400/mo or $29,030/year
3% Project would pull in $7,300/mo or $87,100/year
5% Project would pull in $12,100/mo or $145,200/year
10% Project would pull in $24,200/mo or $290,300/year
15% Project would pull in $36,300/mo or $435,500/year

A programmer would be paid about 3% now. Even with a 9% cap, we could still have 3 projects with 3% funding and have a dedicated programmer working on each. Of course, in 5 years this could be 0.1% for a programmer.

My view is that 3 projects at a time is all we should be focusing at once. Each project would be a 3 month commitment. If less funding is needed than the 3 month amount, funding stops when complete and the slot is opened for another project.

Now back to fuzzyduck's comment. I don't think the projects should just get arbitrarily voted up for more %. The project owner should commit to a certain amount of funding. I just see this based on people needed (1 programmer, 1 tester) or whatever the project owner envisions. For projects paying for a service(video) than the funding % would be based on what is needed in 3 months.

 

[Solarminer]

Somewhat OT but there's a whole lot of very under-utilised MN hardware out there...
What about an option for distributed MN cloud backup of your wallet as long as it has a decently complex passphrase and isn't enormous? I'd never keep my main stash online, though this might be irrational of me as with a good passphrase it would be safe enough, but I'd be happy with my day to day wallet being backed up this way. 2FA could be used to access.

The last "Let's talk Bitcoin" talked about wallets. It was interesting what has come about.

• The bitcoin core wallet is really secure, but takes minutes to hours to load up and sync with the network.
• The web wallets are really susceptible to getting hacked.
• There are hybrid wallets with more security, and less wait to load up and sync.

It seems like there is really no ideal solution. Any convenience of web wallet is limited by the likelihood of hacking. The hybrid wallets had issues with too many transactions, which should be fixed. A good passphrase for a web wallet would need to be 12 random words. To me this is just impossible to remember. It is crazy the lengths Andreas Antonopolis goes to, just to secure his bitcoins(removing network cards on his computer while creating keys). There is a ton of potential for improvement here.

I think the key is 2FA. You can have a phone wallet/web wallet with a simple passphrase and then if coins need to be transferred, you confirm with a text/email/authy app.

As for anyone else storing my wallets in the masternode network, no thanks. I want to keep my wallets offline as much as possible.

 

[Solarminer]

This 15% is a property of the Dash Network -- not a tax that is being given or taken away. It's used to create a self-sustaining system; it's a freaking genius idea if left undiluted.

Taking 15% without a vote from the network is a tax. Right now it is going to miners and per the MN payment schedule will go to the MNs in 2016. The argument that it is coming from the network would have worked if this was a new coin. Doing this now is a tax.

Taxing 15% to pay for pizza for meetings to review goals (without any desire from the community for this) = not a genius idea.

Voting for valid projects with 15% of the block rewards. Having investors with 1000 coins vote on each project keeping a check on good/bad value projects based on the increase in their 1000 coins vs loss of 1/4 of their block rewards = Genius Idea!

 

[crowning]

Taxing 15% to pay for pizza for meetings to review goals = not a genius idea.

I seem to repeat myself all day, I guess nobody reads my posts any more: if someone wants to spend money on pizzas just vote NO. Or yes. It doesn't get any simpler than that.

THAT is the genius idea. No discussion, no name calling, no "Evan said this / Evan decided that / Evan is a dictator" arguing.

Your "free pizza & beer for Solarminer" didn't get enough votes? Come up with a better one.

YES , or NO. What's it gonna be boy? I can't wait all night...Yes or No?

 

[Solarminer]

I seem to repeat myself all day, I guess nobody reads my posts any more: if someone wants to spend money on pizzas just vote NO. Or yes. It doesn't get any simpler than that.

THAT is the genius idea. No discussion, no name calling, no "Evan said this / Evan decided that / Evan is a dictator" arguing.

Your "free pizza & beer for Solarminer" didn't get enough votes? Come up with a better one.

YES , or NO. What's it gonna be boy? I can't wait all night...Yes or No?

I am with you. I clarified my post. Obviously, if there was a vote for a pizza event and it won, fantastic the system works.

 

[Bridgewater]

I just came across this while researching open source private communication tools:

https://github.com/WhisperSystems/BitHub

While the details of our amazing SDGB project are still being hammered out, could the BitHub service be employed as an easy way to utilize the already in-place MN donation feature to automatically distribute money to devs whenever they contribute? I can't read code, so I'm not sure exactly how it works or if any of it can be adapted to work with Dash.

Moxie Marlinspike explains it in a blog post here https://whispersystems.org/blog/bithub/

...
We’ve written and deployed a simple service called “BitHub” that does two things:

1. Accepts Bitcoin donations and allocates them into a single pool of funds.
   
   
2. Distributes the Bitcoin donations from that pool to anyone who commits to our repositories.

We’re starting with an initial “worse is better” distribution strategy: the owner of every merged pull request is paid 2% of our total balance at the time of the merge. Depending on how that works, we might adjust the payout strategy in the future, or even add features like the ability to donate for bounties on specific GitHub issues.

In order to effectively communicate the current payout for a project to developers, a BitHub instance will render the current payout amount (in USD) as an image that can be embedded in a GitHub project’s README.md (or anywhere).

For example, this is the current Open WhisperSystems payout per commit, rendered dynamically as an image by the Open WhisperSystems BitHub instance:

A project’s BitHub instance will also return JSON (or rendered HTML) of the most recent payouts. For example, these are the five most recent Open WhisperSystems payouts returned from the API:

• Sent $10.82 USD to moxie0 for 4bbaee17 2015-04-29T05:34:09+0000.
• Sent $11.04 USD to moxie0 for 5b774473 2015-04-29T03:47:20+0000.
• Sent $11.26 USD to moxie0 for 6a48c55e 2015-04-29T00:44:05+0000.

This way anyone can donate to the project, and the donations are distributed to anyone who’d like to be involved in the project.

 

[crowning]

I just came across this while researching open source private communication tools:

https://github.com/WhisperSystems/BitHub

While the details of our amazing SDGB project are still being hammered out, could the BitHub service be employed as an easy way to utilize the already in-place MN donation feature to automatically distribute money to devs whenever they contribute?

I think it's a cool idea to automatically pay developers per commit on Github, but

- this only covers developers, nothing else
- it's seriously flawed, people would develop less locally and split everything into single commits to get more Dash
- I have already more commits than gmaxwell. Still all of my commits together are most probably worth less than a single one of his.

 

[Bridgewater]

I see your point. It still requires oversight or it can easily be gamed just like any other system. Seeing this attempt makes me appreciate the elegance of the SDGB proposal even more.

 

[raganius]

It wouldn't go forward:



Agreed. And maybe it's better to start with a higher bar and see how that works out before trying anything else.



Let me try and lay out how I envision this working in pseudo code. I am not a coder, this is barebones rough draft 0.0.0.1-pre-alpha, try not to laugh too loudly.

# we start with an empty projectlist
projectlist = []

# a project is proposed, discussed, voted forward, added to the list
projectlist = [{project1}]

# the project will have some basic structure, eg:
project1
{
project1.priorityscore;
project1.initialpaymentamount, project1.initialpaymentdate;
project1.milestonepayment1amount, project1.milestonepayment1date;
project1,finalpaymentamount, project1.finalpaymentdate;
project1.paymentaddress;
}

# ... projectlist is added to as time goes on ...

# the system will allocate funds to projectx.paymentaddress as follows

for each project in projectlist:
if projextx.paymentdate (is due) and projextx.paymentamount (is possible to pay from 1 block) then pay project1.paymentaddress (due amount)
if projextx.paymentdate (is due) and projextx.paymentamount (is not possible to pay from 1 block) then keep paying projectx.paymentaddress until projectx.paymentamount is satisfied

if there is conflict or overlap between projectx and projecty payments then pay whichever has highest priority first then continue down the list

# etc.

In this way there's no need to limit the number of projects, except the practical one that there's only so much money to go around so maybe limit adding new projects beyond a certain point, because it's going to dilute the available money and delay completion of whtever is currently ongoing.

With a bit of coding the wallet could give the proposer a rundown of how long payments might be delayed (if at all) given the proposed dates/amounts based on the current project list, and maybe only add the project to the live list when prior commitments allow - have a commitment cap in other words that varies with known cost load. Projects get queued according to priority score before being added to the live list.

I think it's essential that all this happen in-wallet without any dependency on websites etc. The website should be an information portal only that reflects network state, that information must all be accessible from the wallet itself.



Eh, a strict FIFO system would be a lot simpler... but hey, that's why Evan earns the megabucks... :grin:

Great post, I am with thelonecrouton's suggestion of how things can work. Solarminer's initiative of starting a draft code is also awesome. Thanks guys!

I like this idea. No input from the developers, we just start coding it here. LOL. Let me see if I can take a crack at the wallet commands. Looks like the code on the github is C++, so I will go with that. (Note: The getline() stuff is not right, this would be better to put in a database rather than a file, missing the shebangs. This about if for my coding skills.)

Wallet Commands:
Masternode Create Project(Description, DASH, DASH Address)
Masternode Vote Project(Description, Yay/Nay)

Create a subroutine to input each project into a file with the description, funding amount needed, yay and no votes at 0, masternode count when project was created, and project priority of 0)

//Function Masternode Create Project
#include <iostream>
#include <ofstream>
masternode create project (project.description, project.funding, project.address);
masternode count >> project.mncount
projectdata.open();
projectdata << (project.description, project.funding, project.address,0, 0, project.mncount, project.priority);
projectdata.close();

Create a subroutine for voting. When vote request comes through with project.description and the vote(yay/nay), it pulls up the files with project data and outputs the line for the project. Then if it is yay it adds 1 to yay or if nay it adds 1 to nay.
If votes meet the threshold of 51% yes, it is given a project.priority = to the yay votes.
//Function Masternode Vote Project
#include <iostream>
#include <fstream>
masternode vote project (project.description, vote)
projectdata.open();
sting::find(project.destription) in projectdata
getline(with projectdata)
getline (project.description, project.funding, project.address, yay, nay, project.priority)
while (vote){
If masternoded voted before(print "Already voted ", vote)
If(vote=yay)
yay=yay+1
else if(vote=nay)
nay=nay+1
If yay > 0.51*mncount
project.priority=yay
}
projectdata << (project.description, project.funding, project,address, yay, nay, project.mncount, project.priority)
projectdata.close();

After vote ends. Run this command to list the projects that were voted in.
list projectdata | grep project.priority > 0

Then the real coding happens.
Need to add how to split priority between the remaining projects. Maybe top one gets 8%, next 5%, and last 2%.
Implement the block reward distribution to each project.
Stop block reward distribution when blockrewardssent = project.funding.

Also great this post:

I just put some numbers together so we could look at this in a rational way. Assuming DASH is $3 US and 1% is 1 out of 60 MN payments of 2.8 DASH.
1% Project would pull in $2,400/mo or $29,030/year
3% Project would pull in $7,300/mo or $87,100/year
5% Project would pull in $12,100/mo or $145,200/year
10% Project would pull in $24,200/mo or $290,300/year
15% Project would pull in $36,300/mo or $435,500/year

A programmer would be paid about 3% now. Even with a 9% cap, we could still have 3 projects with 3% funding and have a dedicated programmer working on each. Of course, in 5 years this could be 0.1% for a programmer.

My view is that 3 projects at a time is all we should be focusing at once. Each project would be a 3 month commitment. If less funding is needed than the 3 month amount, funding stops when complete and the slot is opened for another project.

Now back to fuzzyduck's comment. I don't think the projects should just get arbitrarily voted up for more %. The project owner should commit to a certain amount of funding. I just see this based on people needed (1 programmer, 1 tester) or whatever the project owner envisions. For projects paying for a service(video) than the funding % would be based on what is needed in 3 months.

That was enough to let me see things much clearer. That's the difference when you master the left side of the brain :wink: I am a slave of my brain's right side and for such details I often need such incentives.

 

[raganius]

+1
I hope eduffield is reading these posts from both angles... And if he still thinks he needs to allocate a large portion of funds to marketing... please, Evan, read the Dash sections for wallet/daemon support and guides... Even with all of the videos that were made to guide newbies there are people that still don't know where to find their wallets (even after watching one of the videos). One particular case someone spent 8 hours to find his wallet on his mac. It's not just old people, it seems a problem for any age, if they don't have the computing basic skills they don't know how to get around their computers. So definitely an easy wallet is where to start. If this coin is easy for people to understand how it works, how to use it, the natural response is more people will want to adopt this coin.

I also don't see the need for immediate funds for marketing.

DEVELOPMENT is what matters most, and I understand how important it is for us to make our Dev Team happy, and able to hire whatever specialists to help us in no matter what new important feature needed.

We speak about Research-Development-Marketing ("RDM") here.
So everybody who don't spend their money or time for RDM now - are RDM-freeriders.

I think >80% of DASH holders now are RDM-freeriders (but in Bitcoin >90% :smile and it has to be changed somehow.

After reaching 0% RDM-freeriders Dash will be 10 times more effective than Bitcoin!

Sorry, but I cannot agree with you here. This thread is about how to allow the community to make DECENTRALISED decisions, and, of course, this comprehends deciding between our options of voluntarily donating whatever we want to donate, or instead, of "compulsorily" paying money, or better, salaries, to people with (recognised) abilities directed towards important things that the COMMUNITY DECIDES AND AGREES (at least the majority) are important.

There are many "relatively" important things to be done as well as many "very" important things. The community in the end will choose the priorities.

But, IMO, MARKETING is of "relative" importance when compared to DEVELOPMENT.

Our community has been recognisedly successful in achieving relevant results based solely in the VOLUNTARY efforts of us members. It cannot be simply ignored. To say that I am a FREERIDER because I did not give money is the same to say that all the time and efforts that I have dedicated to the community were not welcome and are worth nothing. The only thing I can say is that I feel discouraged and disappointed, and I guess I am not the only one.

I would surely pay for whatever the community decides is the priority for DASH, but IF I feel that my eventual voluntary efforts that I might continue to donate are not being well received or appreciated by the community, the moment I see that my love and works were simply taken for granted, I cannot help but to stop donating. And that is sad, because I believe a P2P network is MAINLY built of love, friendship, donation... and that's why I came here, and am here.

Let's not let our vanities spoil what beautiful things we built...

Let's not give too large steps. We should start with basic and genius ideas like some of those cited above, and, with time and experience, go further.

(edit) PS: The idea that the eventual unused funds should not be paid to the Masternodes in order to avoid it "seducing" their owners into making irresponsible decisions just makes no sense as long as the proposal here is to have these decisions made by the same Masternode owners because the community believes they are responsible enough (and trustworthy as a group) to decide.

(edit2 ) Once a proposal is approved and not rejected by the voting pre-established rules, IMO the contribution towards it should be mandatory to all Masternodes (yes voters, no voters, abstainers) - instead of a Masternode paying only for the projects it voted yes. Likewise, to stop funding a running project would take a specific proposal from the community, to be voted (in case of the community not satisfied with that project's execution/results).

 

[thelonecrouton]

Raganius makes a particularly good point that further illustrates the silliness of the 'MN ops are not to be trusted with real decision making power' argument - all the regulars here, on BCT and elsewhere are already, and have always been, putting in real time and real money (same difference) in working toward our common goal.

To claim that we will all now cease our rational support because our future MN earnings might decrease by a packet of cigarettes worth a month is mystifying.

There's a lot of real and justified pride in the work done by many here, which isn't going to be aided by implementing a system that instead of empowering committed supporters with a real say in funding, instead denies them any meaningful veto.

The estimable Minotaur, with his 'I don't usually stoop to personal attacks, but in your case crouton you fugly deviant scoundrel I'm going to make a long and rambling exception!'-speech earlier on in the thread ( :tongue: ) is a good case in point. Does he think he's suddenly going to cease supporting what he believes in because his MN earnings might decrease by some paltry amount? I doubt it... and yet he thinks the rest of us will act like fools?

 

[alex-ru]

...There's a lot of real and justified pride in the work done by many here...

How do you estimate: how many people spend at least 100 hours (forum's chatting - doesn't count) (or as alternative - 1% of their DASH holdings) monthly - for Research-Development-Promotion for DASH?
- 20 People?
- 50 people?
- 100 people?

How do you estimate: what percentage of current DASHs supply do these people hold?
- 20%?
- 25%?
- 30%?

Do you think it is fair that the remaining > 70% "free riders" are consumers of their work, but don't do anything significant for Research-Development-Promotion?

I'll be honest - I have many friends that I could invite to invest in the Dash, but I won't invite them, because I know for sure - they will be 100% "free riders" - they can't and will not do anything for the project, but they will just sit and wait for growth of DASH prices.

The proposed system will allow all holders to be 100% usefull for Research-Development-Promotion of Dash - and this will be fair.

Those who are now investing their money, time and competence to the Research-Development-Promotion of the project - my respect for each of you! I am confident that they will continue to do the same, even after the introduction of the new system.

And I hope that new system will allow some of them to move to full-time employment in Dash team, to multiply the their usefulness for the project.

P.S. Just to make it clear - I estimate myself as "free rider" also. (may be not 100% though)

 

[raganius]

Alex, I can understand your point of view, and I can agree with its core idea, but let's be a little more more careful. :wink:

How do you estimate: how many people spend at least 100 hours (forum's chatting - doesn't count) (or as alternative - 1% of their DASH holdings) monthly - for Research-Development-Promotion for DASH?
- 20 People?
- 50 people?
- 100 people?

How do you estimate: what percentage of current DASHs supply do these people hold?
- 20%?
- 25%?
- 30%?

I don't see much relevance in these "estimates" as long as we are talking about voluntary work. No matter what DASH supply someone holds, if this person wants to help the community, the community is supposed to welcome this help, but if this person wants just to hold or trade, it's the person's decision and right to do that way.

Do you think it is fair that the remaining > 70% "free riders" are consumers of their work, but don't do anything significant for Research-Development-Promotion?

I'll be honest - I have many friends that I could invite to invest in the Dash, but I won't invite them, because I know for sure - they will be 100% "free riders" - they can't and will not do anything for the project, but they will just sit and wait for growth of DASH prices.

This is no measure of fairness. We WANT AND NEED these "consumers" that's what it is all about. DASH is money, and money depends on acceptance. We cannot try to force our potential users into a careless TAXATION scheme. It simply makes no sense at all... actually, it's dangerous. Are we intending to create difficulties to the access to DASH, instead of facilitating it?

It doesn't matter if the users benefit from DASH's evolution without paying TAXES. DASH is already supposed to evolute, that's this evolution and efficiency that will bring more and more necessary users. And if DASH doesn't improve the USERS will simply go elsewhere.

If people are investing in DASH, if people are BUYING DASH, exchanging their fiat paper into this real money, that's already good enough.

The proposed system will allow all holders to be 100% usefull for Research-Development-Promotion of Dash - and this will be fair.

What is fair for one person not necessarily is fair for someone else. If, to use DASH, one needs to submit to paying the salaries to some unknown marketeer, then this person surely will prefer migrating to monero, animecoin, bitcoin, etc, where there are no socialist fairness worries...

Those who are now investing their money, time and competence to the Research-Development-Promotion of the project - my respect for each of you! I am confident that they will continue to do the same, even after the introduction of the new system.

And I hope that new system will allow some of them to move to full-time employment in Dash team, to multiply the their usefulness for the project.

Sure, DASH needs a strong development team. Sure, DASH needs many implementations and services to be provided to it in order to make it the perfect money. I agree with all that. IF the community chooses to pay salaries to one or another worker, great, as long as it is considered necessary for the benefit of all, let's vote and do it. No one is against this here as I understood it. BUT let's be careful to not turn it all into a socialist welfare... no one wants to create another Featherbedding to the world.

P.S. Just to make it clear - I estimate myself as "free rider" also.

No, you are not a freerider, because I've seem lot's of contributions to the community from yourself, and you surely love DASH and I know that you have the best intentions towards our community. The fact that you are here now, exchanging ideas is already enough evidence of your not being freerider at all :smile:

 

[alex-ru]

... And if DASH doesn't improve the USERS will simply go elsewhere.
If people are investing in DASH, if people are BUYING DASH, exchanging their fiat paper into this real money, that's already good enough...

I urge everyone to think not only about users, but also about the developers.
If all of our developers tomorrow will leave "Satoshi Nakamoto"-style: "OK, we've already done so much, we have a lot of coins, and other things to do - you proceed by yourself..." (and well if they do not go to make competitor project).

A balanced system should make happy and interested not only users (as not only miners, etc.), but all participants of the system. IMHO

 

[Minotaur]

- There is no tax. All the funds belong initially to the network and it distributes them depending on what it needs. A lot of what I have read in this thread revolves around this fundamental difference. Whatever portion of funds are allocated to development belong to this separate category and would go to the development of the ecosystem. Is just a different model.

- In the original proposal from the OP masternode operators are compensated with 45% of the reward, those are the funds that belong to us masternode operators and we are free to do anything with our portion of the rewards. Just like miners are free to do anything with their portion of the rewards.

- Most importantly emission and inflation are the same, so no matter how you look at it, for the end user it is better with the new model. The emission will hit the market no matter what, for the end users it is better if a portion of that is dedicated to the development and promotion of the system. This is what makes this model so powerful that it does not mess with emission and inflation, only uses it in a smarter way, just like we did when masternodes were added.

- It is easy to confuse the role we have as masternode operators in the development portion, the only reason we as masternode operators are involved in the process, is because we form an assembly of stake holders that can decide together how the development and promotion funds are invested. Similar to the way a board of shareholders can decide how a company invests its funds, it does not mean that the company's funds belong to the shareholders, they actually don't.

-An initiative like this is crucial for any coin that wants to be successful in today's market. Most of the big projects now are well funded or private. Dash does not get the benefit of receiving MIT private funds, that is why a better system is needed that makes our blockchain self sustainable.

- I think this will represent a huge competitive advantage for Dash. About the mechanics, I am curious to see how Evan will implement it, as I am sure there are technical limitations as to what is possible to do. Whatever the implementation conceptually this is huge for Dash.

 

[deusstultus]

Can we not jump the gun here arbitrarily defining quotas for this? It really defeats the point of even implementing the voting system...
With some fixes to the multisig implementation, you have a clean masternode supported donations channel, this should be the avenue utilized for funding at the moment at masternode operator discretion. I wouldn't be opposed to a default "donation" imposed in the client either so long as the change was rolled out transparently.

This needs to be phased and not alienate anyone here. You guys have made a lot of off-the-cuff decisions and it's made adoption a whole lot rockier than it could be. We're over a year in at this point and need to settle out on protocol level changes... I'd propose something more in the way of the following:

1) Avoid making changes to the block templates, mining is still essential to this coins operation and breaking miner configurations or incentives should be avoided until a suitable alternative is provisioned for.
2) Create defined oversight and exhibit the system before channeling funding towards it. The voting mechanism should even be an integral part in making changes of this nature. No one 's expected rewards whether through mining or masternode operation should be arbitrarily changed, and there should be no expectation of constant funding to anyone involved on this project from the consumers.
3) Tune-up masternode multisig donations and create/update multisig addresses to provide for the claimed functionality:

a) Foundation should have an address anyone can contribute to. This is to facilitate the project, handling legal aspects, etc. This is to be a blanket account which would allow for discretionary spending or project allocation as necessary even on the same system indicated in OP.
b) Core Team should have an address anyone can contribute to for discretionary spending. Transparency of course expected, and likely require surpluses released back to foundation per charter.
c) Masternode network should ultimately be responsible for signing on the proposals without funds being arbitrarily distributed for future allocation. Here I propose some changes to the POSE system to allow for voting mechanisms to have expectations of actualization.​

4) Alter the current POSE system to have more reaching potential. Currently it's just an isMisbehaving boolean with enough gray area to account for network anomalies. This could be rebuffed into something much grander, including a decentralized solution for the current roundrobin masternode payment modeling. Ultimately, for voting to be effective, we need a proof of trust model and this addresses both. Ideally, masternode network would also have the capability of generating multisig payments and established trust is needed to reasonably expect masternodes to sign in a timely manner enabling a truer form of network managed escrow. Expectation is this run on mainnet for some time after sufficient testnet time without influencing payouts before being enforced, with provisions to reset pose counters before enforcement would begin.

a) Create a secondary counter and define scope on POSE, defaulting to some value, say 2048 (arbitrary so as to be large enough to allow reduction and alternative use cases without a specification change in the future and happens to approximate current masternode count. For each block, masternodes perform their network checkout and behaving active nodes get this counter incremented while misbehaving nodes are given the 6-stage buffer zone before being penalized on their payout counter unless an action of malintent demands punishment. The masternode with the highest established pose score is the one to get paid (or random amongst top list to reduce targeted attacks) after declaring eligibility (see 'b'). Payout results in a reasonable decrementation in the counter, likely based on current masternode count with pose above default.
b) Instead of project funding allocation within block template, require a masternode to have locked a transaction for such purposes in InstantX style with extensions to length of lock per this use case. Here this becomes a secondary proof of service functionality and allows the masternode operator to directly select the project she intends to fund. This transaction must include the latest generated coinbase sent to the masternode if available. New masternodes or those who have spent latest payout would be allowed to generate this transaction from other coins supplied to the masternode operating address, effectively increasing masternode creation to 1001 coins in two separate transactions. Using alternative coins would come with an increased decrementation on payout as it reduces tracability. Upon validation of a project for funding, the network would expect payment from each pledger based on votes from their locked coinbases and approve such transactions only against the target address. If payment is not remitted by a pledger within a reasonable duration, masternode is penalized by not being permitted pose incrementation. This is now an escrow mode without requiring releasing funds to a
c) Masternode operators would be permitted an opt-out case in which these funds would be redistributed to masternode operators and miners by publishing coins to darksend with an increased fee schedule. This introduces a constant stream of virgin coins to darksend and the heightened fees on the masternode operator would increase block payouts. Forces masternode operators to support the network without demanding they pay for a project.
​

This is over-idealized in some regards and incredibly incomplete. Predominantly designed to seed conversation on alternatives with more fluidity and transparency while reducing alienation threat present in Evan's proposed fee schedule adjustment.

 

[TaoOfSatoshi]

Can we not jump the gun here arbitrarily defining quotas for this? It really defeats the point of even implementing the voting system...
With some fixes to the multisig implementation, you have a clean masternode supported donations channel, this should be the avenue utilized for funding at the moment at masternode operator discretion. I wouldn't be opposed to a default "donation" imposed in the client either so long as the change was rolled out transparently.

This needs to be phased and not alienate anyone here. You guys have made a lot of off-the-cuff decisions and it's made adoption a whole lot rockier than it could be. We're over a year in at this point and need to settle out on protocol level changes... I'd propose something more in the way of the following:

1) Avoid making changes to the block templates, mining is still essential to this coins operation and breaking miner configurations or incentives should be avoided until a suitable alternative is provisioned for.
2) Create defined oversight and exhibit the system before channeling funding towards it. The voting mechanism should even be an integral part in making changes of this nature. No one 's expected rewards whether through mining or masternode operation should be arbitrarily changed, and there should be no expectation of constant funding to anyone involved on this project from the consumers.
3) Tune-up masternode multisig donations and create/update multisig addresses to provide for the claimed functionality:

a) Foundation should have an address anyone can contribute to. This is to facilitate the project, handling legal aspects, etc. This is to be a blanket account which would allow for discretionary spending or project allocation as necessary even on the same system indicated in OP.
b) Core Team should have an address anyone can contribute to for discretionary spending. Transparency of course expected, and likely require surpluses released back to foundation per charter.
c) Masternode network should ultimately be responsible for signing on the proposals without funds being arbitrarily distributed for future allocation. Here I propose some changes to the POSE system to allow for voting mechanisms to have expectations of actualization.​

4) Alter the current POSE system to have more reaching potential. Currently it's just an isMisbehaving boolean with enough gray area to account for network anomalies. This could be rebuffed into something much grander, including a decentralized solution for the current roundrobin masternode payment modeling. Ultimately, for voting to be effective, we need a proof of trust model and this addresses both. Ideally, masternode network would also have the capability of generating multisig payments and established trust is needed to reasonably expect masternodes to sign in a timely manner enabling a truer form of network managed escrow. Expectation is this run on mainnet for some time after sufficient testnet time without influencing payouts before being enforced, with provisions to reset pose counters before enforcement would begin.

a) Create a secondary counter and define scope on POSE, defaulting to some value, say 2048 (arbitrary so as to be large enough to allow reduction and alternative use cases without a specification change in the future and happens to approximate current masternode count. For each block, masternodes perform their network checkout and behaving active nodes get this counter incremented while misbehaving nodes are given the 6-stage buffer zone before being penalized on their payout counter unless an action of malintent demands punishment. The masternode with the highest established pose score is the one to get paid (or random amongst top list to reduce targeted attacks) after declaring eligibility (see 'b'). Payout results in a reasonable decrementation in the counter, likely based on current masternode count with pose above default.
b) Instead of project funding allocation within block template, require a masternode to have locked a transaction for such purposes in InstantX style with extensions to length of lock per this use case. Here this becomes a secondary proof of service functionality and allows the masternode operator to directly select the project she intends to fund. This transaction must include the latest generated coinbase sent to the masternode if available. New masternodes or those who have spent latest payout would be allowed to generate this transaction from other coins supplied to the masternode operating address, effectively increasing masternode creation to 1001 coins in two separate transactions. Using alternative coins would come with an increased decrementation on payout as it reduces tracability. Upon validation of a project for funding, the network would expect payment from each pledger based on votes from their locked coinbases and approve such transactions only against the target address. If payment is not remitted by a pledger within a reasonable duration, masternode is penalized by not being permitted pose incrementation. This is now an escrow mode without requiring releasing funds to a
c) Masternode operators would be permitted an opt-out case in which these funds would be redistributed to masternode operators and miners by publishing coins to darksend with an increased fee schedule. This introduces a constant stream of virgin coins to darksend and the heightened fees on the masternode operator would increase block payouts. Forces masternode operators to support the network without demanding they pay for a project.
​

This is over-idealized in some regards and incredibly incomplete. Predominantly designed to seed conversation on alternatives with more fluidity and transparency while reducing alienation threat present in Evan's proposed fee schedule adjustment.

Some interesting ideas there... Nice post!

 

[Solarminer]

Rereading Evan 'Almighty's' original post, I am finding some really good quotes.

• Donation Only = Unfair to donators since they pay for development and non-donators enjoy the rewards from development.

This makes sense. All of us will benefit from a development project and should pay the same.

• 100% decentralized system powered by masternodes. (no vote proxies, foundation input, etc.)

Genius. This is where the real power of the proposal lies.

• There are two conflicting statements "Paid from the blockchain" and "Portion above 45% would be held in escrow"

This is confusing. I believe the missing link here is that the funds are stored in an escrow account(multisig wallet), but the funds are only released with a blockchain voting mechanism. (There would not need to be an escrow account if the funds were paid directly from the blockchain.)

• Budget will be calculated in real time after a masternode updates their vote....masternode owners could change their vote and remove funding immediately.

I am still trying to figure out how this could work. If a project is approved, then paid, but then votes are changed, how does funding get returned.

• If there is money left over in the budget, the system will also support proposals for moving money into a "savings" account.

This sounds good. I like the idea of not funding non-value projects and saving the money. At some point as DASH increases in value and the projects will get less valuable and savings will grow. Does the savings get returned to the masternodes? If it does, then the escrow account/budget/manager is way to complicated.

So lets start with the options:
Voluntary Donation Model. (what we have now)
This gives each masternode individual ability to fund anything they want. Masternodes don't have to pay if they don't want. This is the same as saying send funding to this address. This is also the same as allow a yes/no vote, but only the yes votes pay. The problem here is that the masternodes that don't pay get a free ride. It also doesn't guarantee any level of funding, and we would be left with 20 projects that are partially funded.

The 15% Mandatory Donation Model
This model takes 15% from the blocks rewards and puts it into an escrow fund or budget for projects. There is not a way to return the 15% taken, and if there is, it changes the model to the one below. This is a dangerous model, it forces donations, but does not encourage quality work or valuable projects. Since there is no mechanism to defund contributions, eventually, this system will fail.

The Vote per Project Donation Model - I believe this is the only model that will work long term.
Once votes meet the minimum yes%(51% or 66%) each project gets approved, up to the 15% maximum cap.
All masternodes pay in for approved projects. There are no free riders, and not all masternodes have to vote to approve a project.
There is no escrow account, payments come from block rewards(or x payments our of 60 blocks)
Each project is submitted with a desired % of block rewards for a 3 month period. Each project is voted on based on the value of that % over 3 months.
An alternative would be to have each project get 15% and highest priority start first, and rotate to the second project when first is fully funded.
Another alternative is to add an escrow account. All 15% of the funds go to the escrow account, is prioritized in a budget, and what is not used is returned to the masternodes at the end of the year. There is still no additional incentive for masternodes to vote for a project. And the additional problems and maintenance with an escrow account will be a big problem in the future(Think $millions target).

Can we agree to eliminate the Voluntary Donation Model and the 15% Mandatory Donation Model? Then we can move on to refining a Vote per Project Donation Model that makes the most sense.

 

[Solarminer]

Deusstultus, now that I have laid out the options, I will attempt to respond to your post.

Can we not jump the gun here arbitrarily defining quotas for this? It really defeats the point of even implementing the voting system...
With some fixes to the multisig implementation, you have a clean masternode supported donations channel, this should be the avenue utilized for funding at the moment at masternode operator discretion. I wouldn't be opposed to a default "donation" imposed in the client either so long as the change was rolled out transparently.

There are a few ideas that sound good, but I don't see them working well. Multisig wallets require a lot of technology to make them work right. Controlling of sending donations to specific projects, while maintaining voting control, without delays. I see this as being very difficult and not "clean". A default donation would make this worse.

This needs to be phased and not alienate anyone here. You guys have made a lot of off-the-cuff decisions and it's made adoption a whole lot rockier than it could be. We're over a year in at this point and need to settle out on protocol level changes... I'd propose something more in the way of the following:
1) Avoid making changes to the block templates, mining is still essential to this coins operation and breaking miner configurations or incentives should be avoided until a suitable alternative is provisioned for.

Yes! There is already a block reward change in place that will phase out 15% of mining rewards a little each month and shift them to masternodes. We can work with this to implement the next alternative.

2) Create defined oversight and exhibit the system before channeling funding towards it. The voting mechanism should even be an integral part in making changes of this nature. No one 's expected rewards whether through mining or masternode operation should be arbitrarily changed, and there should be no expectation of constant funding to anyone involved on this project from the consumers.

The masternodes will be the ones voting so only their block rewards should change. They are the ones responsible to make the decision if a project has value. Miners don't have a say so their rewards should stay the same.

3) Tune-up masternode multisig donations and create/update multisig addresses to provide for the claimed functionality:

a) Foundation should have an address anyone can contribute to. This is to facilitate the project, handling legal aspects, etc. This is to be a blanket account which would allow for discretionary spending or project allocation as necessary even on the same system indicated in OP.
b) Core Team should have an address anyone can contribute to for discretionary spending. Transparency of course expected, and likely require surpluses released back to foundation per charter.
c) Masternode network should ultimately be responsible for signing on the proposals without funds being arbitrarily distributed for future allocation. Here I propose some changes to the POSE system to allow for voting mechanisms to have expectations of actualization.​

A blanket foundation account will cause problems. Not only will become an easy target for theft/tax/confiscation from outside, but it will complicate how projects are paid. Who has access to the account, a list of foundation members. If one of the those members is associated with something illegal(whether it is or isn't) the entire fund could be confiscated. Plus there would be the extra expenses for managing and budgeting to make all this work. As for the masternodes voting, this ends up with a vote every week to make sure the budgets are paid.

4) Alter the current POSE system to have more reaching potential. Currently it's just an isMisbehaving boolean with enough gray area to account for network anomalies. This could be rebuffed into something much grander, including a decentralized solution for the current roundrobin masternode payment modeling. Ultimately, for voting to be effective, we need a proof of trust model and this addresses both. Ideally, masternode network would also have the capability of generating multisig payments and established trust is needed to reasonably expect masternodes to sign in a timely manner enabling a truer form of network managed escrow. Expectation is this run on mainnet for some time after sufficient testnet time without influencing payouts before being enforced,
with provisions to reset pose counters before enforcement would begin.

Adding the multisig capability to the masternode donations is useful. Maybe this will be one of the first projects - to get this fixed.

a) Create a secondary counter and define scope on POSE, defaulting to some value, say 2048 (arbitrary so as to be large enough to allow reduction and alternative use cases without a specification change in the future and happens to approximate current masternode count. For each block, masternodes perform their network checkout and behaving active nodes get this counter incremented while misbehaving nodes are given the 6-stage buffer zone before being penalized on their payout counter unless an action of malintent demands punishment. The masternode with the highest established pose score is the one to get paid (or random amongst top list to reduce targeted attacks) after declaring eligibility (see 'b'). Payout results in a reasonable decrementation in the counter, likely based on current masternode count with pose above default.
​

I believe Evan has already stated that the order for masternode payments will be saved, so there isn't a reset like we have had on the last updates. There is already a mechanism in place when the score goes above 6 the node will get delisted.

b) Instead of project funding allocation within block template, require a masternode to have locked a transaction for such purposes in InstantX style with extensions to length of lock per this use case. Here this becomes a secondary proof of service functionality and allows the masternode operator to directly select the project she intends to fund. This transaction must include the latest generated coinbase sent to the masternode if available. New masternodes or those who have spent latest payout would be allowed to generate this transaction from other coins supplied to the masternode operating address, effectively increasing masternode creation to 1001 coins in two separate transactions. Using alternative coins would come with an increased decrementation on payout as it reduces tracability. Upon validation of a project for funding, the network would expect payment from each pledger based on votes from their locked coinbases and approve such transactions only against the target address. If payment is not remitted by a pledger within a reasonable duration, masternode is penalized by not being permitted pose incrementation. This is now an escrow mode without requiring releasing funds to a

Implementing InstantX to control the block rewards for each project might work. I just see this as using 1-15 out of every 60 masternode block reward payments going to projects depending on 1-15% payments. Also the idea that there are pledgers and non pledgers is not acceptable, the non-pledger can freeload. There is no need for a voting mechanism, if you just want a donation model. See above for details. All masternodes must pay the same and only when a project has value, which is determined by a majority vote.

c) Masternode operators would be permitted an opt-out case in which these funds would be redistributed to masternode operators and miners by publishing coins to darksend with an increased fee schedule. This introduces a constant stream of virgin coins to darksend and the heightened fees on the masternode operator would increase block payouts. Forces masternode operators to support the network without demanding they pay for a project.

No! If a project is voted in, it must not allow for an opt out by a few masternodes that can freeload. If a project is not valued, the majority of masternodes don't vote for it and no masternodes pay. This way all masternodes pay for a valued voted in project that will benefit them all. I don't understand why darksend would be included in the voting/donation process.
​

This is over-idealized in some regards and incredibly incomplete. Predominantly designed to seed conversation on alternatives with more fluidity and transparency while reducing alienation threat present in Evan's proposed fee schedule adjustment.

I probably misinterpreted some of your statements here. Feel free to clarify anything I missed.