Welcome to the Dash Forum!

Please sign up to discuss the most innovative cryptocurrency!

Self-sustainable Decentralized Governance by Blockchain

Discussion in 'Official Announcements' started by eduffield, Apr 22, 2015.

  1. thelonecrouton

    thelonecrouton Well-known Member
    Foundation Member

    Joined:
    Apr 15, 2014
    Messages:
    1,139
    Likes Received:
    815
    Trophy Points:
    283
    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?"
     
    #541 thelonecrouton, Apr 29, 2015
    Last edited by a moderator: Apr 29, 2015
    • Like Like x 3
  2. TanteStefana

    TanteStefana Moderator
    Linguistic Foundation Member

    Joined:
    Mar 9, 2014
    Messages:
    2,839
    Likes Received:
    1,861
    Trophy Points:
    1,283
    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!!!
     
  3. fulltimegeek

    fulltimegeek Well-known Member
    Foundation Member

    Joined:
    Sep 17, 2014
    Messages:
    109
    Likes Received:
    217
    Trophy Points:
    193
    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".
     
    #543 fulltimegeek, Apr 29, 2015
    Last edited by a moderator: Apr 29, 2015
    • Like Like x 1
  4. thelonecrouton

    thelonecrouton Well-known Member
    Foundation Member

    Joined:
    Apr 15, 2014
    Messages:
    1,139
    Likes Received:
    815
    Trophy Points:
    283
    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.
     
    #544 thelonecrouton, Apr 29, 2015
    Last edited by a moderator: Apr 29, 2015
    • Like Like x 2
  5. Solarminer

    Solarminer Well-known Member

    Joined:
    Apr 4, 2015
    Messages:
    763
    Likes Received:
    922
    Trophy Points:
    163
    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.
     
    • Like Like x 1
  6. thelonecrouton

    thelonecrouton Well-known Member
    Foundation Member

    Joined:
    Apr 15, 2014
    Messages:
    1,139
    Likes Received:
    815
    Trophy Points:
    283
    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...
     
    #546 thelonecrouton, Apr 29, 2015
    Last edited by a moderator: Apr 29, 2015
  7. Solarminer

    Solarminer Well-known Member

    Joined:
    Apr 4, 2015
    Messages:
    763
    Likes Received:
    922
    Trophy Points:
    163
    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.
     
  8. thelonecrouton

    thelonecrouton Well-known Member
    Foundation Member

    Joined:
    Apr 15, 2014
    Messages:
    1,139
    Likes Received:
    815
    Trophy Points:
    283
    It wouldn't go forward:
    Agreed. And maybe it's better to start with a higher bar and see how that works out before trying anything else.

    Let me try and lay out how I envision this working in pseudo code. I am not a coder, this is barebones rough draft 0.0.0.1-pre-alpha, try not to laugh too loudly.
    Code:
    # 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... :D
     
    #548 thelonecrouton, Apr 29, 2015
    Last edited by a moderator: Apr 29, 2015
    • Like Like x 3
  9. Solarminer

    Solarminer Well-known Member

    Joined:
    Apr 4, 2015
    Messages:
    763
    Likes Received:
    922
    Trophy Points:
    163
    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.
     
    #549 Solarminer, Apr 30, 2015
    Last edited by a moderator: Apr 30, 2015
    • Like Like x 3
  10. Solarminer

    Solarminer Well-known Member

    Joined:
    Apr 4, 2015
    Messages:
    763
    Likes Received:
    922
    Trophy Points:
    163
    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).
     
    #550 Solarminer, Apr 30, 2015
    Last edited by a moderator: Apr 30, 2015
    • Like Like x 1
  11. Solarminer

    Solarminer Well-known Member

    Joined:
    Apr 4, 2015
    Messages:
    763
    Likes Received:
    922
    Trophy Points:
    163
    Just to clear all this up, I have made a flow chart that should make this obvious.
    The TanteStefana Plan.jpg
     
  12. snogcel

    snogcel Well-known Member
    Foundation Member

    Joined:
    Jun 11, 2014
    Messages:
    188
    Likes Received:
    202
    Trophy Points:
    203
    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.
     
    • Like Like x 2
  13. fuzzyduck

    fuzzyduck Active Member

    Joined:
    Feb 19, 2015
    Messages:
    141
    Likes Received:
    115
    Trophy Points:
    93
    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.
     
  14. AzzAz

    AzzAz New Member

    Joined:
    Feb 24, 2015
    Messages:
    8
    Likes Received:
    6
    Trophy Points:
    3
    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...
     
  15. darkstrike420

    darkstrike420 Active Member

    Joined:
    Jul 1, 2014
    Messages:
    178
    Likes Received:
    136
    Trophy Points:
    103
    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.
     
    • Like Like x 4
  16. thelonecrouton

    thelonecrouton Well-known Member
    Foundation Member

    Joined:
    Apr 15, 2014
    Messages:
    1,139
    Likes Received:
    815
    Trophy Points:
    283
    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.


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


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

    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.
     
    #556 thelonecrouton, May 1, 2015
    Last edited by a moderator: May 1, 2015
    • Like Like x 1
  17. thelonecrouton

    thelonecrouton Well-known Member
    Foundation Member

    Joined:
    Apr 15, 2014
    Messages:
    1,139
    Likes Received:
    815
    Trophy Points:
    283
    100% agreed: https://dashtalk.org/threads/crouto...ly-also-pow-is-an-exclusionary-dead-end.4735/ :)
     
    • Like Like x 3
  18. moli

    moli Grizzled Member

    Joined:
    Aug 5, 2014
    Messages:
    3,262
    Likes Received:
    1,837
    Trophy Points:
    1,183
    +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.
     
    #558 moli, May 1, 2015
    Last edited by a moderator: May 1, 2015
    • Like Like x 2
  19. fulltimegeek

    fulltimegeek Well-known Member
    Foundation Member

    Joined:
    Sep 17, 2014
    Messages:
    109
    Likes Received:
    217
    Trophy Points:
    193
    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.
     
    #559 fulltimegeek, May 1, 2015
    Last edited by a moderator: May 1, 2015
  20. thelonecrouton

    thelonecrouton Well-known Member
    Foundation Member

    Joined:
    Apr 15, 2014
    Messages:
    1,139
    Likes Received:
    815
    Trophy Points:
    283
    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.
     
  21. crowning

    crowning Well-known Member

    Joined:
    May 29, 2014
    Messages:
    1,430
    Likes Received:
    2,009
    Trophy Points:
    183
    I'm sorry to state the obvious, but it will not be up to Evan to decide if and how much funds will be used for what...
     
    • Like Like x 1
  22. Solarminer

    Solarminer Well-known Member

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

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

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

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

    Solarminer Well-known Member

    Joined:
    Apr 4, 2015
    Messages:
    763
    Likes Received:
    922
    Trophy Points:
    163
    The last "Let's talk Bitcoin" talked about wallets. It was interesting what has come about.
    • The bitcoin core wallet is really secure, but takes minutes to hours to load up and sync with the network.
    • The web wallets are really susceptible to getting hacked.
    • There are hybrid wallets with more security, and less wait to load up and sync.
    It seems like there is really no ideal solution. Any convenience of web wallet is limited by the likelihood of hacking. The hybrid wallets had issues with too many transactions, which should be fixed. A good passphrase for a web wallet would need to be 12 random words. To me this is just impossible to remember. It is crazy the lengths Andreas Antonopolis goes to, just to secure his bitcoins(removing network cards on his computer while creating keys). There is a ton of potential for improvement here.

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

    As for anyone else storing my wallets in the masternode network, no thanks. I want to keep my wallets offline as much as possible.
     
    • Like Like x 1
  24. Solarminer

    Solarminer Well-known Member

    Joined:
    Apr 4, 2015
    Messages:
    763
    Likes Received:
    922
    Trophy Points:
    163
    Taking 15% without a vote from the network is a tax. Right now it is going to miners and per the MN payment schedule will go to the MNs in 2016. The argument that it is coming from the network would have worked if this was a new coin. Doing this now is a tax.

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

    Voting for valid projects with 15% of the block rewards. Having investors with 1000 coins vote on each project keeping a check on good/bad value projects based on the increase in their 1000 coins vs loss of 1/4 of their block rewards = Genius Idea!
     
    #564 Solarminer, May 1, 2015
    Last edited by a moderator: May 1, 2015
    • Like Like x 1
  25. crowning

    crowning Well-known Member

    Joined:
    May 29, 2014
    Messages:
    1,430
    Likes Received:
    2,009
    Trophy Points:
    183
    I seem to repeat myself all day, I guess nobody reads my posts any more: if someone wants to spend money on pizzas just vote NO. Or yes. It doesn't get any simpler than that.

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

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

    YES , or NO. What's it gonna be boy? I can't wait all night...Yes or No?
     
    • Like Like x 5
  26. Solarminer

    Solarminer Well-known Member

    Joined:
    Apr 4, 2015
    Messages:
    763
    Likes Received:
    922
    Trophy Points:
    163
    I am with you. I clarified my post. Obviously, if there was a vote for a pizza event and it won, fantastic the system works.
     
    • Like Like x 1
  27. Bridgewater

    Bridgewater Well-known Member
    Foundation Member

    Joined:
    Dec 14, 2014
    Messages:
    183
    Likes Received:
    164
    Trophy Points:
    203
    I just came across this while researching open source private communication tools:

    https://github.com/WhisperSystems/BitHub

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

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

    crowning Well-known Member

    Joined:
    May 29, 2014
    Messages:
    1,430
    Likes Received:
    2,009
    Trophy Points:
    183
    I think it's a cool idea to automatically pay developers per commit on Github, but

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

    Bridgewater Well-known Member
    Foundation Member

    Joined:
    Dec 14, 2014
    Messages:
    183
    Likes Received:
    164
    Trophy Points:
    203
    I see your point. It still requires oversight or it can easily be gamed just like any other system. Seeing this attempt makes me appreciate the elegance of the SDGB proposal even more.
     
  30. raganius

    raganius cryptoPag.com
    Foundation Member

    Joined:
    Jun 11, 2014
    Messages:
    715
    Likes Received:
    1,158
    Trophy Points:
    263
    Great post, I am with thelonecrouton's suggestion of how things can work. Solarminer's initiative of starting a draft code is also awesome. Thanks guys!


    Also great this post:

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

Share This Page