Self-sustainable Decentralized Governance by Blockchain

[thelonecrouton]

A full 15% block reward regardless of project takes greed out of the equation, leaving only an interest in the greater good

Said every warmongering banker, politician and priest ever, as they took our money and lined their own pockets with it.

I wonder if porktalk.org and porkpay.io have been registered yet?

With this weight cleared from the decision making process I think it's much more likely projects will be chosen strictly on merit. I have faith in humanity, really, I do -- but only when self-serving interests are removed from the equation can this thing really work.


The sad truth is that this is and should be an all-or-nothing type of deal. Without forcing a black and white consensus self-serving interests will always prevail.

Your logic here is broken, because your assertion that mandatory taxation eliminates greed and self interest is flat out ludicrous.

Self serving interests are in no way being removed from anything with a mandatory tax, projects that lacked enough merit to be approved in the first place, by vote, are going to get funded anyway, and WTF is a "forced consensus?"

 

[TanteStefana]

If the DASH is in escrow and it will be given back if no projects get voted on, than the same argument applies, MNs will vote against projects and just to keep the rewards.

So maybe we can move past the forced donation nonsense. Just take out enough funds for valuable projects that get voted in.

I honestly don't think you understand anything I tried to say. I just don't know any other way. Anyway, I'm going to bed good night everyone!!!

 

[fulltimegeek]

Let me make my concept of governance a little bit clearer because I think some confusion is in the air regarding pork barrels (Unproductive Human Leeches).

-- DASH Voting Governance --
Phase 1: All masternodes that want to elect a "Spending Proposal" must vote "YES" for it.

Spending Proposal Example:
Submitter: Evan Duffield
Duration: 210,240 blocks
Project Name/Recipient | Address | Slice
Evan Duffield______________| Xabc...... | 10%
Udjn_______________________| Xbca...... | 10%
Flare_______________________| Xcab...... | 10%
Marketing / Promotion___| XAab...... | 60%
Random / Savings________| XcbA...... | 10%

Note: Only 1 proposal can be active at a time until it's time expires.

Phase 2: Once a spending proposal is elected by having the most "YES" votes; MNs that initially voted "YES" can no longer change their vote until the spending proposal's time expires. The %15 block reward is now split between the "YES" votes and the "NO" votes. "YES" goes to the spending proposal and "NO" votes goes to either MNs or Escrow (up for debate). An "ABSTAIN" would count as a "YES" vote once the proposal is active.

If all "NO" votes are directed to the MNs then there is no way for those MNOs to fund pork barrel.

The reason why I like this method is because I, as a MNO, don't have to study about every project in the proposal but would rely heavily on the reputation of the proposal submitter -- in this case Evan Duffield. Secondly, It also gives a way for those who do not want to fund the projects to OPT OUT (no pork barrel). Thirdly, funded projects would have more chance of completion if "YES" votes can not be changed. Fourth, if the submitter is not anonymous, then we would have a point of contact as to how things are running and being managed. Fifth, if MNOs that initially voted "NO" want to start funding the proposal, they can change their vote at any time while the proposal is active.

Possible Problems with this concept
* MN operators that initially voted YES can just recreate a new MN address and there is no way to tell if they were the original voter or a new MN on the network. A way around this is by forcing all new MNs that joined the network AFTER the proposal was activated to vote "ABSTAIN" or "YES".

 

[thelonecrouton]

Let me make my concept of governance a little bit clearer because I think some confusion is in the air regarding pork barrels (Unproductive Human Leeches).

-- DASH Voting Governance --
Phase 1: All masternodes that want to elect a "Spending Proposal" must vote "YES" for it.

Spending Proposal Example:
Submitter: Evan Duffield
Duration: 210,240 blocks
Project Name/Recipient | Address | Slice
Evan Duffield______________| Xabc...... | 10%
Udjn_______________________| Xbca...... | 10%
Flare_______________________| Xcab...... | 10%
Marketing / Promotion___| XAab...... | 60%
Random / Savings________| XcbA...... | 10%

Note: Only 1 proposal can be active at a time until it's time expires.

Phase 2: Once a spending proposal is elected by having the most "YES" votes; MNs that initially voted "YES" can no longer change their vote until the spending proposal's time expires. The %15 block reward is now split between the "YES" votes and the "NO" votes. "YES" goes to the spending proposal and "NO" votes goes to either MNs or Escrow (up for debate). An "ABSTAIN" would count as a "YES" vote.

If all "NO" votes are directed to the MNs then there is no way for those MNOs to fund pork barrel.

The reason why I like this method is because I, as a MNO, don't have to study about every project in the proposal but would rely heavily on the reputation of the proposal submitter -- in this case Evan Duffield. Secondly, It also gives a way for those who do not want to fund the projects to OPT OUT (no pork barrel). Thirdly, funded projects would have more chance of completion if "YES" votes can not be changed. Fourth, if the submitter is not anonymous, then we would have a point of contact as to how things are running and being managed. Fifth, if MNOs that initially voted "NO" want to start funding the proposal, they can change their vote at any time while the proposal is active.

Possible Problems with this concept
* MN operators that initially voted YES can just recreate a new MN address and there is no way to tell if they were the original voter or a new MN on the network. A way around this is by forcing all new MNs that joined the network AFTER the proposal was activated to vote "ABSTAIN" or "YES".

I don't like the 'bundling' of projects in the example you have given. Maybe I like one aspect but not another? The 'only 1 funded initiative at a time' also seems very restrictive.

I think it an be simpler while also being more flexible.

eg.
Proposer A wants $X to pay to develop feature P
Proposer B wants $Y to pay to develop feature Q
Proposer C wants $Z to pay to develop feature R

All of these can be voted on independently, with those that pass vote being added to the rolling funding priority list with their position in that list determined by the level of voting support they garnered.

eg.

Proposal A and B are submitted at the same time
Proposal A receives 30% more votes than required* to pass voting, goes to top of list and money is diverted its way first.
Proposal B receives 20% more votes than required to pass voting, goes to position 2 and money is diverted its way subject to availability. Might take longer to fully fund if A is very expensive, might not have to wait at all.
Proposal C does not meet consensus criteria and no money is diverted towards it.

Then Proposal D comes along and gets 45% more votes than required to pass voting because everyone thinks it's a fantastic idea, jumps to priority #1 in list and the others are bumped down.

The alternative to maybe having your funding put on hold if something that people feel is more urgent comes up is to keep it strictly FIFO.


* Not much discussion has taken place on the voting system in terms of what will constitute a funding pass.

I would suggest

IF (Yes votes > No votes) AND (total votes cast > 40% of MN count):

funding goes ahead;
Priority Score = number of Yes votes above (40% of MN count / 2);​

I see no point in Abstain being an option. Yes or No is all that's needed. There should be no default vote. You must choose one or the other.

Proposals to terminate projects should go through the same process, with funding to be halted immediately upon pass and any previously allocated funding going to whatever is at the top of the queue.

Frivolous proposals would never get anywhere due to the minimum participation criteria, and spam could be further reduced by having a Proposal Tabling Fee ( 1 DASH?) which is paid to miners/next MN in line/local donkey sanctaury/whoever.

In this system, I do not see funding being at all difficult to achieve on a voluntary basis if a proposal has merit, and there are no free riders, enough Yes votes and funding comes from all, but it allows voters a real No vote to bad ideas and there's no pork barrel to be abused.

 

[Solarminer]

I don't like the 'bundling' of projects in the example you have given. Maybe I like one aspect but not another? The 'only 1 funded initiative at a time' also seems very restrictive.

I think it an be simpler while also being more flexible.

eg.
Proposer A wants $X to pay to develop feature P
Proposer B wants $Y to pay to develop feature Q
Proposer C wants $Z to pay to develop feature R

All of these can be voted on independently, with those that pass vote being added to the rolling funding priority list with their position in that list determined by the level of voting support they garnered.

eg.

Proposal A and B are submitted at the same time
Proposal A receives 30% more votes than required* to pass voting, goes to top of list and money is diverted its way first.
Proposal B receives 20% more votes than required to pass voting, goes to position 2 and money is diverted its way subject to availability. Might take longer to fully fund if A is very expensive, might not have to wait at all.
Proposal C does not meet consensus criteria and no money is diverted towards it.

Then Proposal D comes along and gets 45% more votes than required to pass voting because everyone thinks it's a fantastic idea, jumps to priority #1 in list and the others are bumped down.

The alternative to maybe having your funding put on hold if something that people feel is more urgent comes up is to keep it strictly FIFO.


* Not much discussion has taken place on the voting system in terms of what will constitute a funding pass.

I would suggest

IF (Yes votes > No votes) AND (total votes cast > 40% of MN count):

funding goes ahead;
Priority Score = number of Yes votes above (40% of MN count / 2);​

I see no point in Abstain being an option. Yes or No is all that's needed. There should be no default vote. You must choose one or the other.

Proposals to terminate projects should go through the same process, with funding to be halted immediately upon pass and any previously allocated funding going to whatever is at the top of the queue.

Frivolous proposals would never get anywhere due to the minimum participation criteria, and spam could be further reduced by having a Proposal Tabling Fee ( 1 DASH?) which is paid to miners/next MN in line/local donkey sanctaury/whoever.

In this system, I do not see funding being at all difficult to achieve on a voluntary basis if a proposal has merit, and there are no free riders, enough Yes votes and funding comes from all, but it allows voters a real No vote to bad ideas and there's no pork barrel to be abused.

Thelonecrouton, I like the way you think. The idea of a proposal submit fee to reduce spam projects is great.

As for voting %....

• Camasoul is thinking 66% majority to get a project in. Understanding that each project needs to be a 'good' project, a real winner.
• I was thinking 51% as it is a majority and wouldn't require every masternode to vote. It would still allow 30% or 40% to not vote.
• The 40% requirement is too low. It would allow 40% yes and 40% no. Then what? There would need to be a threshold for no votes too if this were desired. Like 40% yes but only if less than 20% no or something. Might be complicated to get right.
• I see anything over 51% but less than 90% working well. (Over 90% will be too restrictive requiring nearly all the masternodes to vote.)

So working with your idea.

• 51% for a project to be approved.
• Full 15% goes to each project voted in, but in the order of priority with highest votes.
• If no valid projects, 15% stays with the masternode rewards.

This could work.
Only one project can get funding at a time. (could be good or bad)
Jumping from 0-15% is a big step and might hold off yes votes.
Projects could quote block reward months needed. Then funding expires after quoted time and switches to next project.
Limits long term projects since only one project can be implemented. Like a bug fix fund of 1% ongoing.

 

[thelonecrouton]

Thelonecrouton, I like the way you think. The idea of a proposal submit fee to reduce spam projects is great.

As for voting %....

• Camasoul is thinking 66% majority to get a project in. Understanding that each project needs to be a 'good' project, a real winner.
• I was thinking 51% as it is a majority and wouldn't require every masternode to vote. It would still allow 30% or 40% to not vote.
• The 40% requirement is too low. It would allow 40% yes and 40% no. Then what? There would need to be a threshold for no votes too if this were desired. Like 40% yes but only if less than 20% no or something. Might be complicated to get right.
• I see anything over 51% but less than 90% working well. (Over 90% will be too restrictive requiring nearly all the masternodes to vote.)

So working with your idea.

• 51% for a project to be approved.
• Full 15% goes to each project voted in, but in the order of priority with highest votes.
• If no valid projects, 15% stays with the masternode rewards.

This could work.
Only one project can get funding at a time. (could be good or bad)
Jumping from 0-15% is a big step and might hold off yes votes.
Projects could quote block reward months needed. Then funding expires after quoted time and switches to next project.
Limits long term projects since only one project can be implemented. Like a bug fix fund of 1% ongoing.

Personally I'm happy with a higher voting threshold, 40% seemed like a sensible minimum. In the event of a perfectly tied vote I think the default behaviour should be a Not Passed? I don't see a 'No' threshold being needed as surely this would already be taken care of by the participation minimum, but maybe I have misunderstood what you meant. If the 'Yes' criteria are not met it's a 'No' anyway.

As long as funds are diverted when required and go immediately to the recipient (upon feature delivery / at milestone etc.) and we avoid the necessity of any money hanging about to be wasted/embezzled/seized by our beloved overlords.

If funding is only diverted as needed I don't see why, upon approval, multiple projects cannot proceed at once. Their payment dates and payment milestones will all be different and can be automatically met, sequentially, or queued if needed according to their consensus priority score.

Pardon my bombast, but if we get this right it could be a milestone not just in crypto but in the whole concept of consensual governance - real democracy without any potential for abuse. The other route is well and truly trodden...

 

[Solarminer]

Think about a vote of 41% yes and 45% no. I think this would not be fair to go forward since over half of the voters were opposed. There would need to be a decision if a 40% yes would go as long as the no was less than 39% no or whatever. It seems simpler just to require a 51%+ yes vote and not count the no votes.

The decision how to split funding needs to happen with the voting system. These are the options:

• Project owner specifies a split x% share and only the projects added up to under the 15% cap get funded,
  
• All projects are go that meet 51%+ yes, but are split based on voting %,
• Top 3 projects are go that meet 51%+ yes, but are split based on voting %
  
• Each project gets full 15% but is executed in order by highest votes first.

Yes, this needs to be correct. I encourage the feedback good or bad. We are setting the standard.

 

[thelonecrouton]

Think about a vote of 41% yes and 45% no. I think this would not be fair to go forward since over half of the voters were opposed. There would need to be a decision if a 40% yes would go as long as the no was less than 39% no or whatever. It seems simpler just to require a 51%+ yes vote and not count the no votes.

It wouldn't go forward:

IF (Yes votes > No votes) AND (total votes cast > 40% of MN count):

funding goes ahead;
Priority Score = number of Yes votes above (40% of MN count / 2);

It seems simpler just to require a 51%+ yes vote and not count the no votes.

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

The decision how to split funding needs to happen with the voting system. These are the options:

Project owner specifies a split x% share and only the projects added up to under the 15% cap get funded,
All projects are go that meet 51%+ yes, but are split based on voting %,
Top 3 projects are go that meet 51%+ yes, but are split based on voting %
Each project gets full 15% but is executed in order by highest votes first.

Yes, this needs to be correct. I encourage the feedback good or bad. We are setting the standard.

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:

 

[Solarminer]

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.

 

[Solarminer]

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

This is the hard part, isn't it? I don't think we can just split the block rewards by 15% and send to projects. If each MN payment is only 2 DASH then each 15% block reward would be about 0.3 DASH. This seems like it would cause a bloated wallet with 1000s of these transactions. Maybe this needs to be something like a round robin deal.

1 of every 7 masternode (2 DASH) payments goes to a project. Then each project gets a payment determined by it's priority. It would be easier if each project had the same weight and it just cycled between them, but it shouldn't be that much more code to add more payments to one project than another.
1 of every 7 = 14.28% so maybe change the cap to this. Otherwise, 15% would be 1 of every 6.66.

FYI, this proposal assumes full donation amount split between projects, but we could add % needed for each project variable, add that up on the winning projects to give the donation amount(1 in every 10 would be 10%, 1 in every 20 would be 5%, etc.).

Now that I think about it, maybe we just set a 5% amount for each project. If only one project is voted in, the donation is 5%(1 in 20 payments), 2 projects-10%(2 in 20 payments), 3 projects-15%(3 in 20 payments).

 

[Solarminer]

Hi, I want to just be sure you all understand what I'm trying to say So I'm going to try with a little diagram. In truth, I don't like the pay as you choose model because it will likely infringe on my rewards, reducing my ROI by causing more MN owners to shortsightedly create too many masternodes, reducing everyone's ROI. Please let me explain.

Diagram 1 is my proposal:

In this example, masternode owners can be relatively certain of their ROI because their block rewards do not change. This way, only so many masternodes will be created as makes sense. Say the market thinks a 15% per year reward is good, maybe more, maybe less. Lets say those numbers land us at 3000 masternodes, and it stays there nice and steady because there are no fluctuations in the rewards.

Now at the end of the year, if the funding was not used up, the funds go back to the miners and masternodes equally. This can be distributed evenly if a portion of the excess is distributed with each block reward over the next year. The Masternodes would increase, undoubtedly, due to the increase in rewards until you hit that balance again, and the miner's hash rate would undoubtedly increase as more miners come in to mine as the rewards have increased.

In the end, Masternode owners can always expect a certain ROI, knowing that they will be able to pay their servers and still have a small profit at the end.

There is another big advantage to this funding system. It allows for savings. If there is a big project that the community wants to do, but it requires a large amount of funds, over 15%, funds could be put aside for it, and the project can eventually be achieved. Without an ability to save, this can not be done. Or else, large accounts must be entrusted with trusted people who may fail us.

Low varience
Stability
ability to plan

These are the major positives of this system. I'm sure it could be refined, but even kept as simple as this model makes it, it would work. Simple and eloquent.


The basic other proposal:

In this diagram, the masternode owners will recieve 60% of the block rewards. This will likely increase the masternodes until they feel they have an acceptable ROI, if all things were equal, we would have about 5250 masternodes with 60% of the rewards. Now, a project comes up, and it's funded at 2%, another is funded at 5% and yet another at 8% and so on until we hit the 15% limit. The masternodes, if they haven't already, are freaking out because it costs them too much to run their masternodes and they're losing money, but they have worked so hard for their masternode, nobody wants to stop them, so they all eek out, maybe enough to pay their servers.

Or, the masternode count rises and falls along with the block rewards given out. This would create a lot of volatility in service. With this much chaos, and nobody able to make enough ROI, they stop funding things. Yes, I can see it happen. And once you have that many people who struggled to get their masternodes, it'll be hard to get them to turn them off.

Now, lets say that there is an idea for a big project that would require more than 15% of the rewards. There is no savings. What would you do? Pay the project until THEY save up enough money to do it? You'd trust them? What if they (likely) run off with the funds before it starts? Who else would you like to trust the funds to? Without a DAO, you got nuthin.

Finally, the fact that you can't save at all reduces your ability to make future plans. It ties your hands.


Personally, I reject the idea that Masternode owners will vote for anything if the funds are there. Sure, if the funds are returned a year later, there is no big incentive to recycle the funds back to MN and Miners, but there is no incentive to burn up funds either.


I hope some of you can understand now the advantages of the first proposal. I honestly don't think the second proposal is stable and I suspect people think they will be able to keep more of the funds for themselves, but that surely won't be the case. Instead, you will trade it off for volatility and probably lower income. And this is why I don't like it, because I want stability and a decent rate of return on my investment. Because I am selfish!!!

Edit: Pictures were reversed, fixed
Edit 2: There was a line in the diagram that didn't belong there, fixed

Just to clear all this up, I have made a flow chart that should make this obvious.

 

[snogcel]

Said every warmongering banker, politician and priest ever, as they took our money and lined their own pockets with it.

I wonder if porktalk.org and porkpay.io have been registered yet?



Your logic here is broken, because your assertion that mandatory taxation eliminates greed and self interest is flat out ludicrous.

Self serving interests are in no way being removed from anything with a mandatory tax, projects that lacked enough merit to be approved in the first place, by vote, are going to get funded anyway, and WTF is a "forced consensus?"

My assertion isn't that broadly scoped, but maybe that wasn't clear in my previous post. What I was saying is that this removes self-serving motives from the decision maker (the voting MN owner). Of course there's still going to be greedy folks trying to create B.S. projects in hopes they'll get a slice. That's what the voting system is there for, to filter out the crap and leave only the good projects around.

I don't recall ever saying "forced consensus", you did. What I say was that it should be an all-or-nothing type of deal. By that I think it just doesn't make sense to take 15%, vote on whether to use it, then return whatever's leftover using some type of refund mechanism. Similarly, it doesn't make sense to me to collect 15% only upon approval of certain projects.

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.

 

[fuzzyduck]

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.

Sent with my fat thumbs from my mobile.

 

[AzzAz]

Voting first for percentage would be nice. To me 10% looks better than 15%. It might slow down projects a bit but higher percentage might decrease MN count so...

 

[darkstrike420]

Voting first for percentage would be nice. To me 10% looks better than 15%. It might slow down projects a bit but higher percentage might decrease MN count so...

Supporting Dash development should be optional for Masternode operators.

I didn't read the full thread (28 pages, aint got time for that sadly) but I did see word "Marketing" and "60%" in this thread.

In my opinion, spending any amount of money on marketing as of right now would be a complete waste of funds. We need iOS/Android/Ubuntu wallets for phones, we need e-wallets, we need an easy way to exchange cash to dash and most importantly - we need something that teaches old people how to use smartphones and how to use the future dash phone wallet because without the old people there will be no mainstream. I see old people struggling with their credit-card PIN as its too hard for their brain we need the dash wallet to be much more simple than using a credit-card. If all old people say "Fuck banks. Dash is better." we will be one step closer.

 

[thelonecrouton]

My assertion isn't that broadly scoped, but maybe that wasn't clear in my previous post. What I was saying is that this removes self-serving motives from the decision maker (the voting MN owner).

I don't think I was clear either. Removing self-interest from the electorate makes the whole process a sham and will lead to the railroading of useless crap, as the only people who will be bothered to vote are the barrel plunderers.

Of course there's still going to be greedy folks trying to create B.S. projects in hopes they'll get a slice. That's what the voting system is there for, to filter out the crap and leave only the good projects around.

Nothing is really filtered out if there isn't an option to say No to useless expenditure in the first place.

I don't recall ever saying "forced consensus", you did.

Uh:

Without forcing a black and white consensus self-serving interests will always prevail.

...and, once more, the self serving interests of the electorate should and must prevail, not the self serving interests of the pork plunderers.

What I say was that it should be an all-or-nothing type of deal. By that I think it just doesn't make sense to take 15%, vote on whether to use it, then return whatever's leftover using some type of refund mechanism. Similarly, it doesn't make sense to me to collect 15% only upon approval of certain projects.


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.

We have come to nearly opposite conclusions. It will be a revolutionary step for good if the electorate actually has a meaningful vote. It will be the same farce we see absolutely everywhere else otherwise.

 

[thelonecrouton]

Supporting Dash development should be optional for Masternode operators.

I didn't read the full thread (28 pages, aint got time for that sadly) but I did see word "Marketing" and "60%" in this thread.

In my opinion, spending any amount of money on marketing as of right now would be a complete waste of funds. We need iOS/Android/Ubuntu wallets for phones, we need e-wallets, we need an easy way to exchange cash to dash and most importantly - we need something that teaches old people how to use smartphones and how to use the future dash phone wallet because without the old people there will be no mainstream. I see old people struggling with their credit-card PIN as its too hard for their brain we need the dash wallet to be much more simple than using a credit-card. If all old people say "Fuck banks. Dash is better." we will be one step closer.

100% agreed: https://dashtalk.org/threads/crouto...ly-also-pow-is-an-exclusionary-dead-end.4735/ :smile:

 

[moli]

Supporting Dash development should be optional for Masternode operators.

I didn't read the full thread (28 pages, aint got time for that sadly) but I did see word "Marketing" and "60%" in this thread.

In my opinion, spending any amount of money on marketing as of right now would be a complete waste of funds. We need iOS/Android/Ubuntu wallets for phones, we need e-wallets, we need an easy way to exchange cash to dash and most importantly - we need something that teaches old people how to use smartphones and how to use the future dash phone wallet because without the old people there will be no mainstream. I see old people struggling with their credit-card PIN as its too hard for their brain we need the dash wallet to be much more simple than using a credit-card. If all old people say "Fuck banks. Dash is better." we will be one step closer.

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

 

[fulltimegeek]

Supporting Dash development should be optional for Masternode operators.

I didn't read the full thread (28 pages, aint got time for that sadly) but I did see word "Marketing" and "60%" in this thread.

In my opinion, spending any amount of money on marketing as of right now would be a complete waste of funds. We need iOS/Android/Ubuntu wallets for phones, we need e-wallets, we need an easy way to exchange cash to dash and most importantly - we need something that teaches old people how to use smartphones and how to use the future dash phone wallet because without the old people there will be no mainstream. I see old people struggling with their credit-card PIN as its too hard for their brain we need the dash wallet to be much more simple than using a credit-card. If all old people say "Fuck banks. Dash is better." we will be one step closer.

Those were just arbitrary percentages I used for my concept of a spending proposal. I personally would only want to vote for a proposal that is mostly focused on development right now because we're still at beta. Maybe a little bit of marketing/promotion.

 

[thelonecrouton]

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

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.