Self-sustainable Decentralized Governance by Blockchain

[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% ) 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.

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

 

[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.

 

[Solarminer]

- 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.

This point keeps coming up and I would like to address it. Is the 15% donation a tax?

• If the 15% Donation amount is taken from miners or masternodes and is not able to be returned to miners/MN by a veto vote or no projects vote in, then this is a tax.
• If the 15% Donation can be returned to miners/MNs by a veto vote or no projects voted in, then it is a donation or a loan if returned.

Who loses, when these funds are taken from the 'network' assuming the 40% mining/45% MN/15% Donation split?

• This 15% is taken from miners(if implement now)
  
• The 15% is taken from masternodes(if implemented after 3/2016 when the expected MN block rewards are expected to be maxed out at 60% and mining rewards reduce to 40%).
• The 15% is also a tax on the network too. It will either lower the mining hashrate(less coin security) or lower masternode count(less transaction/darksend speed and less investment).

If this was a brand new coin, and the 15% was taken at the start of the coin, sure, I would say this is a network owned block reward %. Since 100% of the block rewards are getting distributed now with DASH, taking 15% out of the ecosystem isn't a network owned asset anymore.

 

[thelonecrouton]

- 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.

The proposed model is very plainly a tax.

Forced development of the 'ecosystem' is doomed. Any ecosystem needs to be independently viable without continuous enforced-charity cash injections from the infrastructure providers. Core money funding core development is fine if that's what people want, but core money funding 3rd party enterprises is not.

 

[alex-ru]

If this was a brand new coin, and the 15% was taken at the start of the coin, sure, I would say this is a network owned block reward %. Since 100% of the block rewards are getting distributed now with DASH, taking 15% out of the ecosystem isn't a network owned asset anymore.

1. Tax - is when system takes away something that you own. New model won't take away any coins people already own.
2. Or hidden tax - is when additional money is issuing (tax through inflation). New model won't issue any additional inflationary coins.

So it is not about taxation - it is all only about distribution of new (planned) coins (amount exactly was planned to be issued anyway). It is just a changing distribution model.

Previously DASH distribution model was already changed 1 time (miners started to receive less than 100%, not because of "MN taxation" - but because system changed distribution model for more efficient and viable model.) First time - this change was dictated by developers.

Now it is time to change distribution model in second time. Now - this change isn't dictated by developers. Now System (but not you, I, Evan, ...) will vote if it is needed a change to new distribution model. So it is much more democratic and I hope more effective.

MN (but not miners or all users) will vote for this just because they are more stable and most interested in Dash's success - to make right decision. It doesn't mean that they (or miners, or ...) "own all future issuing coins, so new model is a taxation".

Only System itself own all new coins and can decide how to distribute them more effectively - for the whole System to survive. IMHO.

Bitcoin has fixed distribution model "forward 100% - to protection".
DASH can be more clever, flexible and development oriented - this is a base for our long-term excellence.

 

[Solarminer]

1. Tax - is when system takes away something that you own. New model won't take away any coins people already own.
2. Or hidden tax - is when additional money is issuing (tax through inflation). New model won't issue any additional inflationary coins.
So it is not about taxation.

Incorrect. There is a 'contract' in place to pay miners 55% of the block rewards now. See page 1 of the ANN DASH thread for details. Take away %15 and that is a tax.

By your assesment, paying an income tax is not a tax because it only takes away from future income.

 

[raganius]

- 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.
(...)

Minotaur, I am aware of the importance of the solutions that our community needs. Your great post "Dash: Filling the gaps..." is enough to show how fragile DASH can be without a proper and solid paying for its core developers. As you have said there: "Masternode voted funding could be a great way to ensure the long term viability of the project, pay core developers, etc.". And no one can deny it is really an important issue.

What worries most, as I see it, is not if the proposed solution is or isn't a tax (I, for example, could agree to pay a tax if it is considered necessary). The focus is: How safe it is, in the long run, to create a Pork Barrel (as it's been named here)? How will it be controlled? Who will be taking care of it? What if these accumulated funds become a target for thugs, governments and the like?

We are here today, we TRUST you, we TRUST each other... but others will arrive... If we build a fragile system, these others might find the opportunity to take advantage from it. Will our solution be based on TRUST?

Directing money to development, research, marketing, legal issues, foundation, etc, I agree, are indeed important. But do we really have to create a fund/escrow/budgeting/savings account/etc... accumulated money, instead of block rewards?

Miners receive block rewards from their work, and only while they work. If a miner is not serving the network there's no accumulation, no "miners pork barrel". The same with Masternodes, they receive block rewards from their work, and only while they work. If a Masternode is not serving the network there's no accumulation, no "MN pork barrel". Why can't we simply direct block rewards to this "third category" as they work and only while they work? Why not pay a developer directly in his address from newly mined blocks during the period he's serving the community according to a voted proposal, without the need to a previous accumulation of money?

There will be a sensible solution. I believe we are nearly there, after all, we already have the necessary tools.

 

[deusstultus]

Solarminer Some snippets:

I was not really endorsing long term use of donation metrric, more a "don't shift radically to solve something that could be similarly implemented with less breakage." This methodology could be implemented without the hardfork inherent in the 15% add. Same for the foundation really, assuming a level of community trust in the foundation allows go ahead on community voted objectives before the masternode voting model could be reasonably backed in qualified code, allowing for quicker rollout of a voting method with pillars of community being relied upon to enact decisions with reasonable confidence. Not by any means a long term solution and certainly not without risk. That said, a living legal entity charged with enforcing such decisions is a boon given the current sociopolitical societal state, much of the reason the Bitcoin Foundation and comparable entities exist.

As for my implementation notes, a lot of this was thoughts I'd been tooling with regarding a "Kickstarter" type engine before seeing this post so I ran off some ideas, some of which I'd surely scrub tomorrow in looking at again as this was a fresh venture on my part. I do feel my "opt-out" case to be viable, if not necessary, however. I thought of this after pushing out the earlier ideas and tagged it in post rather than detailing as I probably should have. If the goal here is to support the network, each masternode could reasonably be expected to contribute a level of service, but need not commit to projects they do not see merit in despite differing opinions in the community. With a voting system, we're very black/white on fund/not. My thoughts allow blockchain driven prioritization of activities as well. If only 10 masternodes out of 2500 opt to fund a project consistently, it would be inherently lower in priority than one funded by 1000 / 2500 masternodes, even if the votes stood at 2000/2500 saying "should implement" for both.

Not to mention the fact that this permits anyone to fund any campaigns anonymously from darksend funds, furthering the reaching project goals, while promoting the coin directly. I'll stew on some more thoughts over the next day or two, take the time to actually read this thread in full and bounce back a more thought out implementation on this track in the week. Again, I'm more for network stability and limiting hard forks which adding template elements encourages. This coin has historically been willing to adapt to these forks and was a decent part in its inception, but it's not something that should continue to happen long term. We need a fair amount of thought and QA effort on mainnet put in before such elements become live and I'm simply trying to seed ideas for alternative paths to make this work smoothly as I don't have much opportunity to code it out myself at present.

 

[alex-ru]

Directing money to development, research, marketing, legal issues, foundation, etc, I agree, are indeed important. But do we really have to create a fund/escrow/budgeting/savings account/etc... accumulated money, instead of block rewards?

Miners receive block rewards from their work, and only while they work. If a miner is not serving the network there's no accumulation, no "miners pork barrel". The same with Masternodes, they receive block rewards from their work, and only while they work. If a Masternode is not serving the network there's no accumulation, no "MN pork barrel". Why can't we simply direct block rewards to this "third category" as they work and only while they work? Why not pay a developer directly in his address from newly mined blocks during the period he's serving the community according to a voted proposal, without the need to a previous accumulation of money?

There will be a sensible solution. I believe we are nearly there, after all, we already have the necessary tools.

I believe that for Research, Developing and Marketing (RDM) DASH needs exactly! "accumulated funds", because of "offline"-nature of this part of System.
With "digital world" you can easily switching on and off, scale the level, necessary part of "source" and so on...
Scaling works with Mining, MNoding, but it wouldn't work for offline-work like RDM.

We can't switch on and off additional developers several times a day, we can't pay for promotion videos on "pay-per-click, pay-per-view models". We have to "pay-per-create", pay a whole amount at once (sometime even in advance), and then use result "for free" for a long period. This is not bad, this is a feature.

Imagine you need to create a new house, and you are ready to pay for this task let's say "1.000$ per month". We have no banking-mortgage in crypto so best idea is not start build from day one, but first accumulate at least 10.000-50.000$ for this task.
Another example - I have small source of water, but I want to swim in a swimming pool - I have to wait until necessary amount will have accumulated...
Same with RDM and many other non-digital projects.

We need to be less "theoretical", but more "practical" with RDM.
One good thing - we can change (same way - by MN voting) way of spending RDM-funds (or even distribution model) it a future to make it even more effective (or correct errors). So there is no need to argue about it now, "theoretically" - we can go more practical and then to correct actual practical results).

Sorry - it's hard to me to explain it in English clear - sorry.

 

[Solarminer]

Solarminer With a voting system, we're very black/white on fund/not. My thoughts allow blockchain driven prioritization of activities as well. If only 10 masternodes out of 2500 opt to fund a project consistently, it would be inherently lower in priority than one funded by 1000 / 2500 masternodes, even if the votes stood at 2000/2500 saying "should implement" for both.

We want a voting system so that projects can be prioritized and funded sufficiently. Your suggesting a voluntary donation model - no minimum masternode agreement %, and a floating funding amount. There is no need for a voting system with this model, just a donation address.

The voting model allows a majority of masternodes(51% yes vote) to decide what projects have value. Those projects get funded from all the masternodes(no masternodes get a free ride). The % will vary by project could be 10% or .1%(any %) depending on project. The total funding % will be determined by the projects that are voted in. The projects with the highest yes votes(above the 51%) will go first. We have been talking about a 15% maximum for all projects, but this could start at 5% or something, although I don't see this as necessary.

 

[Solarminer]

I believe that for Research, Developing and Marketing (RDM) DASH needs exactly! "accumulated funds", because of "offline"-nature of this part of System.
With "digital world" you can easily switching on and off, scale the level, necessary part of "source" and so on...
Scaling works with Mining, MNoding, but it wouldn't work for offline-work like RDM.

We can't switch on and off additional developers several times a day, we can't pay for promotion videos on "pay-per-click, pay-per-view models". We have to "pay-per-create", pay a whole amount at once (sometime even in advance), and then use result "for free" for a long period. This is not bad, this is a feature.

There are a few ways to make what you are talking about work.

$1000 project for video.

• We can negotiate and say that we only pay when the video is complete.(ideal) Project owner collects block rewards and pays when video is complete.
  
• We can work with a project owner who is trustworthy and have them fund the project, in return for the block rewards over 3 months. Maybe they get a fee to front the funds upfront.
• The project owner collects the block rewards until there are enough funds to pay for the project.

Alternatively, if you are thinking that a slush fund for all projects will be faster, we would still have to wait until enough funds have accumulated to pay for a project. A combined project fund is only more complicated to manage priorities and access to the account.

I do see that a project for certain RDM funds could work. Maybe used for several smaller items, but this would need to be clearly defined so it wasn't just an open checkbook project.

 

[raganius]

So, the problem "justifying" a "pork barrel" would be, according to this reasoning:

(...) We have no banking-mortgage in crypto so best idea is not start build from day one, but first accumulate (...)

I should propose: instead of creating an "accumulation" which could eventually reveal itself to be a "weakness", we should better create a parallel system of "cooperative P2P loans" specific for approved DASH projects.

On such system (perhaps built on top of the Masternode network), voted-approved DASH projects which demand the dreaded "payments in advance" would be funded by lenders which will later receive their invested monies plus interest directly from future block rewards. So, in this case, the DASH network would act as a "borrower" when approved projects demand so.
This would avoid the problem of TRUST as we would no longer have a "pork barrel".

It's an example from the many possible solutions: in this case, a trustless independent parallel system, not endangering DASH directly. No bag of money to be targeted. Anyone could be a "lender/investor", even anonymously through Darksend. The interest rates could be adjusted by network consensus (voting, or better yet, by "market forces").

In the more "practical" world, not always the easiest solutions are the best, long term wise

 

[deusstultus]

I should propose: instead of creating an "accumulation" which could eventually reveal itself to be a "weakness", we should better create a parallel system of "cooperative P2P loans" specific for approved DASH projects.

This was exactly my thought with the mention of considering use of transaction locks held by masternodes who receive the coinbase tx. With proper implementation, these become held to a function and burned if not appropriated according to masternode voting, or with some tweaks to darksend allow these coins to circulate constantly while preserving UTXO locks on their outputs preventing their use except in mixing. This does create more meta-traffic, but otherwise seems theoretically viable. I am wary of using long-term multisig across the network as masternodes need not have expectation of lasting forever, and pooling to some owned fund is unacceptable.

I'd still rather not see forcing 3 outputs (miner, masternode, fund) in the coinbase if we can restrict this to 2 (miner,masternode) and worry about the routing of some percentage of masternode earnings by locking the masternode coinbase transaction, forcing it to go through darkmix, where as long as some percentage of the darkmix output goes back to the masternode address, the transaction is approved and his share of payment is securely in a personal wallet secured by darkmix tracing. The UTXOs at the masternode then again held in lock for some period for funding. If the protocol breaks or something, these coins have no risk of being burned as the transaction lock can be removed.

 

[stan.distortion]

Oops, not been keeping up and nearly missed this. Hats off, yet another "OMFG" inducing moment 30 pages to catch up on and this has probably been suggested already, building from or integrating with Liquid Feedback could maybe save some work:
http://liquidfeedback.org/

 

[Solarminer]

I would like to keep the voting/project funding discussion separate from the P2P lending. Lending is risky, and that risk should not be forced on Masternodes or the network. There would likely be an interest charge for lending which would be determined by the lender/borrower. All this is not directly related DASH and already exists. Check out:
Bitcoin P2P
www.btcjam.com
www.bitbond.com
$ P2P
www.prosper.com
www.lendingclub.com

Lending for certain projects that need upfront funding can be managed by the project owner. Most of the projects will be based on man hours anyway and block reward payouts would be ideal.

Storing coins in the blockchain with certain limitations on release and mingling with darksend coins sounds complicated. I would rather focus on the system of authorizing and distributing the funds directly to a project owner with some responsiblity than a complicated way of storing and lending funds.

 

[stan.distortion]

Only about 10 pages through so far and its hard going, not because the discussion isn't interesting, it is, but because I've been going over something remarkably similar (yet entirely different) for the last couple of years and so far only a few posts have come anywhere close to the bigger picture.

We're not the only ones looking at this kind of thing, democracy as a whole is about to get a much needed kick in the arse, many much needed kicks in the arse from many different directions and Dash has a huge advantage over most of them. Identity is the missing link for the most part and its not relevant here, a masternode is a masternode is a masternode and there's no room for gaming the system, its put up the coin or gtfo. That has the potential to add an extra layer that most other cases don't even know they're missing, folks like the Pirate Party are having incredible success with systems like Liquid Feedback and that's getting huge amounts of discrete attention but the identity hump, speaking for anyone and everyone equally and fairly has to be got over before they can even consider anything like transparent and democratic accounting and Dash has the potential to be there ready and waiting when they do.

So, imho... integration or cross-compatibility with similar systems that are shaking things up elsewhere would be a killer feature, verifiable shared masternode funding would allow way more participation and getting a test platform up and running asap (maybe an existing platform and signed messages initially) would allow much more efficient discussion (ie, for now I can assign whatever voting power I have to TaoOfSatoshi and get back to hitting things with hammers). Things like assigning percentages and proposing projects could be resolved far more effectively than via pages and pages of random and undirected discussion. Not that I don't like the discussion, as discussions go this forums loaded with good'ns but none of them have a hard and fast percentage of agreement.

 

[Solarminer]

Only about 10 pages through so far and its hard going, not because the discussion isn't interesting, it is, but because I've been going over something remarkably similar (yet entirely different) for the last couple of years and so far only a few posts have come anywhere close to the bigger picture.

We're not the only ones looking at this kind of thing, democracy as a whole is about to get a much needed kick in the arse, many much needed kicks in the arse from many different directions and Dash has a huge advantage over most of them. Identity is the missing link for the most part and its not relevant here, a masternode is a masternode is a masternode and there's no room for gaming the system, its put up the coin or gtfo. That has the potential to add an extra layer that most other cases don't even know they're missing, folks like the Pirate Party are having incredible success with systems like Liquid Feedback and that's getting huge amounts of discrete attention but the identity hump, speaking for anyone and everyone equally and fairly has to be got over before they can even consider anything like transparent and democratic accounting and Dash has the potential to be there ready and waiting when they do.

So, imho... integration or cross-compatibility with similar systems that are shaking things up elsewhere would be a killer feature, verifiable shared masternode funding would allow way more participation and getting a test platform up and running asap (maybe an existing platform and signed messages initially) would allow much more efficient discussion (ie, for now I can assign whatever voting power I have to TaoOfSatoshi and get back to hitting things with hammers). Things like assigning percentages and proposing projects could be resolved far more effectively than via pages and pages of random and undirected discussion. Not that I don't like the discussion, as discussions go this forums loaded with good'ns but none of them have a hard and fast percentage of agreement.

stan.distortion, check out the bottom of page 19. Good summary of all the ideas.

 

[Nexus9]

This project should seek to accomplish at least 4 things in my view. 1. Establish a democratic reputation system where the community determines the rating criteria that should constitute a user's voting privileges. 2. Incorporate a universal infrastructure and mining reward tax that would pool financial resources into a community fund. 3. Build a programmable and fully decentralized virtual accounting system that could distribute those funds and carry out other essential operations in accord with the consensus of its constituents. 4. Engage in a deliberative assembly where the effective discussions and aggregate voting power of the members are used to release the funds needed for projects.

1. is required because there is no solution to the one-person-one-vote problem. Giving the masternodes all the voting power is a mistake as those with the greatest share of computational and financial resources will also have disproportionate control over the network. Why should those with more capital be in an arbitrarily privileged position to enforce their interests within the system? What is the democratic merit in doing this? The alternative is to allow the community to decide what should count.

Dash requires significant unrecognized work to develop its platform. Why not make these socially necessary contributions the standard of democratic control? For instance, if it takes an average of x time + expertise to start and maintain a masternode then that is the service rewarded with voting privileges. Now, of course, in addition to that you might all want to provide some other financial incentive given the costs of electricity and computing power. However, this should be a separate equation altogether to the one that affords political influence, e.g. transaction fees. Similarly, engaging in constructive discussion, software development, and community building are all valuable activities. Participating in the growth of the network should therefore be recognized as a political action with no less force than any other acitivity. Like Reddit and StackExchange, users could acquire karma / reputation by engaging in behavior the community deems valuable. In return, users would be granted more or less decision-making weight. If these mechanics were properly designed, you wouldn't be able to obtain more influence by creating more than one account as the voting power would be bound to the community's value judgments of the activities, and not the contingent private capital invested. Having 100 accounts with 300 reputation points worth of votes is no more effective than a single account with the very same number.

This unfortunately shifts the risk to a user's ability to make value judgments. There is nothing to prevent people from making multiple accounts to game the rating system. I believe Synereo has put forward one plausible solution to this issue. Essentially, trust is built-up over time through the density of vetted social network connections. If Alice trusts Bob and Bob trusts Peter they can mutually recognize each other to form a small-world network. As they continue trusting and mistrusting new users and as those new users continue trusting and mistrusting still more new users their associations will grow into a large-world network. Similar to how the formation of synapses work in the brain, it is the strength between these connections that constitutes their trusted status and therefore their privileges to make value judgments. In this arrangement, it would be extremely difficult for someone to start an army of sockpuppet accounts since each of those accounts would need to acheive an active trust with a diversity of other users in the larger network. In this way bots would be pruned out of the functional economy of decision-making and would have no true power to influence the community.

2. is the financial condition for the development of necessary projects. A certain amount of resources must be collected to serve the ends of the community. However, the precise rate of taxation along with the mode of distributing funds and the nature of the ends those funds should serve cannot be determined in advance. Parameters such as these have yet to be democratically negotiated. They should therefore remain open-ended while also reflecting the continual evolution and shifting consensus of the community. Deciding at the outset that x% of funds should go to the masternode operators and an unspecified promotion budget is more or less arbitrary. Dash should be using a democratically-controllable blockchain design similar to what Ethereum and Eris are capable of. As more discussions are carried out and more experiments are conducted a stable point of equilibrium will eventually be reached. That would encourage a far more legitimate outcome than simply dictating the terms at the outset in favor of a narrow and largely concealed set of developers and network operators. The contributions and most immediate needs of network users must be taken into account. All of these interests combined is what a community fund should represent.

3-4. is what ensures the security of the network against corruption. The prospect for collusion and misappropriation of funds should remain outside the reach of an arbitrarily privileged minority of individuals. This could be achieved by designing an autonomous program with executive control over the network's financial operations. The only way those operations could be activated is through the democratic processes set-up by the community. This follows the basic ideas already discussed in this thread. Motions are proposed, topics discussed, adjustments made, solutions voted on, and a summary decision rendered. You might consider modeling this in a way similar to how action potentials are known to function in the brain. That is, an authorized decision is only passed when the number of participants and their combined reputation scores are sufficient to overcome the accounting system's activation threshold. This would incentivize people to acquire as much reputation as possible and thus encourage only the very best ideas to flourish. It would also prevent centralized decision-makers from abusing their power because they would be accountable to the collective value judgments and decision-making processes of the community.

I realize these are complicated ambitions to carry out in practice. However, the very real possibility to do this is standing right in front of us. We have the technology. We have the expertise. And I also believe, we have the will. Something of this nature will be created eventually. If not in the Dash community, then elsewhere. Of course, the sooner the better.

 

[Solarminer]

This project should seek to accomplish at least 4 things in my view. 1. Establish a democratic reputation system where the community determines the rating criteria that should constitute a user's voting privileges. 2. Incorporate a universal infrastructure and mining reward tax that would pool financial resources into a community fund. 3. Build a programmable and fully decentralized virtual accounting system that could distribute those funds and carry out other essential operations in accord with the consensus of its constituents. 4. Engage in a deliberative assembly where the effective discussions and aggregate voting power of the members are used to release the funds needed for projects.

1. is required because there is no solution to the one-person-one-vote problem. Giving the masternodes all the voting power is a mistake as those with the greatest share of computational and financial resources will also have disproportionate control over the network. Why should those with more capital be in an arbitrarily privileged position to enforce their interests within the system? What is the democratic merit in doing this? The alternative is to allow the community to decide what should count.

Dash requires significant unrecognized work to develop its platform. Why not make these socially necessary contributions the standard of democratic control? For instance, if it takes an average of x time + expertise to start and maintain a masternode then that is the service rewarded with voting privileges. Now, of course, in addition to that you might all want to provide some other financial incentive given the costs of electricity and computing power. However, this should be a separate equation altogether to the one that affords political influence, e.g. transaction fees. Similarly, engaging in constructive discussion, software development, and community building are all valuable activities. Participating in the growth of the network should therefore be recognized as a political action with no less force than any other acitivity. Like Reddit and StackExchange, users could acquire karma / reputation by engaging in behavior the community deems valuable. In return, users would be granted more or less decision-making weight. If these mechanics were properly designed, you wouldn't be able to obtain more influence by creating more than one account as the voting power would be bound to the community's value judgments of the activities, and not the contingent private capital invested. Having 100 accounts with 300 reputation points worth of votes is no more effective than a single account with the very same number.

This unfortunately shifts the risk to a user's ability to make value judgments. There is nothing to prevent people from making multiple accounts to game the rating system. I believe Synereo has put forward one plausible solution to this issue. Essentially, trust is built-up over time through the density of vetted social network connections. If Alice trusts Bob and Bob trusts Peter they can mutually recognize each other to form a small-world network. As they continue trusting and mistrusting new users and as those new users continue trusting and mistrusting still more new users their associations will grow into a large-world network. Similar to how the formation of synapses work in the brain, it is the strength between these connections that constitutes their trusted status and therefore their privileges to make value judgments. In this arrangement, it would be extremely difficult for someone to start an army of sockpuppet accounts since each of those accounts would need to acheive an active trust with a diversity of other users in the larger network. In this way bots would be pruned out of the functional economy of decision-making and would have no true power to influence the community.

2. is the financial condition for the development of necessary projects. A certain amount of resources must be collected to serve the ends of the community. However, the precise rate of taxation along with the mode of distributing funds and the nature of the ends those funds should serve cannot be determined in advance. Parameters such as these have yet to be democratically negotiated. They should therefore remain open-ended while also reflecting the continual evolution and shifting consensus of the community. Deciding at the outset that x% of funds should go to the masternode operators and an unspecified promotion budget is more or less arbitrary. Dash should be using a democratically-controllable blockchain design similar to what Ethereum and Eris are capable of. As more discussions are carried out and more experiments are conducted a stable point of equilibrium will eventually be reached. That would encourage a far more legitimate outcome than simply dictating the terms at the outset in favor of a narrow and largely concealed set of developers and network operators. The contributions and most immediate needs of network users must be taken into account. All of these interests combined is what a community fund should represent.

3-4. is what ensures the security of the network against corruption. The prospect for collusion and misappropriation of funds should remain outside the reach of an arbitrarily privileged minority of individuals. This could be achieved by designing an autonomous program with executive control over the network's financial operations. The only way those operations could be activated is through the democratic processes set-up by the community. This follows the basic ideas already discussed in this thread. Motions are proposed, topics discussed, adjustments made, solutions voted on, and a summary decision rendered. You might consider modeling this in a way similar to how action potentials are known to function in the brain. That is, an authorized decision is only passed when the number of participants and their combined reputation scores are sufficient to overcome the accounting system's activation threshold. This would incentivize people to acquire as much reputation as possible and thus encourage only the very best ideas to flourish. It would also prevent centralized decision-makers from abusing their power because they would be accountable to the collective value judgments and decision-making processes of the community.

I realize these are complicated ambitions to carry out in practice. However, the very real possibility to do this is standing right in front of us. We have the technology. We have the expertise. And I also believe, we have the will. Something of this nature will be created eventually. If not in the Dash community, then elsewhere. Of course, the sooner the better.

I think the recent revised proposal that we are voting on addresses some of your points.
https://dashtalk.org/threads/vote-s...tralized-governance-by-blockchain.4825/page-4

I will also comment on 1 above. The segment of the market with most to gain and most to loose are the masternode owners that have invested 1000 DASH. They are also the most knowledgeable about how wallets and the blockchain work for DASH. There is no other segment that should be determining the long term strategy of the coin. If you want to vote, participate in a masternode. There are services when you can own a share in a masternode if you can't afford a full node. If you want to support the network, point a miner at a DASH pool or start a P2P Node.

Just because you may get 800 likes or post 200 posts in a DASH thread, isn't going to make you understand the principles or want DASH to succeed as strongly as someone that has a big investment on the line.

As for the comment about DASH needing significant work to finish it. Great, figure out what is needed, create a project and get paid. Maybe even use your earnings to buy a masternode and vote.

 

[camosoul]

Bottom line is simpler than all this.

The blockchain is getting raped. In the ass. No condom.

You get to vote on whether or not the rapist's brother will wear matching socks 4 days ago. Oh, wait, you can't change the past, even with a vote, so sorry! Fuck you!

 

[Jeztah]

Bottom line is simpler than all this.

The blockchain is getting raped. In the ass. No condom.

You get to vote on whether or not the rapist's brother will wear matching socks 4 days ago. Oh, wait, you can't change the past, even with a vote, so sorry! Fuck you!

Camo, I've spent considerably more time than I would have liked to trying to understand your point. Are you for or against voting, and what do you mean about the blockchain? Thanks.

 

[oaxaca]

"it is the strength between these connections that constitutes their trusted status and therefore their privileges to make value judgments."

The number of "likes" you can collect has no correlation to your ability to make business decisions.