Welcome to the Dash Forum!

Please sign up to discuss the most innovative cryptocurrency!

Lamassu Integration Delay - An ominous precedent?

Discussion in 'General Discussion' started by Macrochip, Mar 25, 2016.

Thread Status:
Not open for further replies.
  1. Macrochip

    Macrochip Active Member

    Joined:
    Feb 1, 2015
    Messages:
    221
    Likes Received:
    185
    Trophy Points:
    103
    Dash's Governance model is without a doubt the most sustainable and technically superior method to govern the development of a cryptocurrency. However we must not close our eyes to potential weaknesses.

    The recently revealed reason for the insufferable Lamassu integration delay, which boils down to a single developer with questionable motivations, is a perfect display of how the "Pay and Pray" method of budget funding is flawed. I had my concern about this the day budget proposals were introduced and it took a while but my concern finally came true: Currently we're relying on delivery of performance after an upfront payment has occurred.

    What's being created when a budget proposal is accepted is nothing short of a legally binding contract. But we lack any recourses or any possibilities of a refund. Paid is paid. Delivered or not. And that's the problem. The nature of most proposals ("Code for money") makes smart contracts (at least with current technology) almost useless, too: Let's assume a contractor made a proposal to build a decentralized marketplace. He shows us some nice mockups, test code, roadmap, milestones etc. Everyone is frantic about it and Masternode operators accept the proposal to pay 200 DASH/month for 1 year to the project. The developer promises to publish every update on a public github account. Now if we had a smart contract in place, all it could check for is this: "Does he upload code within the agreed upon interval? Yes - Pay the 200 Dash | No - Withold payment". There is no method to check for the codes uniqueness (copy-paste garbage?) and usefulness to the end goal. The dev could upload anything just to get paid.

    Currently the only way to check for useful code is having another human party review it. But even then, when the code is revealed to be garbage, that person couldn't stop the payments (and neither should she or anyone be able to do that).

    So we need to have a discussion on how to remove the component of dependency on goodwill and trust within our governance model. Any ideas? An Evolution DApp where users vote on these updates, maybe?

    Edit: Maybe I should clarify something: For some cases I mean for a solution other than voting the entire proposal down and stop payment altogether, even though my example doesn't reflect this, unfortunately. It's about paying less for receiving less. The proposal can still be good (like BTM integration), but should be foolproofed and avoid wasting resources. Other cases (like one time payments) are mostly about wasted funds with no ability to reclaim them. In any case: Payment should occur after delivery and validation of performance.
     
    #1 Macrochip, Mar 25, 2016
    Last edited by a moderator: Mar 25, 2016
    • Like Like x 9
    • Winner Winner x 1
  2. xdashguy

    xdashguy Member

    Joined:
    Feb 9, 2016
    Messages:
    86
    Likes Received:
    50
    Trophy Points:
    58
    The current governance model already supports this. If someone is untrusted / untested and with no track record, then masternodes should not approve their budget. That does not mean if someone is untested that they should never get a proposal. Those people should seek out trusted parties, such as the Dash Foundation, who can manage the proposal on their behalf.

    For example, if untrusted person named Bob submits a propsoal such as "I will make awesome Software X!" they can go to the dash foundation. Dash Foundation will submit the proposal and receive the funds and act as the final gatekeeper of the funds. If Bob does not perform them Dash Foundation does not pay. They can then ask the community what to do with the funds at that point.

    TLD: masternodes need to quit upvoting untested people. Instead, require trusted 3rd parties such as Dash Foundation to act as gatekeepers / escrow of funds for untested submitters.
     
    • Like Like x 2
  3. Miner237

    Miner237 Well-known Member
    Foundation Member

    Joined:
    May 28, 2014
    Messages:
    506
    Likes Received:
    223
    Trophy Points:
    213
    I agree with this. I paid DASH for a sticker from the person who made DASH Payment processor budget request. I never got any such said sticker. How can I expect this project which is currently funded to actually get build out when they can't even mail my sticker.....We need some checks and ballances... Sooner than later
     
    • Like Like x 2
  4. TroyDASH

    TroyDASH Well-known Member

    Joined:
    Jul 31, 2015
    Messages:
    1,251
    Likes Received:
    794
    Trophy Points:
    183
    Separating the approval of the budget and the distribution of the payment might be worth looking into. Similar to how we were discussing how we want to handle multi-month contracts in another thread. But even for a single-payout budget, because a budget approval is not a legally binding contract, it makes more sense for payments to occur after the services are rendered. However, if we implement such a thing, it needs to be difficult enough to prevent a payment that people can still have high confidence that the masternode network will act in good faith, but not so difficult that it is trivial.
     
    • Like Like x 1
  5. Sapereaude

    Sapereaude Well-known Member
    Foundation Member

    Joined:
    Apr 30, 2014
    Messages:
    191
    Likes Received:
    235
    Trophy Points:
    203
    So something like the proposal can be approved and the coins created, but will only be unlocked after the next budget?
     
  6. Miner237

    Miner237 Well-known Member
    Foundation Member

    Joined:
    May 28, 2014
    Messages:
    506
    Likes Received:
    223
    Trophy Points:
    213
    I know its hard to get ALL MNs to vote on these to begin with now but adding a second vote might be a good approach. 1st vote gives requestor confidence to keep on working their project 2nd vote gets them paid becuase they prooved they had something decent in the works and payout is approved by vote on display of work quality...
     
    • Like Like x 3
  7. stan.distortion

    stan.distortion Active Member

    Joined:
    Oct 30, 2014
    Messages:
    839
    Likes Received:
    492
    Trophy Points:
    133
    That was pretty much my thinking with it too, one round to approve funding and a second round on completion to judge satisfaction and release the funds, something like a multisig budget. Imho it's something better done with tools to enable that kind of format and to allow voting to decide what kind of format meets with approval rather than trying to enforce hard and fast rules that may limit what kind of proposals are put forward.
     
  8. SnowHater

    SnowHater Active Member

    Joined:
    Dec 25, 2015
    Messages:
    299
    Likes Received:
    221
    Trophy Points:
    113
  9. TheDashGuy

    TheDashGuy Well-known Member

    Joined:
    Dec 16, 2015
    Messages:
    1,232
    Likes Received:
    1,011
    Trophy Points:
    183
    how did I miss this great thread?
     
Thread Status:
Not open for further replies.