NA

[Sharkzz1]

ny2, it is not about me. And I did not buy the equipment you mention.
I have no personal gain motivation for changing the algo to M7M. I think it is the best solution for the problem that has been dragging on for months now.
The M7M algo has proven its value in fair mining and keeping out mining farms and multipools taking over.
Moreover, XMG dev Joe who implemented M7M very succesfully already offered to help.
So it seems like a good solution to the problem to me.

It might be a solution to the CM problem, but i think we could better stick with scrypt because there's nothing wrong it and it would be weird to go to cpu mining.

[1714638482]

1714638482

[1714638482]

1714638482

[1714638482]

1714638482

[1714638482]

1714638482

[veertje]

After what I read in previous posts, I think it is good to make a change short term to the adjusted Digi that has been tested by Fuse. Unless the GJ can say the simulator is finished within a certain amount of time (say 2 weeks or so) and DGW3 can be tested with big waves and parameter changes. But I think it will take longer to complete the simulator? GJ, can you give an indication?

Also GJ can work further on the simulator if a short term change is implemented. For the future new algo after simulations with different algo's. Even if that means go back to for example DGW3 again later with best simulated parameters with big waves and small waves, if that means the best.

[ny2cafuse]

ny2, it is not about me. And I did not buy the equipment you mention.
I have no personal gain motivation for changing the algo to M7M. I think it is the best solution for the problem that has been dragging on for months now.
The M7M algo has proven its value in fair mining and keeping out mining farms and multipools taking over.
Moreover, XMG dev Joe who implemented M7M very succesfully already offered to help.
So it seems like a good solution to the problem to me.

You don't just change from GPU/ASIC based mining to CPU mining after 9 months of mining.  I have a hard time believing you don't have a reason for suggesting it other than the fact that it would eliminate the MPs.  But you forget that it will eliminate miners in general.

What about alienating the already established mining population?  Dedicated miners who have held the chain together for months now.  Are you ready to tell them that they have to abandon their gear and adapt to a completely different way of mining?

It's nonsensical at best.  I said it when you first recommended it, and I'm saying it again.

-Fuse

[Digithusiast]

It will not eliminate miners, it will increase miners. CPU mining is much more accessible than scrypt (GPU) for the average citizen.
NLG mining population will grow more rapidly.
Current miners who gathered NLG are only gaining from such a change, as the value of Guldencoin will more likely increase, so their already mined coins increase in value.
Changing an algo does not mean your coins are lost or devaluated.

[Frais]

It will not eliminate miners

You'll dump the dedicated miners who put a lot of money in to fight against Clevermining. Without them Guldencoin was already destroyed by clever.

[ny2cafuse]

It will not eliminate miners, it will increase miners. CPU mining is much more accessible than scrypt (GPU) for the average citizen.
NLG mining population will grow more rapidly.
Current miners who gathered NLG are only gaining from such a change, as the value of Guldencoin will more likely increase, so their already mined coins increase in value.
Changing an algo does not mean your coins are lost or devaluated.

You will undoubtedly lose miners.  I for one wouldn't CPU mine.  I did it once with YAC and I hated it.  The stress it put on my computer was horrible.  Imagine the person who doesn't know any better and melts their Macbook pro trying to CPU mine while they're asleep.  No bueno.

You assume that we are going to gain miners because everyone has a CPU.  That's like saying if you have a car you can race in the Grand Prix.  The typical non-experienced miner is not going to CPU mine.  They will pay $20 to buy cloud miners though.  Clever proves that with it's available hashrate.

-Fuse

[Buerra]

Just to let everyone know that I am also voting for a modified Digishield tomorrow. Get it done and if that works, we're sound for the time being. Gives us all room to breathe and continue to enhance and advance with Guldencoin.

Also, changing Scrypt is stupid. That is not even the issue here. Miners are very important, but it has to be fair to all miners. That's what we are trying to fix here. Also, BioMike is working on creating an easy miner that makes CPU mining very easy. So you have best of both worlds - https://forum.guldencoin.com/index.php?topic=656.0

[ny2cafuse]

My opinion: go with DIGI as 'short term' solution, if possible before the end of the year (?), and keep our eyes open for new developments in the algorithm space, including GJ's simulator.

Only thing I want to have explained before I give my vote on DIGI is; why did it go wrong with DGW3?
Didn't we test it as much as we did now with DIGI? Or were the testnet results as promising as the DIGI ones? In that case.. well we would seriously need to reconsider the DIGI choice, I guess..

Fuse, or anyone else, if you could clarify this last issue for me, thanks  

Icebear

I can't speak to the testing done on DGW3.  I don't know what happened with DGW3.  Right off the bat, we experienced some shakiness.  I remember the posts about waiting to give it time to level out so that the swings weren't so dramatic.  But the swings stayed pretty dramatic.  My only guess is that the target timespan vs actual timespan is causing a more exaggerated swing in difficulty with the longer block time.  Kilo proposed this to me in Criptoe chat, and it's why we brought up shorter block times.  It's my only thought as to why it didn't work.

-Fuse

[RJF]

Just a real life metaphor from me....

My best friend and I bought a boat 10 years ago. It needed finishing on the interior. I am a hands on guy (measure once, cut many times), the opposite of my friend who likes to make models and lists endlessly before he actually starts to do anything. Needless to say this created some challenges.

One weekend our wives decided it was time to end discussions and encouraged us to start doing the job. I decided to go along with the ideas we came up with together and drove by the stores to pick up the materials and started on the job. My friend started preparing a list and spend the entire weekend finding out where to best buy the materials.

On Sunday he arrived at the shipyard with the list and found me with a beer on the boat. It was finished, almost exactly the way he described on his list....

I don't want to say here this is the best way to go, but it might help you to understand why I'm with Fuse's last remarks...

Nice example, i'm with Fuse's choice too

Same here...

[investeerder]

I will be happy to see a Digishield implementation and the coin can move forward!

[RJF]

Please, don't touch the reward and the block time. That's something you do with scam coins, not guldencoin (and are, for me, in a way important determinants for trust in this coin).

I have to agree with BioMike, that's not the problem and should not be changed at this time. Lets solve the problem before we change the equation...

[Buerra]

I don't think we should tamper with block times, unless we really absolutely entirely have no other choice. We're talking about retargeting, an algorithm can be developed for that. If Digishield modded can give us that breathing room to perfect the NLG-algo. Let's do it.

Scrypt doesn't have anything to do with the problems, it was KGW and now DGW3 - we done fucked up, but we can fix it. Remember that part. We can fix it and are fixing it together. But also remember. If a modded Digishield does not fix the issue at hand (and this is an if, don't attack me with false claims that I'm against it, I'm simply lowering expectations). We have no right to complain about it afterwards. We will just have to strap tight and wait for the proper algorithm to be developed, tested, tweaked and implemented.

[RJF]

ny2, it is not about me. And I did not buy the equipment you mention.
I have no personal gain motivation for changing the algo to M7M. I think it is the best solution for the problem that has been dragging on for months now.
The M7M algo has proven its value in fair mining and keeping out mining farms and multipools taking over.
Moreover, XMG dev Joe who implemented M7M very succesfully already offered to help.
So it seems like a good solution to the problem to me.

You don't just change from GPU/ASIC based mining to CPU mining after 9 months of mining.  I have a hard time believing you don't have a reason for suggesting it other than the fact that it would eliminate the MPs.  But you forget that it will eliminate miners in general.

What about alienating the already established mining population?  Dedicated miners who have held the chain together for months now.  Are you ready to tell them that they have to abandon their gear and adapt to a completely different way of mining?

It's nonsensical at best.  I said it when you first recommended it, and I'm saying it again.

-Fuse

Agreed. lets keep our sites on fixing the current problem. Changing the entire landscape at the same time is problematic at best.

[24Kilo]

I have had 3 hours of sleep in the past 48 hours and driven over 1000klms delivering produce to the markets... so this post may be insulting and will be blunt... I ask for your consideration and understanding before replying -

1. GJ - his work on the simulator and 'ultimate diff algo' is absolutely of vital importance and should continue. Sadly, the tyranny of time and distance is preventing me from working closely with GJ.

2. - Digishield aka GuldenShield - this implementation should always be looked at as a stop gap to allow GJ the time and breathing space to perfect GuldenShield V2.

3. - I know how a network and blockchain works intimately, I have spent over 12 months as miner studying and testing networks and exploits. I have the knowledge and the resources to test any diff algo at a level usually referred to as brute force.

4. - the response to my radical proposal proves that most of you have not been paying attention to my posts for the past few months. There is huge disparity between the intended use of NLG and the technical specifications of the network. NLG is a blatant copy and paste of LTC, look at the codebase, with the change to single block retargeting.

5. - the strength of NLG lies in the community, it is without peer. The community is why I support NLG completely and I am even bothering to type this post. But NLG could be so much more if we matched the technical specs of the coin to the community vision.

6. - why did I make a radical proposal -

• NLG is maturing into the coin for micro-transactions(that is wallet to wallet, small, daily use currency)
• reducing the block time to 75sec cuts transaction times by greater than 50%, speeding up transactions
• reducing the block reward to 500NLG maintains the current number of NLG minted per 24hrs
• increases the number of diff increments by 100% per 24hrs, from 576 to 1152
• reduces the number of blocks a high-hash-rate attacking miner/multipool can mint by 80%
• these changes support the community vision of NLG becoming a daily use currency
• the only down side of this proposal is that the block chain storage requirement would double, but still be less than most alt-coins

7. - NLG has my 100% support, hash-rate and vision.

8. - I am completely opposed to changing from Scrypt, halving miners rewards over the 24hrs or long-term, or any manipulation attempts to increase the value of NLG by change coin variables. What I am proposing may change the value of NLG, I could care less, but the changes will make NLG a much better coin for the community vision of NLG becoming a daily use currency.

9. - I am content with only changing the diff algo if that is the community decision. The radical proposal is a simple change of a few numbers in a few lines of code and would also make GJ job easier with the diff algo easier. I spoken to Fuse about the variables needed to Digishield if the community want to do something radical and implement my proposal, he can explain

It is time for NLG to take the next steps in becoming the premier alt-coin.

[LTEX]

I Just want to say I'm proud to see everyone is sharp and focused on getting this coin to the next level. I think it's safe to say I haven't found any coin with such a mature and sensible community.

Thanks for that!

[icebear]

I have had 3 hours of sleep in the past 48 hours and driven over 1000klms delivering produce to the markets... so this post may be insulting and will be blunt... I ask for your consideration and understanding before replying -

1. GJ - his work on the simulator and 'ultimate diff algo' is absolutely of vital importance and should continue. Sadly, the tyranny of time and distance is preventing me from working closely with GJ.

2. - Digishield aka GuldenShield - this implementation should always be looked at as a stop gap to allow GJ the time and breathing space to perfect GuldenShield V2.

3. - I know how a network and blockchain works intimately, I have spent over 12 months as miner studying and testing networks and exploits. I have the knowledge and the resources to test any diff algo at a level usually referred to as brute force.

4. - the response to my radical proposal proves that most of you have not been paying attention to my posts for the past few months. There is huge disparity between the intended use of NLG and the technical specifications of the network. NLG is a blatant copy and paste of LTC, look at the codebase, with the change to single block retargeting.

5. - the strength of NLG lies in the community, it is without peer. The community is why I support NLG completely and I am even bothering to type this post. But NLG could be so much more if we matched the technical specs of the coin to the community vision.

6. - why did I make a radical proposal -

• NLG is maturing into the coin for micro-transactions(that is wallet to wallet, small, daily use currency)
• reducing the block time to 75sec cuts transaction times by greater than 50%, speeding up transactions
• reducing the block reward to 500NLG maintains the current number of NLG minted per 24hrs
• increases the number of diff increments by 100% per 24hrs, from 576 to 1152
• reduces the number of blocks a high-hash-rate attacking miner/multipool can mint by 80%
• these changes support the community vision of NLG becoming a daily use currency
• the only down side of this proposal is that the block chain storage requirement would double, but still be less than most alt-coins

7. - NLG has my 100% support, hash-rate and vision.

8. - I am completely opposed to changing from Scrypt, halving miners rewards over the 24hrs or long-term, or any manipulation attempts to increase the value of NLG by change coin variables. What I am proposing may change the value of NLG, I could care less, but the changes will make NLG a much better coin for the community vision of NLG becoming a daily use currency.

9. - I am content with only changing the diff algo if that is the community decision. The radical proposal is a simple change of a few numbers in a few lines of code and would also make GJ job easier with the diff algo easier. I spoken to Fuse about the variables needed to Digishield if the community want to do something radical and implement my proposal, he can explain

It is time for NLG to take the next steps in becoming the premier alt-coin.

Thanks for taking the time 

I would say, go for the DIGI implementation now and keep the eventual blocktime/reward changes for later? Not changing too much at once and letting the simulator be of good use in the future?

Icebear

[c_e_d]

Darn, what a read of the last few pages

Thanks to Fuse to finally show the code and thanks to 24Kilo for his details arguments and his big help modding the code for NLG.

Both, DGW3 and DigiShield, are not that complicated to understand.
Simple said:

Our DGW3 uses an average diff of the interval and a summed up time of blocks to calculate the next diff. A little code cleanup and correcting the obvious make it looking better but there is still something in there that makes it overreacting under certain conditions. The slower reaction to a spike is caused by the diff average and (from what I understood) intended by the developer to smooth the swings.

DigiShield takes the diff of the last block and the time diff between first and last block in the interval to calculate the next diff. The original version is retargeting the diff only once per interval. We need it to retarget every block and the modded version does it.

In the modified code I saw an additional line in there (called 'amplitude filter') that seems to reduce the used time swings more than the original code (with is still in there) and it uses an interval length of 1?
The last point rings an alarm bell in my head but I might simple be too tired to read it correctly right now.
I think tomorrow I need to do a little code cleaning here too and than read and think about it again.

That said, I am all for this quick solution even if that means we have to change the diff algo in a few months again. It buys us time to work on the next NLG diff algo and on a simulator that can test hash rate swings like Clever would jump with all it has on NLG.

[joelao95]

It's very hard to define an "exact" algo to take care of the diff issue in my view. It's rather a static math problem but a real time matter involving with time-relevant situations; every algo can only solve part of issue at one time. A "perfect" algo should be smart enough to predicate the 'next' diff before it actually happens which is rather clueless since you'd never know the input, i.e., the actual hash rate. "Accurate" adjustment is possible in applications, for example, under a stable environment (http://en.wikipedia.org/wiki/PID_controller). Any efforts coping with the dynamic environment barely leads to convergence. It could lead to improvement but rather a solution. Diff adjustment in all existing algo is based on past blocks which actually tell what they did are just rough guess. My simple tip is trial-and-error, implementing adjustment particularly for the issue you had and then further optimization if needed later on.

[sven22]

I have had 3 hours of sleep in the past 48 hours and driven over 1000klms delivering produce to the markets... so this post may be insulting and will be blunt... I ask for your consideration and understanding before replying -

1. GJ - his work on the simulator and 'ultimate diff algo' is absolutely of vital importance and should continue. Sadly, the tyranny of time and distance is preventing me from working closely with GJ.

2. - Digishield aka GuldenShield - this implementation should always be looked at as a stop gap to allow GJ the time and breathing space to perfect GuldenShield V2.

3. - I know how a network and blockchain works intimately, I have spent over 12 months as miner studying and testing networks and exploits. I have the knowledge and the resources to test any diff algo at a level usually referred to as brute force.

4. - the response to my radical proposal proves that most of you have not been paying attention to my posts for the past few months. There is huge disparity between the intended use of NLG and the technical specifications of the network. NLG is a blatant copy and paste of LTC, look at the codebase, with the change to single block retargeting.

5. - the strength of NLG lies in the community, it is without peer. The community is why I support NLG completely and I am even bothering to type this post. But NLG could be so much more if we matched the technical specs of the coin to the community vision.

6. - why did I make a radical proposal -

• NLG is maturing into the coin for micro-transactions(that is wallet to wallet, small, daily use currency)
• reducing the block time to 75sec cuts transaction times by greater than 50%, speeding up transactions
• reducing the block reward to 500NLG maintains the current number of NLG minted per 24hrs
• increases the number of diff increments by 100% per 24hrs, from 576 to 1152
• reduces the number of blocks a high-hash-rate attacking miner/multipool can mint by 80%
• these changes support the community vision of NLG becoming a daily use currency
• the only down side of this proposal is that the block chain storage requirement would double, but still be less than most alt-coins

7. - NLG has my 100% support, hash-rate and vision.

8. - I am completely opposed to changing from Scrypt, halving miners rewards over the 24hrs or long-term, or any manipulation attempts to increase the value of NLG by change coin variables. What I am proposing may change the value of NLG, I could care less, but the changes will make NLG a much better coin for the community vision of NLG becoming a daily use currency.

9. - I am content with only changing the diff algo if that is the community decision. The radical proposal is a simple change of a few numbers in a few lines of code and would also make GJ job easier with the diff algo easier. I spoken to Fuse about the variables needed to Digishield if the community want to do something radical and implement my proposal, he can explain

It is time for NLG to take the next steps in becoming the premier alt-coin.

You had my attention here 24Kilo, thanks for the post and thanks for your hard work!! Also at all the rest off course, I am proud to be part of this community!!

Let's bring NLG to the next level!

[veertje]

• NLG is maturing into the coin for micro-transactions(that is wallet to wallet, small, daily use currency)
• reducing the block time to 75sec cuts transaction times by greater than 50%, speeding up transactions
• reducing the block reward to 500NLG maintains the current number of NLG minted per 24hrs
• increases the number of diff increments by 100% per 24hrs, from 576 to 1152
• reduces the number of blocks a high-hash-rate attacking miner/multipool can mint by 80%
• these changes support the community vision of NLG becoming a daily use currency
• the only down side of this proposal is that the block chain storage requirement would double, but still be less than most alt-coins

If lower blocktimes makes it easier to better the algo, also has more benefits and blockreward is adjusted to the blocktime, it looks fine to me to do that. Total coins will stay the same, so defendable.

Blocktime has been lower at the start before and is now 2,5 minutes. Don't know why 2,5 minutes was choosen. Can the team say something about that? Maybe it's important in the discussion.