NA

[24Kilo]

The inability of NLG to be used for wallet to wallet transactions is starting to sour me on this coin. Yesterday the network was stuck at a diff of 777 for well over 2 hours, and again this morning the network was stuck for over an hour at a diff 497, during which time it is impossible to transfer NLG from wallet to wallet.

It is all fine and good that LiteBit? approves NLG transactions immediately regardless of network status, but for NLG to not be useable for wallet to wallet transactions is killing NLG.

The dev team must assess and address this immediately, there are plenty of coins that are using retargeting algos that are effective when dealing with network hashrate spikes. This is not rocket science, the dev team seems to burying their collective heads in the sand and hoping for the best.

DGW3 is not working, find a solution. Now!!!

[1715032580]

1715032580

[1715032580]

1715032580

[1715032580]

1715032580

[1715032580]

1715032580

[ny2cafuse]

The inability of NLG to be used for wallet to wallet transactions is starting to sour me on this coin. Yesterday the network was stuck at a diff of 777 for well over 2 hours, and again this morning the network was stuck for over an hour at a diff 497, during which time it is impossible to transfer NLG from wallet to wallet.

It is all fine and good that LiteBit? approves NLG transactions immediately regardless of network status, but for NLG to not be useable for wallet to wallet transactions is killing NLG.

The dev team must assess and address this immediately, there are plenty of coins that are using retargeting algos that are effective when dealing with network hashrate spikes. This is not rocket science, the dev team seems to burying their collective heads in the sand and hoping for the best.

DGW3 is not working, find a solution. Now!!!

I'd have to agree with 24Kilo on this one.  I tried to make a deposit to Bittrex last night and the time it to confirm was 140 minutes or more.  The price was 510 I finally gave up waiting and just went to bed.  When I woke up, I sold at ~470 or so.  That's a big hit just because of confirmation times.  Sure I could have stayed up and waited it out, but with non-uniform block times, who knows what it would have taken.

Truth of the matter is that Terk's pool is still hitting upwards of 70-90% of the blocks on any given day, which is a huge security concern to me still.  That pool's influence on the chain is more than I would have accepted a long time ago.  I would have IP banned them from the get-go, but I'm a bit more extreme sometimes.

We keep saying that we will even out when there are more dedicated miners, but we won't get dedicated miners with the current dynamics.

We need to knock multipools off the chain, and we need to do it sooner than later.

-Fuse

[Halofire]

Is there anything wrong with Nite's Gravity Well? Seen it in action for a coin I once played with, worked pretty good.

[strataghyst]

I still think a longer maturity time for newly minted blocks is a nice and simple feature.

[markanth]

For those interested in some daily mining statistics about NLG, feel free to head over to http://nlgstats.iblogger.org  (appologize for the crude html, not my thing).  This has been my scratchpad to learn about / interact with the blockchain.  Will gladly try my best to add any additional info to the daily stats if it will help.  Just shoot me a PM with ideas.  If additional products are needed I'll see what I can do.  There is also an NLG richlist (top 100 addresses) for those interested in those types of things.  I'll update at least daily, just remember to refresh (F5?) for the latest info.  Chrome likes to cache.

RE: Long block gaps:  In my humble opinion regarding large scrypt multi-pools, I'm against IP blocking.  In the immediate short term let's reach out to clevermining and try to tweak their NLG targeting to avoid these long block gaps?  Based on his previous posts they seem reasonable and willing to work with us.  It is probably is more efficient for clevermining to have a dialog with one 1 NLG rep (dev?) and hopefully the information coming out of those talks will flow here in a timely fashion?   Appreciate the NLG devs are being cautious and providing more frequent updates on progress.  Investigations, simulation and analysis take time if done properly and nobody has unlimited free time. 

[Wildwest]

For those interested in some daily mining statistics about NLG, feel free to head over to http://nlgstats.iblogger.org  (appologize for the crude html, not my thing).  This has been my scratchpad to learn about / interact with the blockchain.  Will gladly try my best to add any additional info to the daily stats if it will help.  Just shoot me a PM with ideas.  If additional products are needed I'll see what I can do.  There is also an NLG richlist (top 100 addresses) for those interested in those types of things.  I'll update at least daily, just remember to refresh (F5?) for the latest info.  Chrome likes to cache.

RE: Long block gaps:  In my humble opinion regarding large scrypt multi-pools, I'm against IP blocking.  In the immediate short term let's reach out to clevermining and try to tweak their NLG targeting to avoid these long block gaps?  Based on his previous posts they seem reasonable and willing to work with us.  It is probably is more efficient for clevermining to have a dialog with one 1 NLG rep (dev?) and hopefully the information coming out of those talks will flow here in a timely fashion?   Appreciate the NLG devs are being cautious and providing more frequent updates on progress.  Investigations, simulation and analysis take time if done properly and nobody has unlimited free time. 

I have to agree, I will say this if something ever had to happen to Guldencoin I will never invest in another altcoin. This is the only one I trust 100% outside of bitcoin and I hope everyone can help in getting the blocktime issues resolved.

[strataghyst]

Is there anything wrong with Nite's Gravity Well? Seen it in action for a coin I once played with, worked pretty good.

UFO coin also has nite's gravity well with some other security features maybe something to look at

[kwaasteniet]

The inability of NLG to be used for wallet to wallet transactions is starting to sour me on this coin. Yesterday the network was stuck at a diff of 777 for well over 2 hours, and again this morning the network was stuck for over an hour at a diff 497, during which time it is impossible to transfer NLG from wallet to wallet.

It is all fine and good that LiteBit? approves NLG transactions immediately regardless of network status, but for NLG to not be useable for wallet to wallet transactions is killing NLG.

The dev team must assess and address this immediately, there are plenty of coins that are using retargeting algos that are effective when dealing with network hashrate spikes. This is not rocket science, the dev team seems to burying their collective heads in the sand and hoping for the best.

DGW3 is not working, find a solution. Now!!!

We apologize if we gave the impression we bury our heads in the sand or didn't inform properly about the current situation. We recognize your frustration and are fully aware that DGW3 is not fixing the issue of multipools. This is still our number one priority and we are investigating other algo's, but its simply not a matter of copy paste, as other coins have different configurations and the scenarios are different. So we have to investigate, run simulations and even think about custom made algo's, as you can imagine something like that will take time.

Also to be aware of what is happening we've spend a lot of time developing tools like explorer.guldencoin.com and seeds.guldencoin.com. These tools can help us now and in the future to get the information we need to find a good solution. The crypto landscape is always changing and Guldencoin is a long term project, so tools like these are very important as they provide us a clear overview of what's happening.

The fact that LitePaid approves NLG transactions immediately is NOT a solution, but it means that merchants won't notice these current spikes and can do business like they expect and demand. LitePaid is a third party company that provides merchants with a service and for merchants to even consider accepting crypto we need services like LitePaid, for now that is. I can't think of one serious merchant for NLG or BTC that doesn't work with a third party payment provider. In the future when Guldencoin is a more recognized payment method, merchant will choose to accept Guldencoin directly, instead of converting directly to EUR. Currently some merchants are getting paid in Guldencoin through LitePaid instead of EUR.

So yes its a very serious and frustrating issue which needs to be addressed immediately and we doing everything in our capability to do so, but we don't have the solution yet. So like before we implemented DGW3 the community helped us a lot by discussing different algo's, I would like to ask the community to help us again. We all want to solve this quickly. So when you look into other coins with working algo's, please also compare the other factors.

DGW3 is not the solution, we are doing everything in our capability to find the solution. Let's work together on this and get the network healthy.

Nice... but i haven't the faintest idea were you are talking about. I am just a simple Guldencoin user with no technological background of cryptocurrencies. But i feel the Guldencoin is in Danger....like hundreds of other cryptocurrencies. Can someone explain it in simple words (ELI5).  . I understand miners quit the Guldencoin and now we have a problem with multipools? why? I thought that multipools are also miners but they are switching between the most pofitable coins. What is the problem with that?

[Dutchyyy]

I still think a longer maturity time for newly minted blocks is a nice and simple feature.

Yes we agree and this is something we could start with.

Was digishield maybe not better because all the scrypt coins went with digishield or is it because of > 2 min block times that makes it more difficult?

[/GeertJohan]

I just sent a message to Terk asking if he can take a look at the amount of hashrate thrown at NLG.

DGW3 does better re-adjustment than KGW, but as we can see it's not good enough.
DGW3 calculates diff based on the 24 last blocks.
When there's a long blocktime, and then someone mines 1 block, then clevermining takes 23 blocks, the long blocktime block is not taken into the calculation anymore, and the diff spikes.
Now I hear you say: "why don't we increase the number of blocks taken into the DGW3 calculation". Well, I did some simulations and I believe in the end that will only affect the number of blocks clevermining gets before the diff spikes.

So we need something clever (no pun intended).

There are two methods:
- create a re-adjustment algorithm that is actually pretty smart, detecting patterns, applying penalties if a lot of blocks were mined in short time.
- work out how a block reward based on block time. e.g.: `reward = 1000 * (secsSinceLastBlock/150)` with a max of, say, 3000 (after 3x the target blocktime).

Best would be: both.

Please let me know what you think about this!
I'll work out more details this evening (CEST).

[Bluestreet]

I just sent a message to Terk asking if he can take a look at the amount of hashrate thrown at NLG.

DGW3 does better re-adjustment than KGW, but as we can see it's not good enough.
DGW3 calculates diff based on the 24 last blocks.
When there's a long blocktime, and then someone mines 1 block, then clevermining takes 23 blocks, the long blocktime block is not taken into the calculation anymore, and the diff spikes.
Now I hear you say: "why don't we increase the number of blocks taken into the DGW3 calculation". Well, I did some simulations and I believe in the end that will only affect the number of blocks clevermining gets before the diff spikes.

So we need something clever (no pun intended).

There are two methods:
- create a re-adjustment algorithm that is actually pretty smart, detecting patterns, applying penalties if a lot of blocks were mined in short time.
- work out how a block reward based on block time. e.g.: `reward = 1000 * (secsSinceLastBlock/150)` with a max of, say, 3000 (after 3x the target blocktime).

Best would be: both.

Please let me know what you think about this!
I'll work out more details this evening (CEST).

Those 2 methods look very interesting to me. It would also make it unique to NLG and that you guys can overcome obstacles on your own. As you know I will continue to support this coin where I can, I have been promoting it with friends and some family members who take the time to understand why Crypto currencies are good. Like Wildwest said there isn't too many coins you can really trust in this crypto space but NLG is certainly one of them.

[Digithusiast]

This network problem seems to hold the Guldencoin development hostage for over a month now. That is a big pity. Hopefully there will be some other good news soon from the team?

[Bluestreet]

This network problem seems to hold the Guldencoin development hostage for over a month now. That is a big pity. Hopefully there will be some other good news soon from the team?

This is a valid point but the blockchain is by far the most important aspect to deal with and it needs to be stable. From where I am sitting it looks like the community is building up the coin and not just the development team which makes nlg even more exciting.

[veertje]

I understand miners quit the Guldencoin and now we have a problem with multipools? why? I thought that multipools are also miners but they are switching between the most pofitable coins. What is the problem with that?

Multipools can jump or lower the total hashrate in an instance with GH/s. When they do, than the algorithm has to adjust to that, but it swings too much to handle it well sometimes and that is not what we want ofcourse.

[veertje]

I still think a longer maturity time for newly minted blocks is a nice and simple feature.

Yes we agree and this is something we could start with.

Is this the BTM solution? That was looking good to temper multipools, but they have problems now as well as it seems. When the maturity time is too high and multipool is leaving, it takes a long time to find the next blocks when there is less total hashpower left?

From the ANN of BTM: https://bitcointalk.org/index.php?topic=660544.msg9253396#msg9253396:

Buck. It's not xhash's fault.  The coins take 720 blocks to confirm and this current round of 720 has taken a few weeks.  Everybody is in the same boat.  In a day or so we will move to the next round of 720, the diff will drop and the whales and multipools will move in and 720 blocks will disappear in a few hours... Then everyone will sit back and wait for the painful process to repeat.

[strataghyst]

I just sent a message to Terk asking if he can take a look at the amount of hashrate thrown at NLG.

DGW3 does better re-adjustment than KGW, but as we can see it's not good enough.
DGW3 calculates diff based on the 24 last blocks.
When there's a long blocktime, and then someone mines 1 block, then clevermining takes 23 blocks, the long blocktime block is not taken into the calculation anymore, and the diff spikes.
Now I hear you say: "why don't we increase the number of blocks taken into the DGW3 calculation". Well, I did some simulations and I believe in the end that will only affect the number of blocks clevermining gets before the diff spikes.

So we need something clever (no pun intended).

There are two methods:
- create a re-adjustment algorithm that is actually pretty smart, detecting patterns, applying penalties if a lot of blocks were mined in short time.
- work out how a block reward based on block time. e.g.: `reward = 1000 * (secsSinceLastBlock/150)` with a max of, say, 3000 (after 3x the target blocktime).

Best would be: both.

Please let me know what you think about this!
I'll work out more details this evening (CEST).

This does look very interesting!

[thsminer]

I just sent a message to Terk asking if he can take a look at the amount of hashrate thrown at NLG.

DGW3 does better re-adjustment than KGW, but as we can see it's not good enough.
DGW3 calculates diff based on the 24 last blocks.
When there's a long blocktime, and then someone mines 1 block, then clevermining takes 23 blocks, the long blocktime block is not taken into the calculation anymore, and the diff spikes.
Now I hear you say: "why don't we increase the number of blocks taken into the DGW3 calculation". Well, I did some simulations and I believe in the end that will only affect the number of blocks clevermining gets before the diff spikes.

So we need something clever (no pun intended).

There are two methods:
- create a re-adjustment algorithm that is actually pretty smart, detecting patterns, applying penalties if a lot of blocks were mined in short time.
- work out how a block reward based on block time. e.g.: `reward = 1000 * (secsSinceLastBlock/150)` with a max of, say, 3000 (after 3x the target blocktime).

Best would be: both.

Please let me know what you think about this!
I'll work out more details this evening (CEST).

At first there are more than two solutions so there is some preselection done.

Readjustments wont work, there is no clever way, because they always come late. How smart you design the algo when it rises and the hashrate drops dramaticaly your stuck with a high diff. Nothing can be done about that. Thats why Sathoshi took a lot of blocks to calculate the diff anyway... If you want to act fast, rejection is the only way so that would have a chance but probably other problems. Another way more elegant would be lowering the diff midstream but that would be a huge change in protocol.

Blocktime based reward looks promising to me but don't put a limit on either side. The coin is designed for 1000 NLG every 150 secs avg. So putting a limit on hard blocks would decrease the supply and those hard blocks are compensated with fast low reward blocks anyway. It also would be an incentive for miners to stay at high diff because the jackpot is rising.

[WaterLooDown]

Just to continue with what Geert has said, we will have to come up with our own solution catered towards the guldencoin blockchain. DGW works for darkcoin and Digishield works for digibyte but it doesn't mean there solution works for every other coin perfectly. Also when changing things it's not just about sorting out the block times , securtiy, stability, vulnerabilities, abuse options all need to be looked into with a fine comb.
We will have more updates this week about the plan moving forward but please continue with the discussion, we appreciate the constructive criticism because it means people care about Guldencoin being as close to perfect as humanly possible.

The good news is we have capable developers who are 100% focussed on this and a month isn't long as this is a longterm project and the crypto landscape is always changing and we will have to continually review our processes and development strategy to cater for major changes that could effect the coins network in a positive or negative way.

Please keep the ideas and suggestions coming so we can look at all possible solutions. Together we can get this right!

[veertje]

There is a new coin to be launched with the following specs. Maybe to look at this multi algorithm how that works out for them?

https://bitcointalk.org/index.php?topic=820302.0

Stable Litecoin fork with minor enhancements.
100% Proof of Work
3 confirmations for each transaction
Total coins: 20 Million ONE in 2050
PoW Algorithm Combo: 3S (shavite, simd & skein) with a ~40% speed increase and ~15% power decrease compared to X11(AMD HD 7950)
2 minute block time
DigiShield difficulty retarget
Dificulty retarget every 2 blocks with a max difference of 5%
140 confirmations for blocks to mature
Block halving every 680.000 blocks (~2.5 year)
PoW Total blocks: 1290322

[LTEX]

I have asked  some powerful "friends from the past" to help us out here. One of them for sure will be able to fix this!
I've also asked our Club1680 members to chip in for a bounty to the one that comes up with the final and total answer to this serious issue!

My 150K is already in the pot!

Oh yeah, this is on my calendar today: