Quote from: wpalczynski on March 17, 2015, 06:42:05 PM

Quote from: eduffield on March 17, 2015, 06:38:05 PM

Quote from: wpalczynski on March 17, 2015, 06:27:13 PM

Quote from: the-baker on March 17, 2015, 06:26:10 PM

Quote from: wpalczynski on March 17, 2015, 06:22:46 PM

Quote from: Minotaur26 on March 17, 2015, 05:51:52 PM

Quote from: wpalczynski on March 17, 2015, 05:51:08 PM

Quote from: oblox on March 17, 2015, 03:24:49 PM

Quote from: bluebit25 on March 17, 2015, 03:22:30 PM

So the lead dev has a private key which lets him control all the MasterNodes? Why does he need to control all MasterNodes? In the future, will he be in control or is this just temporary and if so how long will this continue?

No, he does not. There is a private key for engaging the spork but that's it. This allows us to prevent forks for the time being while bugs are getting troubleshooted on mainnet when new features get rolled out.

If he chose to for whatever reason, could he crash/stop/impede the DRK network with this "masterkey"? What exactly does this key allow him to do?

He is refering to the Spork, is a message that is send out to the network so that you can activate, deactivate a hard fork. It works similar to the way alerts work in BTC. Is probably one of the coolest things on DASH/DRK and he chooses to troll about it. It poses absolutely no risk and gives no power, it just allows a mature network to innovate and do hard fork after hard fork in the name of progress, like DRK has been doing to implement its features.

From the OP:

Multi-Phased Fork Implementation (aka the Spork)
In response to unforeseen issues with the rollout of RC3, the Darkcoin development team created a mechanism by which updated code is released to the network, but not immediately made active (or enforced). Communication is sent out to users informing them of the change and the need for them to update their clients. Those who update their clients run the new code, but in the event of errors occurring with that new code, the clients blocks are not rejected by the network and unintended forks are avoided. Data about the error can then be collected and forwarded to the development team.
Once the development team is satisfied with the new codes stability in the mainnet environment - and once acceptable network consensus is attained - enforcement of the updated code can be activated remotely. Should problems arise, the code can be deactivated in the same manner, without the need for a network-wide rollback or client update.
This innovation allows for far smoother transitions than in the traditional hard fork paradigm, as well as the collection of test data in the live network environment.
We set out with the intention of calling this method of updating the Soft Fork, but the Darkcoin community quickly dubbed it the Spork and the name seems to have stuck.

Thanks for the answer.

With other coins, should the community (read miners and masternodes) choose not to accept whatever new aspect the developer(s) are trying to implement in the existing coins code they could simply not upgrade to the latest version put out by developers and run the current version of the code as they have done since the last update they agreed to apply. This would allow the network to continue to operate normally although perhaps temporarily without the support of the developers since they could not reach a consensus with the miners.

I am understanding from your answer, if I understood correctly, that this Spork would in no way provide the DRK dev with the ability of subverting the miners ability to operate as is without accepting and applying the new code?

Basically if the DRK dev tried to implement a code change which was greatly unpopular among the community, miners, etc. this Sprok could not be used in any way to force everyone (miners, masternodes) to accept these unpopular changes?

Thanks in advance.

Well, the same logic applies as in the Bitcoin example you made: If the miners don't like the new version, they won't install it, and thus there will be nothing for the key to activate

But this private key/backdoor/troubleshooting tool is already imbeded in the DRK architecture. I'm trying to understand this. Could you please provide a binary answer to my last question?

It's exactly the same as the Bitcoin network, it's like the developers adding a hardfork, the miners must support it. The only difference is it can be reversed back to the prior way the code was before the hardfork without an update.

There's no magic key that allows debugging or anything like you're saying.

Thanks for your answer eduffield. I can count on one hand the amount of DRK members here who are willing to sincerely answer questions about DRK without accusing people of trolling, being illiterate and other ad hominem attacks.

I understand it now. Its just a tool for rolling back an unsuccessful update automatically and centrally rather then trying to reach out to each individual node and co-ordinating the effort.

exactly