Fuse makes VALID points. From reading how things have been posted lately, I feel he's been shunned and targetted for trying to help, and he's the only one from the outside trying to help!!! So what gives?
I'm not going to deny that the way the errors were presented weren't a little upsetting to me and my team. When /GJ and I were discussing the issues in IRC, he asked if we should make a post about not moving forward with the change yet. I suggested that we state that the code still needed to be worked on, improved and tested, and that my team would provide full support with testnets, hashrate, etc. What the community got was a little different from that. My team wasn't exactly happy about it. We worked to provide support when support was lacking, and we made a single line code mistake that ended up causing this delay.
That being said, I don't see it as a shunning so much as another excuse to delay a change. /GJ said himself the only reason he's going forward with it is because the community demanded it:
Understand that if it were up to me, we'd take more time to develop and test a better solution. But it seems the majority of the community wants to try Digishield..
A better solution. Not DIGI. A better solution.
I understand that things take time. I understand that things need to be tested,
including the validity of the simulator. But you aren't going to find a more effective method of dealing with CM any time soon that doesn't involve a massive overhaul of the entire codebase, or an extremely long period of testing. If you want to test DIGI against the simulator, so be it. I'm all for seeing if it can accurately simulate
real mining. But don't delay what has already been delayed for 4 months while we wait for a tool that won't fix the issue. And let me be clear- I wholeheartedly want the simulator to succeed. But it's a long term project that doesn't need to be mutually exclusive of the algo change. Fix the mistake that was made when DGW3 was implemented, and work on whatever you want to work on for the future of the coin. In the meantime, without a code change, we're dealing with this still:
While the code we uploaded had a small error, the algorithm was in fact providing results. If the devs don't trust the results, I suggest they start up a testnet and test it themselves. Or the community. Or anyone for that matter. Real mining data that can be quantified and examined in real-time by anyone. Just don't sit around playing it ultra-conservative because you want to wow the community with some new innovative idea or tool. Push forward, make the changes that need to be made and refocus on the your future goals. This change doesn't need to be the last change this coin ever makes. If we have to push out another update at a later time, so be it, but at least we didn't sit around while 45 million more NLG get mined by CM.
Implementing Digi in NLG isn't even that much work, no need to ask the Digi dev's to do that for us.
What IS a lot of work is proving that Digi will actually protect us from a jumping pool, that's why we need to run these simulations. We need prove that the algorithm adjusts properly, and we must be able to explain HOW and WHY the algorithm is adjusting properly.
Two things I take from this post, and I could be extremely wrong, but I'm going to take a stab at it anyway. First, DIGI isn't hard for /GJ to implement. So he could have it done now
if he really wanted to. Second, there is already live blockchain data out there, and my "erroneous" testnet data, that proves DIGI works to mitigate jumping pools like CM.
Why delay if you have both parts of the equation? Just solve for X already.
-Fuse
Here is a post I found where /GeertJohan wasn't happy about Digishield. We should have more faith in this dev team.