April 2016 Budget Proposal

Tnx, tf !
How can < I > earn MN status?
...Gosh ! I hope there's Not 'the good 'ole boys' !
I am hoping this is a community kinda thing... We all need to eat. Make use of clothing and have shelter against the WX.
P2P can help us do this without being bled dry by overlords manipulating our existence.
... the greatest respect for ed... and develop those 'fiat access ramps' !!!
Everyone should utilize DASH as much as possible to bring it into strength, and reality.
...there shall be 'pushback'.
Best rc
Grizzled? Yah, I qualify. Been there, am that ! lol
 
Tnx, tf !
My commitment is presently devoted elsewhere. Favorably...

I would put my fiat where my mouth is, at 1k, here in front of the community... if such a thing as partnerships in a MN are considered ?

Tf, I am a mechanic and construction worker, debilitated, now. I strive to make my word good. And I do believe in ed's concept.

Does this forum do PM's ? Anyone may contact me, if such a mechanism exists, and we may discuss options...

As Larry sez, Get r dun !

:)
rc
 
rustycase said:
Tnx, tf !
My commitment is presently devoted elsewhere. Favorably...

I would put my fiat where my mouth is, at 1k, here in front of the community... if such a thing as partnerships in a MN are considered ?

Tf, I am a mechanic and construction worker, debilitated, now. I strive to make my word good. And I do believe in ed's concept.

Does this forum do PM's ? Anyone may contact me, if such a mechanism exists, and we may discuss options...

As Larry sez, Get r dun !

:)
rc
Click to expand...

yes
there are a couple of shared /pooled services
check here
https://dashpay.atlassian.net/wiki/pages/viewpage.action?pageId=1867885

pages does pm
 
TheDashGuy said:
We need alot more discussion on this honestly.

Whats up with the reasoning behind all these changes core team? I'm not so sure we all "want" contracts in place honestly...

Can we ask the network in a poll if they want to add irrevocable contracts to dash?
Click to expand...

So, does core team not care about discussing this? I don't like to keep busting people's balls over this but I can see it already. The topic gets ignored and then Version 12.1 gets railroaded through fast and dirty before any further dialogue happens, and we end up with a very controversial feature that will be even harder to un-do or modify later if we needed to.
 
TroyDASH said:
So, does core team not care about discussing this? I don't like to keep busting people's balls over this but I can see it already. The topic gets ignored and then Version 12.1 gets railroaded through fast and dirty before any further dialogue happens, and we end up with a very controversial feature that will be even harder to un-do or modify later if we needed to.
Click to expand...

I think 99% of people will worry about irrevocable contracts if they see them happen. Right now there is ZERO reason to believe that the devs aren't including some sort of "out" into the code. Sure, it would be better if they commented here and assuaged people's fears, but honestly, what's the harm in just waiting to see what gets released onto testnet? If it's not something you like, complain about it then!

I realize I've been around awhile and some of y'all are fairly new. But please let me assure you that Evan has always been very responsive to the community and has changed course several times in response to community feedback, even once he already had code on testnet.

Completely irrevocable contracts would be bad. But let's at least see what they end up coding, instead of pre-emptively freaking out.

Just my personal opinion.

P.S. You also run a real risk of eventually being seen as the guy who panics before there's a need to panic. Then one day when you really do call somebody out on something urgent, people will just think "meh, he always jumps the gun on everything."
 
TroyDASH said:
So, does core team not care about discussing this? I don't like to keep busting people's balls over this but I can see it already. The topic gets ignored and then Version 12.1 gets railroaded through fast and dirty before any further dialogue happens, and we end up with a very controversial feature that will be even harder to un-do or modify later if we needed to.
Click to expand...

I'm kinda burnt out on carrying my pitch fork, wanna hold it for me?

I totally agree but it seems we are but users of a system we do not control at this point, just let them do whatever they please and let's watch it play out.

Either way we are on the verge of some crazy stuff...
 
We definitely do want contracts. Denying a take at it is completely throwing away the opportunity to innovate in one of the most exciting applications of blockchain.

And I'm not saying this because "everyone" else is doing it, I'm saying it because we are doing it our way, based on our need, based on Evan's vision. The main reason this is happening is because of the soap opera episode in January around the Terpin proposal, and now the LP proposal.

When you enter an agreement that is not bound by regulatory law, you only stake your honour and your word. Humans are too flawed for that. A brilliantly designed decentralised monetary system isn't.

And that is what the core team is thriving for.


.
 
yidakee said:
We definitely do want contracts. Denying a take at it is completely throwing away the opportunity to innovate in one of the most exciting applications of blockchain.

And I'm not saying this because "everyone" else is doing it, I'm saying it because we are doing it our way, based on our need, based on Evan's vision. The main reason this is happening is because of the soap opera episode in January around the Terpin proposal, and now the LP proposal.

When you enter an agreement that is not bound by regulatory law, you only stake your honour and your word. Humans are too flawed for that. A brilliantly designed decentralised monetary system isn't.

And that is what the core team is thriving for.


.
Click to expand...

Vision =/= Implementation


Lets hope Evan nails it.
 
TheDashGuy said:
Vision =/= Implementation


Lets hope Evan nails it.
Click to expand...

Vision precedes implementation, so I don't really see where you're coming from. It's great to discuss the subject. It's even better to propose objective solutions. It's gold to commit changes to the code. How many features were proposed that failed to see the light of day?

If you know Xcoin/DRK/Dash's history, you know how many "impossible" feature Evan has nailed. Now the dev team keeps growing with numerous super talented guys. Also, how time and time again the direction of this project went with the community voice and opinion.

TroyDASH - everything can be reversed. You just need network consensus, plus Spork technology makes this a breeze. Others fear hard-forks, we eat them for breakfast.

I'm not hoping, just patiently waiting.

.
 
yidakee said:
Vision precedes implementation, so I don't really see where you're coming from. It's great to discuss the subject. It's even better to propose objective solutions. It's gold to commit changes to the code. How many features were proposed that failed to see the light of day?

If you know Xcoin/DRK/Dash's history, you know how many "impossible" feature Evan has nailed. Now the dev team keeps growing with numerous super talented guys. Also, how time and time again the direction of this project went with the community voice and opinion.

TroyDASH - everything can be reversed. You just need network consensus, plus Spork technology makes this a breeze. Others fear hard-forks, we eat them for breakfast.

I'm not hoping, just patiently waiting.

.
Click to expand...

Good luck reversing it after we have already established contracts that we told our clients were immutable. What message would that send?

What we *need* is a way to protect against or mitigate scenarios like the Terpin fiasco. What we *don't need* is to rush to the first solution we see without thinking about the unintended consequences. Again, a "contract" that is binding on one party but not the other, isn't a contract. All you have to do is point out *ONE* situation where the network should be able to exit a contract, which is trivially easy, to completely invalidate the idea that we need to bake immutable budgets into the protocol. Clearly we should do something but immutable budgets isn't the answer.
 
TroyDASH said:
Good luck reversing it after we have already established contracts that we told our clients were immutable. What message would that send?

What we *need* is a way to protect against or mitigate scenarios like the Terpin fiasco. What we *don't need* is to rush to the first solution we see without thinking about the unintended consequences. Again, a "contract" that is binding on one party but not the other, isn't a contract. All you have to do is point out *ONE* situation where the network should be able to exit a contract, which is trivially easy, to completely invalidate the idea that we need to bake immutable budgets into the protocol. Clearly we should do something but immutable budgets isn't the answer.
Click to expand...

We're not rushing anything at all. 12.1 is due preliminarily for August and that is exactly what testnet is for. It was exactly the Terpin "fiasco" that sparked Evan's imagination, just like all previous road bumps. Sporks were created exactly because of the RC1 RC2 and RC3 forking. Failure is a brilliant seed for innovation.

I don't think you fully understand how this works. Nothing is immutable. Everything can be reversed. Even the blockchain itself. Plus we have Sporks that make it easy peasy. These contracts are intended to be irrevocable, so in a sense yes, immutable you could say, given the specific network state. That does not mean if something goes wrong it's a doomsday scenario.

If someone was able to subvert the system, Spork is activated, protocol reversed, and the proposal nuked. That is certainly not nice, ideal, fun, or even wanted, but anyone is always welcome to keep that fork alive is they so wanted.

Again, it is exactly because an honourable contract was made with a contractor, and the project was unable to keep it's word, that this is happening. The only fiasco here is being unable to keep our end of a deal with someone.

.
 
guruvan said:
There is no reason this needs to be the case! Default server lists are easily updated in the electrum-dash client to add new volunteers, and servers interconnect via IRC to share their connection information (so each server can deliver this info to clients).

The current Electrum-Dash server database takes up to 24hrs to produce on SSD, and server operation is not uncomplex. This presents a significant barrier to new potential server operators.

In addition to producing a highly scalable, highly available network, we're producing ready-to-run databases, server docker images & start-scripts, and all the configuration for more operators to more easily run their own servers. Databases are already available via IPFS, and we'll have all the tools posted to github this week.
Click to expand...
May I have any progress update for all the tools (ready-to-run databases, server docker images & start-scripts, and all the configuration for more operators to more easily run their own servers) posted to github ? How to access the database via IPFS ?
Possibly you may posted somewhere but I don't see it. Thanks.
 
yidakee said:
We're not rushing anything at all. 12.1 is due preliminarily for August and that is exactly what testnet is for. It was exactly the Terpin "fiasco" that sparked Evan's imagination, just like all previous road bumps. Sporks were created exactly because of the RC1 RC2 and RC3 forking. Failure is a brilliant seed for innovation.

I don't think you fully understand how this works. Nothing is immutable. Everything can be reversed. Even the blockchain itself. Plus we have Sporks that make it easy peasy. These contracts are intended to be irrevocable, so in a sense yes, immutable you could say, given the specific network state. That does not mean if something goes wrong it's a doomsday scenario.

If someone was able to subvert the system, Spork is activated, protocol reversed, and the proposal nuked. That is certainly not nice, ideal, fun, or even wanted, but anyone is always welcome to keep that fork alive is they so wanted.

Again, it is exactly because an honourable contract was made with a contractor, and the project was unable to keep it's word, that this is happening. The only fiasco here is being unable to keep our end of a deal with someone.

.
Click to expand...

Rushing might not be the right word. The point is, from what I am able to gather there has been little or zero effort on the part of those who are actually developing the code, to discuss this here. All I am hearing are assertions about this is what we need, this is what is happening.

Something like this is not a problem that can really be caught in testnet. It's not a bug, it's a design flaw that is going to get swept under the rug until we eventually run into one of those scenarios where the network needs to have a way to exit a previously-approved multi-month budget. In the meantime when we are providing info to clients, are we telling them that their contracts are immutable? Having subsequent protocol updates or using sporks is great for dealing with unexpected problems, but it's a terrible plan to deal with something when we already know that this is going to come up inevitably if we implement budget prioritization with no exit method.
 
TroyDASH said:
Rushing might not be the right word. The point is, from what I am able to gather there has been little or zero effort on the part of those who are actually developing the code, to discuss this here. All I am hearing are assertions about this is what we need, this is what is happening.

Something like this is not a problem that can really be caught in testnet. It's not a bug, it's a design flaw that is going to get swept under the rug until we eventually run into one of those scenarios where the network needs to have a way to exit a previously-approved multi-month budget. In the meantime when we are providing info to clients, are we telling them that their contracts are immutable? Having subsequent protocol updates or using sporks is great for dealing with unexpected problems, but it's a terrible plan to deal with something when we already know that this is going to come up inevitably if we implement budget prioritization with no exit method.
Click to expand...

There is no talk about it because everything is still in Evan's head and on his private computer in embryonic state. He's just started to build the thing. So I guess there is nothing to do but speculate. I'm sure Evan has this in mind as this is both relevant and obvious. In the meantime, everyone else is busy doing what they're doing. This is definitely a valid point. And the more discussion on the subject the better, especially on possible implementation solutions.

.
 
yidakee said:
There is no talk about it because everything is still in Evan's head and on his private computer in embryonic state. He's just started to build the thing. So I guess there is nothing to do but speculate. I'm sure Evan has this in mind as this is both relevant and obvious. In the meantime, everyone else is busy doing what they're doing. This is definitely a valid point. And the more discussion on the subject the better, especially on possible implementation solutions.

.
Click to expand...

Point taken, although I do have to question the order that these things are happening. It sounds to me like this is way further along than in an embryonic state in Evan's head -- apparently they are on track to release this in testnet in just 2-3 weeks? It might be better for the developers to have asked for more feedback before they started implementing. Based on what I heard in Evan's interview from last week, the implementation of this is actually going to be a bit different than anything I have even seen here on the forum. If it turns out the masternode operators don't like the direction they went in their development, then the dev team would have just wasted a lot of time and effort.
 
TroyDASH said:
Point taken, although I do have to question the order that these things are happening. It sounds to me like this is way further along than in an embryonic state in Evan's head -- apparently they are on track to release this in testnet in just 2-3 weeks? It might be better for the developers to have asked for more feedback before they started implementing. Based on what I heard in Evan's interview from last week, the implementation of this is actually going to be a bit different than anything I have even seen here on the forum. If it turns out the masternode operators don't like the direction they went in their development, then the dev team would have just wasted a lot of time and effort.
Click to expand...

I beg to differ. Masternode operators do not control the direction of development. They do control how project proposal funds are allocated.
At any point can anyone, anywhere, fork the project and develop their own version of Dash based on whatever primitives they believe are best.
For example, anyone could even propose funding from them to pursue that route. All you really need is network majority. So ultimately, it is still the miners who decide where the longest chain goes.

Evan, as the founder and main developer of this project is not directly accountable to anyone. That does not mean he is a "dictator" and just does what the heck he feels like it. He's steered away from his path in favour of the community voice in the past. He proposed a vote on the block size increase through DGbB, and respected the vote. But ultimately, this is his baby.

Why not wait for testnet and do what all of us love to do? Try our best to break it! Find logic flaws. Engage in debate directly with devs. That's how things are actually built around here. Not that talk isn't relevant, but going round in circles speculating doesn't achieve much.

.
 
yidakee said:
I beg to differ. Masternode operators do not control the direction of development. They do control how project proposal funds are allocated.
At any point can anyone, anywhere, fork the project and develop their own version of Dash based on whatever primitives they believe are the best.
For example, anyone could even propose funding from them to pursue that route. All you really need is network majority. So ultimately, it is still the miners who decide where the longest chain goes.

Evan, as the founder and main developer of this project is not directly accountable to anyone. That does not mean he is a "dictator" and just does what the heck he feels like it. He's steered away from his path in favour of the community voice in the past. He proposed a vote on the block size increase through DGbB, and respected the vote. But ultimately, this is his baby.

Why not wait for testnet and do what all of us love to do? Try our best to break it! Find logic flaws. Engage in debate directly with devs. That's how things are actually build around here. Not that talk isn't relevant, but going round in circles speculating doesn't achieve much.
Click to expand...

Is that correct though? If the masternodes refuse to update their clients to the protocol version that the devs release, then wouldn't that be the final say?

Definitely yes, if the testnet release is the equivalent of opening it up to feedback, then we'll do that, but I just think it would be a better usage of everyone's time if the development direction was hammered out *first*, and then implementation, and then bugfixing. Not implementation first, and then development direction and bugtesting at the same time.
 
yidakee said:
I beg to differ. Masternode operators do not control the direction of development. They do control how project proposal funds are allocated.
At any point can anyone, anywhere, fork the project and develop their own version of Dash based on whatever primitives they believe are best.
For example, anyone could even propose funding from them to pursue that route. All you really need is network majority. So ultimately, it is still the miners who decide where the longest chain goes.

Evan, as the founder and main developer of this project is not directly accountable to anyone. That does not mean he is a "dictator" and just does what the heck he feels like it. He's steered away from his path in favour of the community voice in the past. He proposed a vote on the block size increase through DGbB, and respected the vote. But ultimately, this is his baby.

Why not wait for testnet and do what all of us love to do? Try our best to break it! Find logic flaws. Engage in debate directly with devs. That's how things are actually built around here. Not that talk isn't relevant, but going round in circles speculating doesn't achieve much.

.
Click to expand...
I disagree with you on this one. Masternodes have the final say in anything, be it development, marketing, or anything else. That's why it's called Decentralized "Governance" by Blockchain. Evan gave up a lot of power creating this system, and as a DAO, we are better for it. The MN operators are the stewards of the project, they will outlive all of us. Anyone is free to voice their opinion on future course, and if the Masternodes agree (and it is possible to be done) it MUST be done by someone. That is the whole point of the governance system.

We just had a long chat on Slack about this between community and core members.

For Dash Nation to succeed, we must respect our decision-making process. Otherwise, it's just a sham.
 
You must log in or register to reply here.
Back
Top