NA

[Brito]

Don't worry too much about current price a lot of traders sold off to get into Doge, but I think that run is almost over but I see NLG had a lot of support at these prices, 7th highest traded coin on bittrex.
That is healthy!

On Cryptsy it would be 5th highest. Nothing to be concerned about here. Let the devs do there thing.

[ShopemNL]

I have another buy other @ 417, for almost 1million coins.

5.1258   4.9823   1194785.83818345 0.00000417

[Jero]

Big sell again. Seems multipools still love Guldencoin.
Think we see many more, hopefully also new, Guldencoin millionaires coming days...

[BioMike]

I agree about price formation, let the market handle it (if it needs to be lower, so be it). About the diff adjustment, I would prefer the tweaking in the diff change algo we set on to this week. If that worked with other coins, it will work with guldencoin. Making forks to the network will only increase the uncertainty about NLG and that will reflect onto the market (that is what we saw yesterday). In the mean time we need to work as hard as possible to get more merchants accepting NLG and continue with its promotion.

[nigttran]

I has bougt over 500000 NLG price from 402 to 440 sat. I will dump it and still buy into.

Please sell now. I will buy all

[ShopemNL]

Check the buy book vs sell book.

Almost 12 BTC to go to 0.00000333
And only 3.23 BTC to go to 0.00000725

[Brito]

I agree about price formation, let the market handle it (if it needs to be lower, so be it). About the diff adjustment, I would prefer the tweaking in the diff change algo we set on to this week. If that worked with other coins, it will work with guldencoin. Making forks to the network will only increase the uncertainty about NLG and that will reflect onto the market (that is what we saw yesterday). In the mean time we need to work as hard as possible to get more merchants accepting NLG and continue with its promotion.

Are the settings to DGW3 not supporting 1 minute block times instead of the 2 and half minute block times for Guldencoin?

[Brito]

Also want to point something out, more and more people are starting to realize that unneeded tech coins aren't longterm, esp with Dogecoins rise recently. Guldencoin can shoot up over 10000 sat in a couple years time if the merchant adoption rate keeps going as it is.

[ShopemNL]

Also want to point something out, more and more people are starting to realize that unneeded tech coins aren't longterm, esp with Dogecoins rise recently. Guldencoin can shoot up over 10000 sat in a couple years time if the merchant adoption rate keeps going as it is.

Problem = users buy nlg, merchants dump nlg. Ideal would be if merchants keep there nlg to buy stuff somewhere else with nlg

[LTEX]

Let the price drop another 200 sat and we can see if clevermining still has major impact.

If the price go down to a the level we can start building again, for sure I still contribute.
If the price go down too much, let new people invest. That should be great! Build a strong community, one of the major goals.

With time we hit the road again , that time we are ready for sure!

Since I am a buyer and not a seller I don't mind the pricedrop too much. I do mind the reason it is happening though. I have no doubt this will get resolved by the DeVteam however.

I agree 100% that lower price will bring in new enthusiasts. Let's give them a warm welcome and show how positive this community is. What we can do now is show that this coin is happening by introducing new merchants and users.

To support that I will release a series of tools you all can use, ETA, this Wednesday...

[BioMike]

I agree about price formation, let the market handle it (if it needs to be lower, so be it). About the diff adjustment, I would prefer the tweaking in the diff change algo we set on to this week. If that worked with other coins, it will work with guldencoin. Making forks to the network will only increase the uncertainty about NLG and that will reflect onto the market (that is what we saw yesterday). In the mean time we need to work as hard as possible to get more merchants accepting NLG and continue with its promotion.

Are the settings to DGW3 not supporting 1 minute block times instead of the 2 and half minute block times for Guldencoin?

Settings can be changed (what's in a name), that was what I was hinting on. Maybe other settings would work better with NLG.

[BioMike]

Also want to point something out, more and more people are starting to realize that unneeded tech coins aren't longterm, esp with Dogecoins rise recently. Guldencoin can shoot up over 10000 sat in a couple years time if the merchant adoption rate keeps going as it is.

Problem = users buy nlg, merchants dump nlg. Ideal would be if merchants keep there nlg to buy stuff somewhere else with nlg

In the early days of bitcoin there was a vivid discussion about a BTC economy, here on the forum. The idea was to have many varying things to be bought by BTC and no need to USD conversion was needed. The problem was spacial distance between the people supporting this idea. With NLG this would be less of a problem. I have thought about starting a discussion about this on the NLG forum, but haven't gotten to it yet.

<edit>
Started the discussion on the NLG forum
https://forum.guldencoin.com/index.php?topic=564.0
</edit>

[c_e_d]

I honestly think the next solution needs to be the solution.  Not a series of solutions until we get there.

The more changes we make, the more bloated the code becomes to keep track of the changes on the blockchain, and the bigger chance we have of breaking things.  Let the devs and the community come together and figure this out in a rational manner.  Hasty decisions kill coins.

-Fuse

The change of block reward depending on block time I would consider a bigger change but easier to implement. It could start hitting if the time falls below a certain level like 60% (1.5min instead the normal 2.5min), this way it allows smaller variations of hashrate before it kicks in.

The other part of changes I am thinking about is the modification of our DGW3, so that it is able to handle major changes in hashrate like we see them now and will have to expect them even more extrem. Let us develop it further, so it can cope with the problems of the Scrypt ASIC age.
I have looked at several diff adaption algorithm during the last days and still think DGW3 was a good choice.
What I had to realize is, they are all pre scrypt ASIC and none of them is able to handle spike like we see them well enough.
Looks like none expected hashpower like we see them today in the hands of only a few switching pools.
And from what I saw, all of them have what I call the "bad block" problem; none of them can handle a sharp drop of hashrate fast enough and steady miners are left with atleast 1 block with extrem long time to solve.
Think of it as a series of smaller patches to tune DGW3 and when it's done you can call it DGW4 if you want.

And for those talking about 1 min block times: The original DGW3 is using a block time of 2.5 min too.
Shortening block times by a factor of 2.5 would only shorten the times for the bad blocks by the same factor. And on the side of the quick blocks we can easily run into much bigger problems.
We need to work on the problem itself, not make them look smaller.

[BioMike]

I honestly think the next solution needs to be the solution.  Not a series of solutions until we get there.

The more changes we make, the more bloated the code becomes to keep track of the changes on the blockchain, and the bigger chance we have of breaking things.  Let the devs and the community come together and figure this out in a rational manner.  Hasty decisions kill coins.

-Fuse

The change of block reward depending on block time I would consider a bigger change but easier to implement.

Sell pressure on exchanges drops, price shoots up. Switching miners are unimpressed by your efforts (read: they still profit enough to keep doing the things they do).

[c_e_d]

Sell pressure on exchanges drops, price shoots up. Switching miners are unimpressed by your efforts (read: they still profit enough to keep doing the things they do).

Don't shoot that fast 

Nothing implemented yet.
We are discussing to find the best solution for the foreseeable future.
Noone wants a quick shot today and than we need the next mod tomorrow and the day after and ...

[BioMike]

Sell pressure on exchanges drops, price shoots up. Switching miners are unimpressed by your efforts (read: they still profit enough to keep doing the things they do).

Don't shoot that fast 

Nothing implemented yet.
We are discussing to find the best solution for the foreseeable future.
Noone wants a quick shot today and than we need the next mod tomorrow and the day after and ...

Don't worry. Just suggesting a possible problem with the reward drop solution.

[thsminer]

I honestly think the next solution needs to be the solution.  Not a series of solutions until we get there.

The more changes we make, the more bloated the code becomes to keep track of the changes on the blockchain, and the bigger chance we have of breaking things.  Let the devs and the community come together and figure this out in a rational manner.  Hasty decisions kill coins.

-Fuse

The change of block reward depending on block time I would consider a bigger change but easier to implement. It could start hitting if the time falls below a certain level like 60% (1.5min instead the normal 2.5min), this way it allows smaller variations of hashrate before it kicks in.

The other part of changes I am thinking about is the modification of our DGW3, so that it is able to handle major changes in hashrate like we see them now and will have to expect them even more extrem. Let us develop it further, so it can cope with the problems of the Scrypt ASIC age.
I have looked at several diff adaption algorithm during the last days and still think DGW3 was a good choice.
What I had to realize is, they are all pre scrypt ASIC and none of them is able to handle spike like we see them well enough.
Looks like none expected hashpower like we see them today in the hands of only a few switching pools.
And from what I saw, all of them have what I call the "bad block" problem; none of them can handle a sharp drop of hashrate fast enough and steady miners are left with atleast 1 block with extrem long time to solve.
Think of it as a series of smaller patches to tune DGW3 and when it's done you can call it DGW4 if you want.

And for those talking about 1 min block times: The original DGW3 is using a block time of 2.5 min too.
Shortening block times by a factor of 2.5 would only shorten the times for the bad blocks by the same factor. And on the side of the quick blocks we can easily run into much bigger problems.
We need to work on the problem itself, not make them look smaller.

In the light of the last phrase the solution has to be an answer to the question: how do you get the blocktime within certain bounds. Satoshi came with the diff. system we all know as a solution to take care of the fact of varying blocktimes and stabilise them. This difficulty was adjusted every 2016 blocks and that worked very well. Nowadays we have large pools that hop in and out so Dr. Kimoto figured out that the diff. had the be adjusted faster. This also opened several expoits because it was a breach in the security.  

So to cope with the blocktime the diff system does not function anymore as a sole solution. I suggested a solution to this by rejecting the first N seconds of blocks but that was shot because the word reject triggers negative emotions. But is it so different from what we know? In my opinion not. The system is designed to supply 1 coin every 150 seconds, so as long as thats the case every method works and has the same effect. The network also does not have a discriminator and everybody is able to submit his hash. So lets take it to the extreme and reject submitted blocks for 149.99 seconds. the first miner that submits a block gets the coins. That a very honest and social system were jumppools have the same chance as small miners. Problem with this system is you can't guarantee the blocktime because at low hashpower it can take some time to find a hash. But maybe it's doable. Second problem is the current systems security is build around blockmass (this is the effort put in a range of blocks measured by an addition of the diff). So to keep that in place we need the difficulty to identify how much effort was put in this chain. A combination of the two gives a system where it is not possible to submit blocks for lets say 75 seconds and the diff. adjusts the remainder that way blocks are found in an average of 150 seconds. You can still rape it, but the effect is much less than with a diff only. A large pool can get 90% of the blocks and mine in advance, but thats also possible in the currect system and thus another problem. You can even think of a system where you slowly (this must be because the diff has to follow) increase the blocking time in case of a hopper.

Is this reject system a disadvantage for the miner, no because everybody has an equal chance to find blocks within the possible submit window. The hoppers however have to adjust their method because they can't rape the coin and mine 20 blocks in a minute and dispear leaving the pieces for the community. So that only is probably enough to get the hoppers off our back. But even if they adjust their system they face a coin that has a profitwise disadvange over others so the chance of getting hit is deminishing.

I'm sure there are flaws and exploits, but to solve the problems we are facing and especialy gona face the next six months, it's important to leave the paved roads and think out of the box. In that light I am a huge fan of the BTM solution because it effectively eliminates the short term miners and pools.

[nfigueir]

So to cope with the blocktime the diff system does not function anymore as a sole solution. I suggested a solution to this by rejecting the first N seconds of blocks but that was shot because the word reject triggers negative emotions. But is it so different from what we know? In my opinion not. The system is designed to supply 1 coin every 150 seconds, so as long as thats the case every method works and has the same effect. The network also does not have a discriminator and everybody is able to submit his hash. So lets take it to the extreme and reject submitted blocks for 149.99 seconds. the first miner that submits a block gets the coins. That a very honest and social system were jumppools have the same chance as small miners. Problem with this system is you can't guarantee the blocktime because at low hashpower it can take some time to find a hash. But maybe it's doable. Second problem is the current systems security is build around blockmass (this is the effort put in a range of blocks measured by an addition of the diff). So to keep that in place we need the difficulty to identify how much effort was put in this chain. A combination of the two gives a system where it is not possible to submit blocks for lets say 75 seconds and the diff. adjusts the remainder that way blocks are found in an average of 150 seconds. You can still rape it, but the effect is much less than with a diff only. A large pool can get 90% of the blocks and mine in advance, but thats also possible in the currect system and thus another problem. You can even think of a system where you slowly (this must be because the diff has to follow) increase the blocking time in case of a hopper.

Is this reject system a disadvantage for the miner, no because everybody has an equal chance to find blocks within the possible submit window. The hoppers however have to adjust their method because they can't rape the coin and mine 20 blocks in a minute and dispear leaving the pieces for the community. So that only is probably enough to get the hoppers off our back. But even if they adjust their system they face a coin that has a profitwise disadvange over others so the chance of getting hit is deminishing.

I'm sure there are flaws and exploits, but to solve the problems we are facing and especialy gona face the next six months, it's important to leave the paved roads and think out of the box. In that light I am a huge fan of the BTM solution because it effectively eliminates the short term miners and pools.

If I am understanding the proposal properly, it seems a good alternative not because big pools won't be able to find a lot of blocks, because most probably they will be mining most of them, but because it makes the mining not profitable enough and as such they go to the next coin. Once that happens, the block findings will return to the finders who are always mining because big pools have left the building.

Is my interpretation correct?

[Bluestreet]

The best solution is just to keep growing the coin and getting more dedicated miners that stay on Nlg permanently. Then less room for pools to come in and make major profits

[thsminer]

So to cope with the blocktime the diff system does not function anymore as a sole solution. I suggested a solution to this by rejecting the first N seconds of blocks but that was shot because the word reject triggers negative emotions. But is it so different from what we know? In my opinion not. The system is designed to supply 1 coin every 150 seconds, so as long as thats the case every method works and has the same effect. The network also does not have a discriminator and everybody is able to submit his hash. So lets take it to the extreme and reject submitted blocks for 149.99 seconds. the first miner that submits a block gets the coins. That a very honest and social system were jumppools have the same chance as small miners. Problem with this system is you can't guarantee the blocktime because at low hashpower it can take some time to find a hash. But maybe it's doable. Second problem is the current systems security is build around blockmass (this is the effort put in a range of blocks measured by an addition of the diff). So to keep that in place we need the difficulty to identify how much effort was put in this chain. A combination of the two gives a system where it is not possible to submit blocks for lets say 75 seconds and the diff. adjusts the remainder that way blocks are found in an average of 150 seconds. You can still rape it, but the effect is much less than with a diff only. A large pool can get 90% of the blocks and mine in advance, but thats also possible in the currect system and thus another problem. You can even think of a system where you slowly (this must be because the diff has to follow) increase the blocking time in case of a hopper.

Is this reject system a disadvantage for the miner, no because everybody has an equal chance to find blocks within the possible submit window. The hoppers however have to adjust their method because they can't rape the coin and mine 20 blocks in a minute and dispear leaving the pieces for the community. So that only is probably enough to get the hoppers off our back. But even if they adjust their system they face a coin that has a profitwise disadvange over others so the chance of getting hit is deminishing.

I'm sure there are flaws and exploits, but to solve the problems we are facing and especialy gona face the next six months, it's important to leave the paved roads and think out of the box. In that light I am a huge fan of the BTM solution because it effectively eliminates the short term miners and pools.

If I am understanding the proposal properly, it seems a good alternative not because big pools won't be able to find a lot of blocks, because most probably they will be mining most of them, but because it makes the mining not profitable enough and as such they go to the next coin. Once that happens, the block findings will return to the finders who are always mining because big pools have left the building.

Is my interpretation correct?

Yep, thats the idea. But even if those pools stay they are put in a position where the impact on the network is much less. But my assumption is they leave the coin alone because it's not profitable anymore.