I've had time to reflect on the changes I posted, the things /GJ noted, and I've come to some conclusions. People are not going to like what I'm about to say, but I'm going to say it anyway to get it off my chest.
6. Responsibility You are responsible and the rest of the community. If you say that we have to implement something, we will. That is what’s happening with DIGI, but Geert-Johan looks at the code before he implements something. And in this case he saw that some things didn’t add up, things that could’ve caused bigger problems. Bigger than we’re facing now. But Geert-Johan can’t just say that something isn’t right. He needs to present proof and discuss this with the person that delivered the code, in this case Fuse. After this conversation it was decided not to implement this code, but further development was chosen.
It's the exact reason I asked Rijk to double-check the code on his end(/GJ). I knew the code was alpha. It wasn't catastrophically incorrect though.
The problems Rijk mentions is that the line in the code we used to adjust the difficulty(albeit incorrectly) would have caused the past blocks on chain to not sync properly if you resynced. That portion of code had nothing to do with algorithm, as noted by /GJ in IRC chat. So the answer to this is to not change it from it's original version. DIGI would have reacted the same way with modified values in this block of code(the correct difficulty adjustment code):
if (nActualTimespan < (retargetTimespan - (retargetTimespan/4)) ) nActualTimespan = (retargetTimespan - (retargetTimespan/4));
if (nActualTimespan > (retargetTimespan + (retargetTimespan/2)) ) nActualTimespan = (retargetTimespan + (retargetTimespan/2));
My error wasn't catastrophic, and it could have been easily corrected. DIGI would still react similar to the graphs I provided. We can move past this "it's done when it's done, so stop asking us about when it will be done" mantra that we've heard for 4 months now.
/GJ could go back to working on the simulator, and proving it's results against a testnet's results. This is still paramount to it's credibility in my mind. Yes, math is math and it will never be wrong... unless it is wrong or there are variables not introduced. Relying strictly on an unproven simulator is as blind-sighted as implementing a community member's code without looking over it first.
7. Decentral If Geert-Johan didn’t look at the code, or hadn’t discovered that the code wasn’t good, we would’ve implemented it. Because the community asked for it, it is decentral, so the majority decides. Very simple. Realize that this comes with huge responsibility. Everyone has that responsibility, you help decide Guldencoin’s future.
No, you wouldn't have. You would have always had him look at it. That's what a smart dev would do. Additionally, if the code was in question, and a solution was needed to stem the effects of CM, the DIGI devs could be contacted to help with the custom changes. They openly announce their willingness to help coins implement DIGI. It's not because they get paid for it, it's because they know it's the algorithm that best mitigates multipool influence. But this was rejected by /GJ on a few separate occasions because "the change is not difficult". If it's not difficult, why not make it happen?
Additionally, people are correct in that no difficulty algo right now will do that completely. No difficulty algo will do that in the foreseeable future of crypto. Yes, you could move to CPU/GPU based mining or POS, but you lose a considerable amount of community in making those changes. DIGI buys us time, and aligns us with the current era of MP mitigation. I feel like we're sitting around waiting for someone, maybe /GJ, to develop the next best algo ever. But how long is that going to take, and is NLG going to be the guinea pig for the implementation?
But the real question here is this- if /GJ is checking community submitted work, who is checking him? This presents us with a single point of failure and acceptance. Who checked /GJ's DGW3 code results when the decision was made to implement it? I'm going to guess it was /GJ. There needs to be a second set of eyes in the code team. My code errors prove that. There always needs to be someone to check the other person's work. Who is the backup in the dev team?
8. What now? Geert-Johan is continuing work on the simulator and will test DIGI too, if the outcome says that DIGI is the solution, that will be implemented. If DIGI is not the solution, Geert-Johan will continue the development of the custom algorithm. This is the path that we are following and is, according to us, the only solution. Note, according to us. Other developers can look for a different solution, in the end the community decides.
Unfortunately, it's not that simple. For anything to be taken seriously now, it will have to be proven by the simulator. The simulator that hasn't been proven against testnet data yet. But the problem lies in that the simulator is in GO. Sure it's a hop, skip, and a jump away from C++, but how many people honestly know GO in this community besides the person who wrote the simulator? So where does that leave us? Again... with a single point of failure and acceptance. We can't just drop some code in to the simulator and test things. We need to port it to GO ourselves, or present it to /GJ to port it.
There's no community involvement when the community isn't able to be involved. Yes, /GJ is a great coder... we know that. But aligning the code so he is the only coder is not the way to go. So yes, learn GO, outsource a dev, etc etc etc.
Fact of the matter is that /GJ had 4 months to focus on algo development. Instead of the algo change, he coded a simulator, still unproven, with an algo we've already proved doesn't work. Wouldn't it have been more productive to start with something that you would want to test, rather than something you want to move away from? DGW3 doesn't work. We don't need to know why after 4 months of dealing with it's failure. Move on to something else that does.
9. Communication There are a lot of questions about this, with most frequently: When is it done? I can understand that, but unfortunately the answer is short: when it’s done. That’s the way it is. I have asked Geert-Johan to just focus on development and not on updates. He can’t say when it’ll be done, but he will solve it. Maybe other developers can give this information and present a specific roadmap.
Actions will always speak louder than words.
It took my team 1-2 weeks to change the code(yes, slightly incorrect), set up 2 pools, confirming nodes around the world, a block explorer, and test mining on a testnet. 24Kilo's 14yo son wrote a pearl script to pull data from the debug.log files to parse block data before we had a block explorer, giving us early block difficulty change data. In two weeks we were able to provided more direct effort towards making a change than we've seen in 4 months of CM rape. We got tired of waiting and we acted. I'm glad we did, regardless of the final outcome. If my team lost face with our inability to provide 100% correct code, I'm ok with that.
So take my post as being overly critical, or angry, or short-minded, or whatever you want to take it as. To me, it's just me being honest to myself and saying what I'm thinking. Some people may not like that, but like I said, I'm in it for the long haul. Like me or hate me, my pool will continue to run, my physical coins will continue to sell, and the Criptoe team will continue to try to provide additional support to NLG in any way possible. Just don't expect us to accept inaction... we've been waiting for 4 months too long now for this change.
-Fuse
