Are you 100% against a flat 15% diversion of funds to the DAO, and if not spent, returned idea? It's just that I see raising the funds upon approval of a project to be difficult to do. Especially if it'd be nice to get a project going asap. I know what you mean, I don't want funds blown out our ass to con artists for time immortal either, but it's good to have funds available to take advantage of things when the idea comes up.
Yes. You don't wander into the supermarket every day and hand them a fistful of cash just in case you might want something later. And you don't expect to ever see it back if you do. Particularly when the people who want this cash off you have repeatedly stated that under no circumstances should you ever get it back, despite the fact that it's coming out of the previously agreed reward schedule that we have based our investment on. $1400/day is immediately available. The voting process on anything would take the same amount of time anyway.
$1400/day Ok. Sounds a lot. But taking even taking insanely low day rates for contracting devs it sounds like peanuts to me: Split between say 10 projects ($140/day) /20 projects ($70/day) /100 projects ($7/day) So it would still have to be volunteer/help out on this cool project/ etc ie at todays value it would still be underfunded.
That's the point, we shouldn't necessarily be paying in full for a hundred simultaneously crap projects. We can vote to prioritise spending. $1400/day is a $4200/month salary for 10 full time devs.
Ok below the average US salary but quite high in other parts of the world http://www.payscale.com/research/US/Job=Software_Engineer_/_Developer_/_Programmer/Salary Also there will be more than that let's say you have ten devs working on the core (great!) then there is the android app ios app payment systems branding/marketing/advertising legal etc Some of which you'd deem to be bollocks. But part of competing unfortunately. Then $1400 still seems like peanuts. A lot of that could still be done as volunteer work. And as above mentioned above things are often cheaper elsewhere (we have global reach.) *edit and fixed fee projects with much lower maintenance retainers or similar would be different to salaries
The only people right now that are being skimmed are the miners, if you look at it from their point of view. They've been having 2.5% taken away (and they feel it each time) every month. Masternode owners have been gaining 2.5% each month, and frankly, each time the price goes up, more masternodes come on line, keeping the ROI pretty much the same, so except for the advantage of increasing the size of the MN network, MN owners really won't feel any difference. Miners have already come to grips that their share is shrinking. SO: Basically, we're creating a 3rd entity that hardly changes the status quo (miners know their share is shrinking for a year now, and MN owners have been pretty much getting the same amount and could expect the same amount in the future still) The effect will be fewer masternodes, but if we want more masternodes, all we have to do is lower the collateral to run one. So the only quiestion, as I see it, is what to do to keep rampant, unwise spending from happening. I still propose the following: Once essential projects are being funded, and nothing meets the standards according to voters for funding, AND a certain savings is set aside, all funds are distributed to Masternode owners and miners alike. This way, there is an incentive to save, but not a huge incentive, and there is an incentive to spend, if it looks more advantages for funds to be used on a project, they'll vote for it. I think, even if it's just to add infrastructure, because the infrastructure would obviously benefit the DASH network as a whole, which should bring value to the coin. I still think the idea that masternode owners doing the voting is a good idea because they are interested in the long term view, whereas miners do come and go, with many of them jumping from coin to coin. The rest of the community, who are indeed invaluable, can participate by promoting what they think should be done, giving argument, as we are doing right now, and generally making their ideas or support heard on the proposed project submission website forum threads. I think Masternode owners, with long term views of the future of the coin are highly unlikely to vote to distribute excess funds if they think they can increase the value of the DASH project by funding a project. But they will be equally unlikely to let funds sit on the blockchain when the lack of liquidity is a problem, or other issues start surfacing that we can't even envision right now.
This is a good point. But why do you feel we would be difficult to prioritize spending? Some projects are needed more than others and would be easier to get a consensus on. I've been saying, it should be built into the code that a review takes place after a certain timeframe. That way, if you are right, and Evan's model simply isn't working, we cut our losses and try it your way. If that doesn't work, we try a potential third proposal. Eventually we will be able to fine-tune it because I can almost guarantee mistakes will be made. I agree with the model as proposed, but if I'm wrong (it's happened before :tongue, we can go in another direction. Contract terms. Very important. The ability to make adjustments is key. I'm sure the final model will be a hybrid of everyone's valuable contributions.
I suppose returned funds could go into transaction fees over a couple of 100/1000 blocks. That way both miners and masternode owners get payed proportionately? Like sending a zero transaction with a portion of the reimbursement as transaction fee every block until done.
And, I would just like to reiterate, that it will be a very long time before we run out of useful projects to vote for. This fund will take us places that Bitcoin could only imagine. If someone is misusing funds, cut their support and fund a worthy effort. And if at some point in time we finally run out of useful contracts, then the ability to make adjustments, or simply stop the DGBB, will be there. I am very excited at the potential uses for this fund. Masternode owners are going to be busy for a long, long time...
Alright it's time for me to put my 2 duffs in... This reimbursement method could cause trouble. Think about it... There's a scheduled "bonus" for 500/1000/however many blocks, this attracts multipools and other exploitative miners who are just looking for the best $/day they can get. These miners are the most likely to cash out of their mining proceeds ASAP which could cause a downswing in price. These miners on our network reduce our DASH income and it's fiat value simultaneously. These miners have no interest in the project, just their own immediate profit, so why are we going to give them a piece of the pie that was set aside for the long term good of our currency? These are some of the dreaded "freeriders" we've been worrying about the past few pages. The only way to implement this plan successfully would be to make the disbursement amounts so negligible it wouldn't attract these types of miners, which would essentially just make the remaining balance a "delayed" payment for long term miners and node operators. In regards to the original debate, I am with thelonecrouton on this one... I see zero reason to allocate funds before we have a purpose for them. There is no need to create any excess funds that we have to worry about returing "fairly" when we could just avoid that situation altogether. Why couldn't we set a premise to allow a maximum of 15% to be diverted if there are enough (a set number) projects to utilize it? Example: fund a maximum of 10 projects that collect 1.5% each. 1.5% gets diverted directly from block reward once the vote to fund it passes, and not a moment sooner. This can be split up to fund smaller projects too... Example 2: 5 major projects claiming 1.5% each, and 10 lesser projects claming 0.75% each. Or 5x1.5%, 5x0.75%, 10x0.375% or something along those lines. With a little prioritization we can negate the whole "fair wealth redistribution" problem every other governing body on the planet has. If there are any typos please forgive me, I'm on mobile.
The welfare entitlement lie again? "We have no choice but to steal from the rich because how else will we get our free stuff?" Uh, work for it? Oh, yeah, that's not free... You actually have to do something... What a terrible suggestion... The suggestion that MN operators would hate the idea of their investment increasing by several orders of magnitude is stupid. Just hodling it won't do that, and MN operators, unlike most cryptotards, know this. Valid, useful projects will get funded by vote, welfare won't. Where's the problem? Oh, yeah, you want to mooch welfare so obviously you don't like that idea... The idea of a pool being faster is an outright lie. The pool has to accumulate in the first place, right? Are blocks suddenly being found faster if you stare at bfgminer hard enough? It's placebo to the small mind... Besides, even if it were true, taking a brief pause to actually think about where this money is going i a good thing. Except if you don't want people seeing that or thinking about that cuz you're porking it... 15% of a block is 15% of a block. Blocks are found so fast... It accumulates at the same rate whether you are staring at it or not. It's the "watched pot never boils" notion. You IMAGINE that it's faster because you were slow to think of the idea to spend it on. But the same time to accumulation still passed, you just weren't watching it happen... It gets done no faster because your proposal didn't even exist yet... The tiny illusion of an advantage that doesn't actually exist in the pork barrel approach is not worth all of the awesome REAL upsides to not doing the pork barrel approach. My primary arguments aren't even against the welfare supporters. It's about front-end control of the supply, which you cannot walk away from if you want your coin to be taken seriously by anyone, ever. And, the simplicity of implementation and enforcement that are only available in that model. The fact that welfare porkers are so desperate to mis-represent any transparent argument they can only displays the urgent need to stick with the same front-end control model that already exists in crypto for this obvious reason...
5KMI: Agreed. Just trying to figure out how such a reimbursement would work which indeed highlights how difficult such a thing would be. To me any excess should be just go to the dev fund.
Glad to see we're at least reading the same book. I wasn't trying to rip your idea apart as much as I ended up doing, it all just kinda spilled out at once as a general response to everything I've read on this topic the past few days.
Which is why the front end control model should not be abandoned. We don't accumulate a pork barrel for a miner that goes offline and then re-imburse it later if he doesn't come back online in a certain period of time... It's an enormous clusterfuck in the name of something that offers only placebo (fake) advantage.
I liked your venom directed at trolls on btctalk. In this debate I find it irksome and somewhat point clouding.
What if the 15% gets taken away and there is a record of how much coins each masternode has contributed to the funding pool. Then when it's voting time you have the options to don't fund anything since you don't like any projects but you will not be able to vote later on the projects approval. The DASH you contributed gets returned to you so no pork building up. If you find projects interesting you can vote yes and even distribute your DASH taken from the 15% as you would like (maybe 3 DASH for this project and 8 DASH for this one). Projects that get the green light get the DASH from the yes people. You must spend the DASH if you vote yes. Basically this clears the pork thing and somehow lets you fund what you find interesting WHEN you find it.
Golly, I wish I got money for nothing... Its a circular argument, too... "I think all the excess funding for the dev fund should go to the dev fund." Wha...?
I'm pretty sure that record exists, it's called the blockchain. But, it still doesn't change the fact that the advantage you imagine is still imaginary...
Dancing around a sugar coating only takes longer to get to the point. Mis-representing it as venom displays your desire for distraction, not mine.
It's not just the dev fund. I'm talking a bout a project achieved for less than allocated. What do you do with the excess? Reimburse? If so how? Or just put it back in the dev fund where it then can be reallocated to another project
Not distraction. Clear concise thinking. I find the ranting detracts from your points. But that is my opinion.
Still thinking like a budgeteer... If we have front-end control, it costs what it costs. The doer of this project doesn't come back and say "Oh jeez I have $5 left." It's spent, we voted that it was worth X, we paid X because it was worth X to do it, that's the end of it.
Several pages of failing to stay on topic are much more of a distraction than my hyperbolic examples, which are designed to bring focus, and do so quite well.
Imaginary advantages are not worth disposing of the front-end control model ubiquitous throughout crypto for damn good reason I think the current arguments on this topic are coming from: 1) people who don't realize that they are promoting an imaginary benefit at great detriment 2) pork barrel welfare moochers I believe 99% fall into category #1.
This is just reducing the plan down to a blockchain integrated direct donation model. I believe we can do this already without any voting. Someone correct me if I'm wrong but I believe MN operators do have the option to divert x% of earnings to a given address.
Fixed your attack for you. Also, Already explained it several pages ago, before all these off-topic distractions of budgeteers who can't wrap their head around the fact that their suggestions are imaginary and detrimental. It's been at least 3 pages of herding cats with the palsy since I nailed it.
