NA

[LTEX]

Although I am not as impatient as others might have become, I also agree with the majority that we need something to change any time soon now.

Right now my priority lies in creating a solid and growing user base, that is what my project is all about. This also means that Icebear is right in stating that a hard fork after thousands of new users have joined is not really desirable. Fortunately the project will start with a preliminary subscription phase, so it won't be affected that much by algo changes.

If I look at the current user base of NLG though, it won't hurt too much to start with an implementation of Fuse's Digi solution mid January first so we can give GJ the time he deserves in creating the most perfect long term solution. We must not be to scared around an extra temporary change atm, I think more damage comes from stalling things right now than a hard fork would bring.

A voting on the official forum would be best to get this decision from the ground I think...

[1714606729]

1714606729

[1714606729]

1714606729

[1714606729]

1714606729

[1714606729]

1714606729

[BioMike]

I don't think the update would need a coordinated fork. You could put the new algo in effect at a specific future block. Previous updates should give an indication on how quick updates are picked up by the users, based on that you could pick a block on when the algo change hits the network.

[ny2cafuse]

I don't think the update would need a coordinated fork. You could put the new algo in effect at a specific future block. Previous updates should give an indication on how quick updates are picked up by the users, based on that you could pick a block on when the algo change hits the network.

Any update would essentially require a fork, because you are in fact forking away from the minority(unupdated users) with the majority(updated users).  As long as a majority of people upgrade, the fork isn't noticed.  But BioMike is correct in that a change can happen at a specific block.  That's why I mentioned that if I had a desired "go-live" block number, I could post the git pull if that's what the dev team and community wanted.

Again, I'm 100% behind whatever the dev team wants to do.  I just want to present this plan of action because my team feels it's a smart choice.  If /GJ wants to see other options, I'm all for it.  Keeping DGW3 and shortening the block time is an option, DIGI with a shorter block time is an option, a new weighted average algo is an option.  There's a lot of different ways this can go.

However, 20% DIGI with our current block time works, and it's an easy fix.  If someone has a better solution, I want to hear it because I want this to succeed.

As far as paying /GJ for development, I'm all for using the premine for it.  I also mentioned using a portion of the physical coin profit.  I'm not going to make millions off the coin sales, but maybe I can help with a server bill to offset dev costs for a month or two or something.  Or maybe a case of [insert caffeinated beverage here] to keep the fire stoked lol.  IDK... just tell me how to help.  Give me a plan of action.

-Fuse

Edit:

A voting on the official forum would be best to get this decision from the ground I think...

Sounds like a good idea. My personal vote would be to wait for GJ, because he is working on the sim to get facts. And with facts he can develop the best solution. GJ also wants to prevent a lot of forks, remember we are just one year old. But like I said its not only up to me.

I would like to hear from /GJ as well, and I stand behind a vote.  However, if /GJ wants to test DIGI against the simulator, I would want to see a roadmap of how we're going to get to that point with all the needed variables(large wave, DIGI code, etc).

Additionally, if a vote is created in the official forums, can you do it in English as well?  I feel lost trying to get info there, as most of the current discussion happens in Dutch.  I know, I know... it's a Dutch coin  .  I just want to keep abreast of what's going on.

[Frais]

However, 20% DIGI with our current block time works, and it's an easy fix.  If someone has a better solution, I want to hear it because I want this to succeed.

If your DIGI solution works my suggestion is to implement it, so GJ has more time to get the final solution worked out (if it's still needed then).

And about the communication: if you want to run a community, feed the community.

[Buerra]

I suggest we test fuse's digishield with the simulator as well before putting it to a vote. More results to make up our minds.

[Jero]

I suggest we test fuse's digishield with the simulator as well before putting it to a vote. More results to make up our minds.

Like the idea but testing is not possible yet and maybe it takes too much time right now.
So I suggest, voting is the best we can do right now. And a 2nd round of votes later on is possible too...  

Also, I thought we all were waiting for an algo change and we should be patience. But reading back now I think we should take action as a community a long time back allready?

[BioMike]

Maybe wait for a reply from /GeertJohan

[Jero]

Maybe wait for a reply from /GeertJohan

you're right...I spoke before my turn

[ny2cafuse]

I suggest we test fuse's digishield with the simulator as well before putting it to a vote. More results to make up our minds.

I'd love to see the simulator results as well, but like /GJ said himself, there is still work to be done to properly test large wave simulations, and of course there's the matter of porting DIGI.  I'm all for testing with the simulator if those features can be implemented in a timely fashion.  Whether that's with outside, paid help, or through /GJ, paid via dev premine, or unpaid... I don't care.  Let's just get roadmap, action plan, whatever figured out and in the works.

-Fuse

[Buerra]

I suggest we test fuse's digishield with the simulator as well before putting it to a vote. More results to make up our minds.

I'd love to see the simulator results as well, but like /GJ said himself, there is still work to be done to properly test large wave simulations, and of course there's the matter of porting DIGI.  I'm all for testing with the simulator if those features can be implemented in a timely fashion.  Whether that's with outside, paid help, or through /GJ, paid via dev premine, or unpaid... I don't care.  Let's just get roadmap, action plan, whatever figured out and in the works.

-Fuse

Yeah. In the meanwhile we can approach Golang developers anyway. It's handy to have one or two that we can call in anyway. Can you give me assistence with this Fuse? Send me a list of requirements/ code that the Golang devs needs to implement and where? Preferably via PM so I can type up a job-post on several freelance boards.

Thanks.

And to calm everyone down. Please take a moment to breathe, testing thoroughly is very very important. Don't rush to pushing for DIGI just because it seems the right thing to do. We need to know it is the best play, based on maths and not an educated guess on tests on the testnet. Sure. It goes a long way and a lot better than no testing at all. But having multiple numbers and tests just gives everyone more bang for their buck.

Not to worry. Buerra's pushing things now. LOL MONEY MONEY LOL

[ny2cafuse]

Yeah. In the meanwhile we can approach Golang developers anyway. It's handy to have one or two that we can call in anyway. Can you give me assistence with this Fuse? Send me a list of requirements/ code that the Golang devs needs to implement and where? Preferably via PM so I can type up a job-post on several freelance boards.

Thanks.

And to calm everyone down. Please take a moment to breathe, testing thoroughly is very very important. Don't rush to pushing for DIGI just because it seems the right thing to do. We need to know it is the best play, based on maths and not an educated guess on tests on the testnet. Sure. It goes a long way and a lot better than no testing at all. But having multiple numbers and tests just gives everyone more bang for their buck.

Not to worry. Buerra's pushing things now. LOL MONEY MONEY LOL

I'll start looking on Odesk and Elance.  Anyone with C++ and GO experience would be able to do the port.  I'd rather let /GJ decide on whether he wants to dev the rest.  It's his baby after all.  Has any post been made to announce the simulator to the crypto community?  There is a dev section of the forums that is filled with very competent devs who eat up this kind of development.  I would guess that announcing it there would lead to an "outsourcing" of community development.  Might just be easier to go that route.

What I say next might seem argumentative, but it's really just for my clarification.  Don't take it the wrong way.

With respect to the testing, how is real world mining not actual maths?  It is how the algorithm is going to behave on a chain, rather than how a simulator says it will behave.  I would think if you wanted true test data you would truly test it, would you not?  Like I said, I'm for testing against the simulator, but we need to know that the simulator(which simulates actual mining, not actually mining) is giving us substantiated results.  We can't say the simulator is the key to testing algorithms without testing the simulator against an actual testnet first.

For example, you would need to mine on a testnet.  You would simulate large wave, small wave, etc. and record all the data.  Then you would need to replicate that chain with the simulator, and compare the results.  If the simulator was off by a predetermined margin, you wouldn't be able to say the simulator was accurate.  After all the testnet chain would be the definitive data... it's the actual mining.

So to say that testnet data is an educated guess is a little off base.  It is the actual, substantiated data collected from mining.

-Fuse

[Halofire]

Throwing money at GJ from the premine isn't going to get anything done faster and could be used in a better way.

Besides, don't you all trust him? 

[LTEX]

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...

[ny2cafuse]

Throwing money at GJ from the premine isn't going to get anything done faster and could be used in a better way.

Besides, don't you all trust him? 

Trust isn't necessarily the issue here.  I trust him completely.  I just want to see things move along and not sit stagnant.

I've spoken in the past with /GJ about development in PM, and he expressed his dedication to NLG development, but lack of time and funds to make it a dedicated job.  Let's face it... in most cases, devs do this in their free time because they need to pay the bills with a full-time job.  I'm not entirely sure what /GJ does for a living outside of crypto, but if using dev premine to pay him to allow him to dedicate more time to development helps, I'm all for it.  This is all up to /GJ though... we can't tell him to quit his job and only work on NLG.

As far as GO skills go, that's not my bag.  I just don't have the time to put into learning it right now.  I'm sure I could, but I've got enough on my plate.  However, if the dev team and community decide to push forward with DIGI, then I'm ready to create the code git pull if needed.  No dev time is needed on the dev team's end, minus the windows compile.  At least that could take a little pressure of the team.

Like others have said though, I'd like to hear from /GJ and see what he has to say.  I'm ready to act on any decision, I just need direction.

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...

Love the story, and the analogy!

-Fuse

[Sharkzz1]

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

[Halofire]

Throwing money at GJ from the premine isn't going to get anything done faster and could be used in a better way.

Besides, don't you all trust him? 

Trust isn't necessarily the issue here.  I trust him completely.  I just want to see things move along and not sit stagnant.

I've spoken in the past with /GJ about development in PM, and he expressed his dedication to NLG development, but lack of time and funds to make it a dedicated job.  Let's face it... in most cases, devs do this in their free time because they need to pay the bills with a full-time job.  I'm not entirely sure what /GJ does for a living outside of crypto, but if using dev premine to pay him to allow him to dedicate more time to development helps, I'm all for it.  This is all up to /GJ though... we can't tell him to quit his job and only work on NLG.

As far as GO skills go, that's not my bag.  I just don't have the time to put into learning it right now.  I'm sure I could, but I've got enough on my plate.  However, if the dev team and community decide to push forward with DIGI, then I'm ready to create the code git pull if needed.  No dev time is needed on the dev team's end, minus the windows compile.  At least that could take a little pressure of the team.

Like others have said though, I'd like to hear from /GJ and see what he has to say.  I'm ready to act on any decision, I just need direction.

snip

-Fuse

What I meant by the trust thing was that's he's oriented to do well for NLG regardless of whether or not we throw additional monies at him.

[c_e_d]

Click on the pictures for a larger view.
...
The first 2 jumps are from baseline to 5 times the network hashrate.  After that, the jumps are 10X increases, and the highest peak is when we toggled a 15X increase for giggles.  In the following pictures you will see the difficulty values and the steps up and down instead of instant spikes and crashes.  Notice that each time the hashrate was removed to go back to baseline, it never dives below the baseline.  It tapers back, and when the block is found, it stabilizes instantly. This is something DGW3 isn't doing properly.
...
-Fuse

Looks really good! For my taste it could increase even faster (use the 25% you tested too instead of 20%) to give MPs like CLEVER even less time to make use of lower diff.
How many blocks is the window for MPs from what you saw in your tests?
I guess your mod is based on DigiShield V1, since V2 and V3 are based on multi algos.

Isn't it possible to do temporarily a little adjustment in the DWG3 parameters without a mandatory upgrade until the simulator is ready for testing?  Or can't that be done without a mandatory upgrade? That would mean some improvements already, the bigger come later then with the new Guldencoin algo.

DGW3 in its original form (as used here) has a little 'One-Off' bug that is easy to fix (plus a little code cleanup) but not the root of the problem. Based on a row of 2k blocks I was analysing there seems to be another, more hidden bug that hits at diff 512 and looks like a data type conversion problem to me. At that point my free time got too short to get closer to the problem.
And I think /GJ was right when he said that fixing DGW3 will not fix our problem of getting raped my MPs; DGW3 has proven that it does not react fast enough for what we need. It sure reacts faster than earlier versions while still trying to smooth the spikes. The smoothing leads to the windows for MPs.

From reading through many diff algos during the last months I have come to an own idea for an algo that should react fast while still a bit smoothed by a trend analysis. Sadly free time is still short and my experience in reading C is far bigger than writing it . And without a tool to test and fine tune the idea it's all theory. So the next steps of the simulator with mid and big waves are needed here too.

Conclusion: Fuse's DIGImod seems the best solution for now to get some pressure from NLG and gives enough time to develop the NLG diff algo for the forseeable future. That's the hope based on what we can see. A new diff algo that is able to keep up with the heavy increasing hash power nowerdays needs more time than previously expected and a lot of testing before it can go life for a coin with real life use.

Another point I mentioned before: Extrem short block times needs a penalty which in my eyes is a necessary and reasonable defense! A reject for extrem short block times (<50sec, 1/3 of the default time of 150) to the block check is low enough for normal 'lucky blocks' still being accepted. Or at least cut the block reward for those blocks to 1/3. This way the first few blocks for big hash powers jumping in and until the diff algo can adjust wouldn't overpay (by time used) so far anymore.

[24Kilo]

Since Fuse pushed this into the public domain... I will submit a summary of my findings and put forth some rather radical proposals. I had wanted to present this to GJ in private as we have been in discussions, but I have not had time due to family and business obligations. And at the moment I am too busy to have time for a detailed reply, so will keep this as short and direct as possible.

1. Look at network difficulty adjustment in increments instead of minutes or seconds -

The common fault is to look at a network as blocks per minute or blocks per 24 hours, such as presented by 'nlgblogger', instead a network needs to be looked at as the number of diff adjustments per 24 hours. With a 60sec block time, there is 1440 increments per 24 hours, with 150sec(NLG), there are only 576. So any diff algo designed for a 60sec block time needs to be looked at over 1440 blocks, not a 24 hour period, to see if it is working as desired if that diff algo is applied to any other block time. NLG has only about 1/3 of the diff increments in 24 hours when compared to a 60sec block time network. Both DigiShield and DGW3 were desired expressly for a 60 second block time, Digicoin in the former and DarkCoin in the latter. This is why neither Digi nor DGW3 are effective without tuning.

2. Digi vs DGW3 -

Digishield is a much simpler and more elegant diff algo that scales easily and effectively, while DGW3 is very complex and does not scale well. DGW3 works extremely well for the coin it was expressly designed for, DRK. Also Digishield handles the backside of the spike much better.

3. Testnet, Simulator or Main-net -

While I completely trust GJ, a simulator is a just that... a simulation. A testnet is just an alternate block chain that replicates the main network exactly and allows for testing. Testnet results are a real and actual and I trust those results much more than an unproven simulation. If the community wants... and I have threatened this... I am happy to fork NLG(the main blockchain) and run my tests on the main chain, just be aware that I could own most of your NLG if I did this. Fuse and the Criptoe has asked me not to do this in the interest of protecting NLG and I have deferred to their request. The testnet results are real and factual as testing on the main chain.

4. DigiShield or as I call GuldenShield provides the best solution in the mid-term -

I have spent over 3 weeks testing various diff algos on the NLG testnet, on my own and with Fuse and the Criptoe team. Fuse has my findings and data. A 25% modified Digishield diff algo is my recommendation. It works, it reacts quick enough to make it unprofitable for a large hash-rate miner/pool by driving the diff up very quickly reducing the number of blocks they can mint on a hash-rate spike, while not lowering the diff to a false low on the back side of the spike.

5. Real world results -

Clever will still be able to drive the diff up and cause the network to hang, but will mint so few blocks that it will no longer be profitable. There is nothing that can be done to prevent a 'stuck' network in the case of a sudden loss in hash-rate. The network will not plummet to a false low after finding a long block, but will the diff drop will controlled and prevent that frenzy of found blocks that Clever is able to capitalise on.

Please read this post - https://bitcointalk.org/index.php?topic=498671.msg9938466#msg9938466 - for further explanation.

6. Implement GuldenShield - give credit to the Digishield devteam, but since we are essentially deploying a custom diff algo, the GuldenCoin devteam and community deserve the credit and right to call the NLG diff algo their own. Fuse has a working codebase and Criptoe can have a clean, pretty codebase ready to deploy in a few days at worst.

In summary, GuldenShield may not be the perfect solution, but is a solid solution that will be able to let the NLG network grow to a diff of 10k plus. The beauty of crypto and open-source is that the codebase can adapt to the environment and demands of the community. NLG needs to embrace this flexibility and move forward.

The time for inaction is over...

EDIT - forgot about my radical proposal...

I would fork NLG to a 75sec block target time with a 500NLG reward that retargets every block using a custom Digishield implemtation. This would reduce any 'stuck network' time by 50%, increase the number of diff increments per 24hrs by 100%, reduce the number of blocks that Clever can mint per 24hrs by 80%, and make NLG a much better network for micro-transactions. This would make NLG the premier alt-coin.

That is what I would do with NLG

[Litesire]

The time for inaction is over...

EDIT - forgot about my radical proposal...

I would fork NLG to a 75sec block target time with a 500NLG reward that retargets every block using a custom Digishield implemtation. This would reduce any 'stuck network' time by 50%, increase the number of diff increments per 24hrs by 100%, reduce the number of blocks that Clever can mint per 24hrs by 80%, and make NLG a much better network for micro-transactions. This would make NLG the premier alt-coin.

That is what I would do with NLG

The reduction of block times by 50% and halving the amount of NLG mined would be a great change if it is possible, this change will also extend the coins mining life cycle as the block halving would come faster. Right now the total coins will be mined out under 15 years, this will extend it over 40 years.

This algorithm problem has been hanging over the coins head since September and would of killed most coins by now, so imagine what a good and smooth algorithm would do, I think top 20 coin by middle of next year as the elephant in the room would be finally dealt with.

[xtrix]

The time for inaction is over...

EDIT - forgot about my radical proposal...

I would fork NLG to a 75sec block target time with a 500NLG reward that retargets every block using a custom Digishield implemtation. This would reduce any 'stuck network' time by 50%, increase the number of diff increments per 24hrs by 100%, reduce the number of blocks that Clever can mint per 24hrs by 80%, and make NLG a much better network for micro-transactions. This would make NLG the premier alt-coin.

That is what I would do with NLG

The reduction of block times by 50% and halving the amount of NLG mined would be a great change if it is possible, this change will also extend the coins mining life cycle as the block halving would come faster. Right now the total coins will be mined out under 15 years, this will extend it over 40 years.

This algorithm problem has been hanging over the coins head since September and would of killed most coins by now, so imagine what a good and smooth algorithm would do, I think top 20 coin by middle of next year as the elephant in the room would be finally dealt with.

Great idea! I fully support this change and would like to see it implemented yesterday  We should start 2015 with a solid and healthy gulden with no room for Clever mining anymore.