Topic: NA - page 308. (Read 893613 times)
https://forum.guldencoin.com/index.php?topic=508.msg9476#msg9476 Almost there, I think 
--------------------------------------------------------------------------------------------------------------
Nice one!
--------------------------------------------------------------------------------------------------------------
In need of a cool, new watch to keep track of time in 2015? Buy a wooden one at https://houtenhorloge.nl!
https://houtenhorloge.nl
https://houtenhorloge.nl
Nice one!
In need of a cool, new watch to keep track of time in 2015? Buy a wooden one at https://houtenhorloge.nl!
http://plaatjesdump.nl/upload/39a01d55bfcb1bb150859eab6a208769.png
https://houtenhorloge.nl
http://plaatjesdump.nl/upload/39a01d55bfcb1bb150859eab6a208769.png
https://houtenhorloge.nl
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.
10. Summary
We are a tiny part of Guldencoin, developing our own way for Guldencoin. We are solving the multipool issue, but we can’t say how long it will take. Guldencoin is decentral, we listen to the majority.
Everyone can help find a solution.
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.
10. Summary
We are a tiny part of Guldencoin, developing our own way for Guldencoin. We are solving the multipool issue, but we can’t say how long it will take. Guldencoin is decentral, we listen to the majority.
Everyone can help find a solution.
@Fuse
Because you have the technical knowhow I wonder if you can help me to set op a roadmap voor delivering the algo change? What has to be done? How much time it will app. cost etc. We can publish this right here in this thread and also at the official forum.
@Rijk
People are getting frustrated about the lack of communication. There is not enough insight in the progress and some don't know how to contribute. Maybe some open todo's can be published and discussed by community in advance. Also, many are tired of waiting, it's like the train stopped in september and we still wait for it to take off. Also remember the crowd funded IOS wallet. There is impatience and damage will happen if there is no action asap. I the mean time people invested heavily in money (remember the buy support at 800, 900 and 1000 sats) and also in time, if they hook off the community will be decimated.
With this message I hope we will have a roadmap soon which make discussion and insight in progress more open/clear. We, the community, have the right to get informed correctly and on a regularly basis. I understand how the Guldencoin (dev) team operates and yes, no updates only results matter. But not in this case. This is something of more importance, the basis of the whole Guldencoin project, the network, is a matter of us all.
Hope you respect this input and follow the right direction.
-- Big Snip --
LTEX have you got my 20k NLG ready?
It's here: GaDigikXYG4WFZKVCUcLvb5M4TZA81qr2g
I'll send you the private key by PM once I'm confident I actually lost the bet...
Amazing! This is what I like of this community, great and honorable!
Wonder who wins and how this turns out
LTEX you can use the 20k towards your project if it will help as a extra bonus for your distribution plans.
You guys keep me amazing
Hope the algo change will come quick after which we can work together to make this project full-grown! 
-- Big Snip --
LTEX have you got my 20k NLG ready?
It's here: GaDigikXYG4WFZKVCUcLvb5M4TZA81qr2g
I'll send you the private key by PM once I'm confident I actually lost the bet...
Amazing! This is what I like of this community, great and honorable!
Wonder who wins and how this turns out
LTEX you can use the 20k towards your project if it will help as a extra bonus for your distribution plans.
-- Big Snip --
LTEX have you got my 20k NLG ready?
It's here: GaDigikXYG4WFZKVCUcLvb5M4TZA81qr2g
I'll send you the private key by PM once I'm confident I actually lost the bet...
Amazing! This is what I like of this community, great and honorable!
Wonder who wins and how this turns out
-- Big Snip --
LTEX have you got my 20k NLG ready?
It's here: GaDigikXYG4WFZKVCUcLvb5M4TZA81qr2g
I'll send you the private key by PM once I'm confident I actually lost the bet...
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.
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):
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.
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?
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.
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
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):
Code:
if (nActualTimespan < (retargetTimespan - (retargetTimespan/4)) ) nActualTimespan = (retargetTimespan - (retargetTimespan/4));
if (nActualTimespan > (retargetTimespan + (retargetTimespan/2)) ) nActualTimespan = (retargetTimespan + (retargetTimespan/2));
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
LTEX have you got my 20k NLG ready?
Looks good, Bram!
-Fuse
-Fuse
Thanks fuse!
I'm sorry I can not join the conversation it's too difficult for me
No worries, mate... google translate only goes so far
I'm trying daily to keep up with the Gulden forum posts in Dutch... I know how you feel!
-Fuse
sorry, I 'm going to do now in English in this topic
it's time to sleep bye bye
Looks good, Bram!
-Fuse
-Fuse
Thanks fuse!
I'm sorry I can not join the conversation it's too difficult for me
No worries, mate... google translate only goes so far
I'm trying daily to keep up with the Gulden forum posts in Dutch... I know how you feel!
-Fuse
Looks good, Bram!
-Fuse
-Fuse
Thanks fuse!
I'm sorry I can not join the conversation it's too difficult for me
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.
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
"Other developers can look for a different solution, in the end the community decides." - Guldencoin
I am in agreement with Fuse. I believe in a team approach by many devs to implement necessary changes is the best route to follow. In this way you evaluate all of the options and then focus on the successful implementation of your strategy. This method will allow Guldencoin to evolve in a timely manner as a premier altcoin.
DIGI may still be the best short term solution to lose CM and gain time to refine and test on the simulator.
I endorse most of the arguments written by Fuse in his post.
As a Coindev there is also a reponsibility to keep the network safe, I am missing this point in the entire discussion. The NLG network is raped by someone with all the possiblities to do any majority attack and I wonder if Rijk or Geert-Johan can guarantee some sort of majority abuse is not happening right now.
Digi is no direct solution to such problem but it will make the coin less attractive to mine it with a lot of hashpower. It will get CM of our back and buy some time to implement an more apropriate way of recalculation.
As a Coindev there is also a reponsibility to keep the network safe, I am missing this point in the entire discussion. The NLG network is raped by someone with all the possiblities to do any majority attack and I wonder if Rijk or Geert-Johan can guarantee some sort of majority abuse is not happening right now.
Digi is no direct solution to such problem but it will make the coin less attractive to mine it with a lot of hashpower. It will get CM of our back and buy some time to implement an more apropriate way of recalculation.
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.
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):
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.
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?
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.
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
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):
Code:
if (nActualTimespan < (retargetTimespan - (retargetTimespan/4)) ) nActualTimespan = (retargetTimespan - (retargetTimespan/4));
if (nActualTimespan > (retargetTimespan + (retargetTimespan/2)) ) nActualTimespan = (retargetTimespan + (retargetTimespan/2));
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
Jump to: