NA

[strataghyst]

I know this might sound like a crazy idea but why don't we let the price fall to around 300 and then the ratio between dedicated miners and multipools will decrease. Then after it's fixed we can start buying again? This would require a lot of collaboration I know but if everyone just removes there buy orders and let the price drop, the multipools will sell out at any price.

Don't worry about the price so much. This will happen naturally when no solution is there. Price manipulation is never a good idea in my opinion.

[1714884648]

1714884648

[1714884648]

1714884648

[veertje]

Kom nooit meer met een lege batterij te zitten bestel onze 10400mAh Powerbank! Verkrijgbaar in diverse kleuren.
Slechts € 29,95

Nice one Shopem! Number 55  

[bram_vnl]

Kom nooit meer met een lege batterij te zitten bestel onze 10400mAh Powerbank! Verkrijgbaar in diverse kleuren.
Slechts € 29,95

Nice one Shopem! Number 55  

no backupoplader.nl is not 55 already on my site http://www.guldencoinlinks.nl/betalen.html

[/GeertJohan]

Terk just got back to me on PM, Clevermining is now using 50% hashrate on NLG. I hope this will give us a bit more stability while we work on a solution.

[veertje]

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

Ask Terk to totally stop this mulipoolmining on NLG. It is in best interest for cryptoland in general to support NLG and leave NLG with dedicated miners. There are other shitcoins to profit from. I really don't understand why Clevermining is doing this. 

Edit: Simultane post, I see now

Terk just got back to me on PM, Clevermining is now using 50% hashrate on NLG. I hope this will give us a bit more stability while we work on a solution.

[ny2cafuse]

Ask Terk to totally stop this mulipoolmining on NLG. It is in best interest for cryptoland in general to support NLG and leave NLG with dedicated miners. There are other shitcoins to profit from. I really don't understand why Clevermining is doing this.

I literally asked to stop all together when when we first did the DGW3 implementation.  He said he "has an obligation to his miners", and that the devs would need to fix the issue instead of him stopping mining.  He ramped down mining, and you can see the result of that over the last month with his 70-90% network ownership.  Keep an eye on the numbers.  I'm sure you'll see the same after this decrease in hashrate.

IMO, whatever solution is put in place needs to be a solution to completely cut multipools out of the game.  We shouldn't be trying to cater to the multipools needs.  Cut clever out of the game and say "we have an obligation to our community".

-Fuse

[veertje]

IMO, whatever solution is put in place needs to be a solution to completely cut multipools out of the game.  We shouldn't be trying to cater to the multipools needs.  Cut clever out of the game and say "we have an obligation to our community".

Could it be that multipools are sponsored by the btc-richlist? They should embrace NLG instead of being destructive. If it stays this way, better cut them out indeed if possible, I agree.

[LTEX]

IMO, whatever solution is put in place needs to be a solution to completely cut multipools out of the game.  We shouldn't be trying to cater to the multipools needs.  Cut clever out of the game and say "we have an obligation to our community".

Could it be that multipools are sponsored by the btc-richlist? They should embrace NLG instead of being destructive. If it stays this way, better cut them out indeed, I agree.

Not that I know of But hey, I do like conspiracy theories

[ny2cafuse]

Not that I know of But hey, I do like conspiracy theories

I know it's totally off-topic in a time of serious discussion, but I've got a doozy of a conspiracy theory I came up with the other day regarding gold, BTC, and China's grand scheme to destroy the US economy.  I'll have to tell it to you some time .

-Fuse

[Meije]

Not that I know of But hey, I do like conspiracy theories

I know it's totally off-topic in a time of serious discussion, but I've got a doozy of a conspiracy theory I came up with the other day regarding gold, BTC, and China's grand scheme to destroy the US economy.  I'll have to tell it to you some time .

-Fuse

You should listen to Alex Jones, he's the guy that knows everything about that.

[/GeertJohan]

Hi all,

Thanks everyone for taking part in this discussion! It's very important that we discuss and work together towards a solution!

Lower price
I agree with ny2cafuse: when the price drops there will still be profitable blocks (the low diff ones) that are going to be mined by the multipools. I also agree with strataghyst: price manipulation is a bad idea in general. Furthermore, the price must go up at one point.. So even if a lower price would fix, it won't be a permanent solution.

Different diff readjusment
I agree with thsminer: changing the diff readjustment is not a complete solution. I should've been more verbose in my earlier post. I think we can change the diff readjustment more so it fits better with Guldencoin's specs and performs better. But it won't be a complete solution. The scale and speed of the multipools is simply too large relative to our dedicated miners.

Longer coin maturity
If I was going to set up a multi-pool, I would start by mining 20 blocks; 20.000 NLG. Lets call it a "buffer". I would put those buffer coins in the exchange wallet. Then I would write software that watches the exchange rate and coin difficulty to calculate the profitability. When the coin is profitable, the software directs the miners to start mining x blocks until the diff is so high that it isn't profitable anymore. Say 10 blocks are mined, the software would directly sell 10.000 NLG from the buffer on the exchange. Once the 10 mined blocks have matured, those coins are sent to the buffer (exchange wallet). Then the whole process starts over again.
I don't know for sure if clevermining works this way, but it's trivial to implement. Therefore, increasing the coin maturity duration only requires multi-pools to have a larger buffer so they can bridge the maturity time. At the same time, a long coin maturity is a huge downside for independent and smaller miners.. So I'm a bit divided on this one.. It might help, but only as long as multi-pools haven't worked around it yet.. And it has downsides for small independent miners, the ones that are dedicated to our network.

Rejecting blocks
This sounds like a good idea, but I'm afraid it can be bypassed fairly easy. A multi-pool could implement some software to premine blocks with future timestamps, and broadcast those future blocks when the time is right (while the actual mining machines are working on different blocks on a different coin). So in the end, it will still result in multi-pools getting a lot of blocks.

Adjustment between blocks
I've been thinking about changing the diff between blocks. The problem is that a diff based on time is prone to errors and would likely cause chain splits when different miners and nodes are not in sync (clock time). This can be solved by doing a diff change only once every -lets say- 10 minutes. The diff is halved when 10 minutes have past without a block. Because machine times are not always in sync, it needs a graceful period of -lets say- 1 minute before that time. This means nodes can be out of sync for max 1 minute. This actually still a short amount of time, I've seen lots of machines with a wrong time greater than 1 minute. But if you were to take a larger graceful margin, people might try to take advance of that in the form of exploits (halving diff after 9 minutes instead of 10, and hoping for all other nodes to accept it because it's in the grace margin).
I think this might work as a fall back, when a block is 'stuck' for a long time. It does not prevent long blocks in any way.. I think it could be beneficial when the halvation time is pretty high (30 minutes or more, instead of 10), and a grace period being 2 or even 3 minutes.
The bitcoin/guldencoin software was never created with this feature in mind, so it could take a lot of efforts to create this, while it does not directly solve our problem.

Time based block reward
When the block reward is based on the seconds that have past since the previous block, it will discourage multi pools to mine a lot of blocks at once, as it won't be profitable since the reward will be low.
For example: 150 seconds since last block would reward 1000 NLG and 15 seconds would reward 100 NLG.
As pointed out by ny2cafuse: the downside is that "lucky" blocks will have a smaller reward. On the other side, we could change the max block reward to 2000 NLG (rewarded at a block being 300 seconds after the previous block). This means that in the end exactly 1000 NLG per 150 seconds would be generated, regardless of "lucky" or "bad-luck" blocks or jumping pools. To me it's still unclear if there are exploits with this approach (for instance: invalid block times to receive more coins).


I'd love to hear everyones thoughts and feedback.
As mentioned before: Guldencoin is a long term project. It's important that we think about decisions that are being made and achieve good consensus.

Cheers!
Geert-Johan Riemer

[ny2cafuse]

Different diff readjusment
I agree with thsminer: changing the diff readjustment is not a complete solution. I should've been more verbose in my earlier post. I think we can change the diff readjustment more so it fits better with Guldencoin's specs and performs better. But it won't be a complete solution. The scale and speed of the multipools is simply too large relative to our dedicated miners.

I'm still in under the opinion that DGW3 would work with tweaked values.  What needs to happen is the difficulty spikes up almost instantly when clever hits the chain.  Going 10 or so blocks at 10 seconds or less a block is no bueno.  It should pick up on the second, or even third, block and jump the difficulty immediately.  The post I made here explains what I mean visually via the difficulty charts of NLG and POT: https://bitcointalk.org/index.php?topic=554412.msg8992812#msg8992812.  POT uses digishield, but I suspect you could tweak DGW3 to emulate it's behavior.

-Fuse

[c_e_d]

The scale and speed of the multipools is simply too large relative to our dedicated miners.

Rejecting blocks
This sounds like a good idea, but I'm afraid it can be bypassed fairly easy. A multi-pool could implement some software to premine blocks with future timestamps, and broadcast those future blocks when the time is right (while the actual mining machines are working on different blocks on a different coin). So in the end, it will still result in multi-pools getting a lot of blocks.

The target for the block time is 2.5 min
Reject blocks of lets say less than 30 sec or 1 min block time (could even be by same IP). That would take away a reasonable part of the advantage for very high hash power jumping in at low diff.

Adjustment between blocks
... The diff is halved when 10 minutes have past without a block. ...
I think this might work as a fall back, when a block is 'stuck' for a long time. It does not prevent long blocks in any way.. I think it could be beneficial when the halvation time is pretty high (30 minutes or more, instead of 10), and a grace period being 2 or even 3 minutes.
The bitcoin/guldencoin software was never created with this feature in mind, so it could take a lot of efforts to create this, while it does not directly solve our problem.

Dividing it by 4 to bring it back closer to the default block time sounds better.


Anyway, here is what I was thinking about to modify our DGW3 for faster adaption to hash rate changes:
Either take the actual hash rate reading into account (was reading weeks back that a coin did this but can't find it again) or try to predict it by giving the blocks in the interval different weight for the calculation.
The first (oldest) block in the interval gets the lowest weight and increase it to the last (newest) block with the highest weight. Maybe double or triple the weight from one block to the next, so the latest blocks are getting far more important for the next diff.
This way it would react much faster to heavy hash rate changes and would not have a big impact on smaller variations.
I still think the very short blocks should get rejected too; less than 40% of the default time is too short.

[strataghyst]

Time based block rewards seems like a good solution if there are no exploits of course.

But I was thinking can block maturity also be dynamic in the way that if clevermining jumps in diff or hashrate goes up next block has a much longer maturity time?

I don't fully understand coin dynamics just an idea

[Svener]

A lot of good coins are in the process of going POS, even Noble because of the same problems they have. Is this a possible solution for the team? I know the miners will most likely not support the coin anymore because it hurts there own pockets but POS should be a backup plan if there isn't going to be a solution on the mining front.

[bram_vnl]

https://ello.co/guldencoin

[strataghyst]

A lot of good coins are in the process of going POS, even Noble because of the same problems they have. Is this a possible solution for the team? I know the miners will most likely not support the coin anymore because it hurts there own pockets but POS should be a backup plan if there isn't going to be a solution on the mining front.

I dont like pos as this will make rich only richer at this point there to little distribution. If pow works more people have a fair chance of minting coins  Just my opinion.

[Wildwest]

A lot of good coins are in the process of going POS, even Noble because of the same problems they have. Is this a possible solution for the team? I know the miners will most likely not support the coin anymore because it hurts there own pockets but POS should be a backup plan if there isn't going to be a solution on the mining front.

I dont like pos as this will make rich only richer at this point there to little distribution. If pow works more people have a fair chance of minting coins  Just my opinion.

Can I give some pointers to look into before looking at POS.

1. Look at POW coins with similar marketcap to guldencoin.
2. Once you have that list, see which coins have similar block times around 150 seconds.
3. Then check how their blocktimes fluctuate compared to Guldencoin.

I know most basic scrypt coins use digishield but maybe those are all coins with 60 second and under blocktimes.

[thsminer]

Hi all,

Thanks everyone for taking part in this discussion! It's very important that we discuss and work together towards a solution!

Lower price
I agree with ny2cafuse: when the price drops there will still be profitable blocks (the low diff ones) that are going to be mined by the multipools. I also agree with strataghyst: price manipulation is a bad idea in general. Furthermore, the price must go up at one point.. So even if a lower price would fix, it won't be a permanent solution.
I agree it should be left to the market but the theory of lowering diff and higher profit does not make sense here. Normally it would but Clever already mines 80+% of the blocks so whatever diff is in place his gain in NLG would be the same. His profit however would drop with the price.

Different diff readjusment
I agree with thsminer: changing the diff readjustment is not a complete solution. I should've been more verbose in my earlier post. I think we can change the diff readjustment more so it fits better with Guldencoin's specs and performs better. But it won't be a complete solution. The scale and speed of the multipools is simply too large relative to our dedicated miners.


Longer coin maturity
If I was going to set up a multi-pool, I would start by mining 20 blocks; 20.000 NLG. Lets call it a "buffer". I would put those buffer coins in the exchange wallet. Then I would write software that watches the exchange rate and coin difficulty to calculate the profitability. When the coin is profitable, the software directs the miners to start mining x blocks until the diff is so high that it isn't profitable anymore. Say 10 blocks are mined, the software would directly sell 10.000 NLG from the buffer on the exchange. Once the 10 mined blocks have matured, those coins are sent to the buffer (exchange wallet). Then the whole process starts over again.
I don't know for sure if clevermining works this way, but it's trivial to implement. Therefore, increasing the coin maturity duration only requires multi-pools to have a larger buffer so they can bridge the maturity time. At the same time, a long coin maturity is a huge downside for independent and smaller miners.. So I'm a bit divided on this one.. It might help, but only as long as multi-pools haven't worked around it yet.. And it has downsides for small independent miners, the ones that are dedicated to our network.
It's not a final solution and it may support more stable hashrate. Right now the small miners are nowhere so every change for the better is good for the small miners.


Rejecting blocks
This sounds like a good idea, but I'm afraid it can be bypassed fairly easy. A multi-pool could implement some software to premine blocks with future timestamps, and broadcast those future blocks when the time is right (while the actual mining machines are working on different blocks on a different coin). So in the end, it will still result in multi-pools getting a lot of blocks.
Right now a jumpool gets 80+% of the coins in a couple of minutes. Even if such pool mines in advance and drops the block after the timeout expires and we asume a timeout of 75 seconds he could not mine more than 1 block every 75 seconds and thus his gains lower dramaticaly. He would have to adjust his software to act as you described but always have 10 fold less profitaility as other coins. The premining of blocks can be further prevented by randomising the timeout. If he mines in advance he can drop the block till it's accepted but cannot mine the next because he does not know in advance if he's at the right time, if another miner was lucky to be the first, hashing in advance is useless because the next block would not match.So  thats not a problem the real problem can be higher vulnerability to timewarp and a proper calculation has to be done for that

Adjustment between blocks
I've been thinking about changing the diff between blocks. The problem is that a diff based on time is prone to errors and would likely cause chain splits when different miners and nodes are not in sync (clock time). This can be solved by doing a diff change only once every -lets say- 10 minutes. The diff is halved when 10 minutes have past without a block. Because machine times are not always in sync, it needs a graceful period of -lets say- 1 minute before that time. This means nodes can be out of sync for max 1 minute. This actually still a short amount of time, I've seen lots of machines with a wrong time greater than 1 minute. But if you were to take a larger graceful margin, people might try to take advance of that in the form of exploits (halving diff after 9 minutes instead of 10, and hoping for all other nodes to accept it because it's in the grace margin).
I think this might work as a fall back, when a block is 'stuck' for a long time. It does not prevent long blocks in any way.. I think it could be beneficial when the halvation time is pretty high (30 minutes or more, instead of 10), and a grace period being 2 or even 3 minutes.
The bitcoin/guldencoin software was never created with this feature in mind, so it could take a lot of efforts to create this, while it does not directly solve our problem.
brought this up as one of many solutions but is not for the short run and agree not for the initial blocktime problem.

Time based block reward
When the block reward is based on the seconds that have past since the previous block, it will discourage multi pools to mine a lot of blocks at once, as it won't be profitable since the reward will be low.
For example: 150 seconds since last block would reward 1000 NLG and 15 seconds would reward 100 NLG.
As pointed out by ny2cafuse: the downside is that "lucky" blocks will have a smaller reward. On the other side, we could change the max block reward to 2000 NLG (rewarded at a block being 300 seconds after the previous block). This means that in the end exactly 1000 NLG per 150 seconds would be generated, regardless of "lucky" or "bad-luck" blocks or jumping pools. To me it's still unclear if there are exploits with this approach (for instance: invalid block times to receive more coins).
Like I said before NO limits. If there is a very tough block it is a huge incentive to gain thousands of NLG to mine it. Limiting does affect the coin supply. Here again the small miners benefit because they also can have the jackpot when their pool finds a tough block. Okay the luck factor changed from lucky to find a NLG 1000 block in three seconds to finding a NLG 10000 block in 15 minutes, but it's still there. There maybe a drawback however, right now clever stops at high diff but in this case he can wait till the blocktime is over 150+ seconds and wham mines that block fast, waits, leaves the easy low value for the small miners and hits again when the blocktime goes over 150some secs.

I'd love to hear everyones thoughts and feedback.
As mentioned before: Guldencoin is a long term project. It's important that we think about decisions that are being made and achieve good consensus.

Cheers!
Geert-Johan Riemer

Beside all these solutions I still think the problem is the way DGW3 is implemented. It just does not react the way it should and that has nothing to do with being designed for... Because its a counting algo based on the last 24 blocks. One thing that also keeps me busy is the fact that KGW did not work properly either so maybe the solution is at some totally other place in the code. You sometimes see the same strange behaviour when variables are used outside the memory space and overwritten by some other procedure

[bram_vnl]

Social media project


https://www.thunderclap.it/projects/17235-de-gulden-is-weer-terug

7 left

3 days to the end