To ilustrate the behaviour we experience look at the blocks below. At 137136 we had a diff of 412 and because the block preceding this took two hours the diff dropped to 118. But the max drop is 1/3 so it should have dropped to 138 and not 118. The dif lowers and despite blocktimes of tens of seconds it lowers and lowers. Till 137159 then the calculation says hoooo fellas this is too fast and it raises the diff from 29.8 to 162.1 not exactly the max three times that was in the DGW design... So why does is diff adjusted more than the DGW design? And second it can behave much better if it is a weighted average instead of a plain one.
+1 for the detailed info, mate. I'm with you 100%. I really do believe either looking at less blocks for the average, or creating a weighted average is the way to go. Additionally, there needs to be a limit in the amount of difficulty increase/decrease so we're not throwing the difficulty all over the place. Again- less extreme changes that happen more often. -Fuse I think we're on a good path here! I've actually started implementing a new algorithm, from scratch. It performs faster re-adjustment, limited to 1.2 or 0.8 difficulty change between individual blocks. But it also limits the difficulty change to 3.0 or 0.33 compared to the last 120 blocks difficulty average. This means that the diff can rise ~3.0 times in 6 blocks, and it can fall to ~0.33 times in 5 blocks. In the linked formula's the impact of the new blocks themselves are not calculated in the 120 blocks average. The idea behind this is that it will be able to handle large joins and leaves, but won't be tricked into settling on a high difficulty too fast. Thoughts? I'll share the code when I'm happy with initial implementation. |
|
|
|
|
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
DGW3 was not modified, except for some code comments and alignment. It looks like DGW3 is calculating correctly, the problem is that it was not created for jump pools at this scale. I have been thinking about increasing the number of blocks into calculation (currently 24). But I'm affraid that it will only result in multipools getting more blocks before the diff spikes. What do you think?
No, what I meant is the fact that two seperate dampening solutions that should work pretty well jump around like crazy. That made me wonder, maybe its not the KGW or DGW code but something that precedes or supercedes it. You maybe could ask Rijk what exactly was done about the KGW problem back in April, because then KGW went haywire. It's just a wild guess, but it's strange that we have more problems with those jump pool than other coins.
I agree, it could be something else. Something not related to KGW or DGW. But when doing the math (and I'm sure you've done it too) it makes sense that it's simply DGW not being able to handle the huge amount of hash/sec
|
|
|
|
|
@ny2cafuse
The idea is good, but it's not a complete fix. Multipools could still mine up to 11 blocks directly after a high diff block was mined (which probably took some hours).
This is because the actualTimespan is several hours, while the targetTimespan is 12*2.5=30 minutes. With this changes that would cause a diff x2 directly when the high diff block is >12 blocks ago in the chain (and not taken into calculation anymore). Because at that point, only blocks with a timespan of several seconds are in the DGW3 calculation, so the diff factor maxes out to 2.0
I think this is a step in the right direction, but there's more required for a full fix.
|
|
|
|
replied inline in green
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
How would you randomise the timeout? The consensus algorithm for bitcoin/guldencoin is that the miner creates the blocks, and the data is confirmed by all other nodes. So the miner would decide the 'random', and no-one could check if it is truly random. One could use the block hash as input for the timeout time calculation, that would make it pseudo-random I guess.. But in both cases: the miner knows the new timeout, and can directly start mining the next block, he doesn't even have to broadcast the first block yet (giving other miners a huge disadvantage). In the end, a multi-GH/s pool can mine a 'perfect' row of blocks in advance, while the dedicated miners have just a few blocks, and will lose in a chainsplit.
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 think there should be a limit but it should be higher, maybe 10.000 NLG for a block that is 1500 seconds after previous block. The reason I want a limit at some point is because otherwise a huge pool could exploit the system by creating a huge diff (getting small miners stuck), waiting a few hours, then mining that one huge-diff block worth 100.000 NLG.
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 procedureDGW3 was not modified, except for some code comments and alignment. It looks like DGW3 is calculating correctly, the problem is that it was not created for jump pools at this scale. I have been thinking about increasing the number of blocks into calculation (currently 24). But I'm affraid that it will only result in multipools getting more blocks before the diff spikes. What do you think?
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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).
|
|
|
|
We have received some reports that receiving coins shortly after downloading/installing the Android app is not working. The android developer, Nuno, is looking into it. We hope to have a fix soon. We have noticed that a rescan (settings > reset chain) a while after the initial install (2 hours, to be sure) will get you your coins back. Please make sure to always back-up the wallet before starting to use it. For feedback and reactions, please see this topic: https://forum.guldencoin.com/index.php?topic=618.0 |
|
|
|
Hello everyone! I've got a nice little update for y'all! A great number of people have asked us, the team, about statistics and insight on the Guldencoin premine and distribution. We've always replied that this was on the TODO list, and would create this as soon as we've got the time for it. Today, it's been taken off the TODO list. Ladies and gentlemen, I present to you: https://distribution.guldencoin.comIt displays the number of coins we have in cold storage, statistics on the distribution requests, and developer premine usage. Please let me know what you think. As always: feedback is welcome  In other news, DGW3 has settled.. we still have some spikes now and then but not as large as we had with KGW. The best thing to happen now is more miners joining the network. I'm still thinking about some other solutions that might stabilize block times, but they're pretty aggressive and I hope we'll never need to implement and deploy those.. |
|
|
|
Wow LTEX, that looks pretty awesome! How many cards do you have? Are you planning to distribute these cards to other community members? Cheers, Geert-Johan |
|
|
|
Let the price drop another 200 sat and we can see if clevermining still has major impact.
Really, this is not a solution in any way. |
|
|
|
The blockexplorer says Clever finds blocks in a few seconds. The truth is that they might find blocks much faster (about 12 blocks within a second?). That's faster then the blockexplorer can proces. I saw around 12 blocks with age -1Y at the same moment. Why is the algo allow that?
The difference in power between dedicated miners and Clever is way out of control. Boosting the dedicated miners I see as only solution. If we manage to mine the hard blocks quicker then the diff will not fall that much.
The timestamps are in the block itself. The block explorer can easily process 50 blocks per second. The "-1y" is a feature in displaying time that is in the future.. The timestamp in a block can be set in the future when the miner doesn't have his clock synced properly. |
|
|
|
|
Right so I agree that Terk should throw less GH/s at NLG. But I don't want to ban IP's. Besides that there are literally thousands of ways to work around IP bans. Especially when it's about profit.
I think the fix should be governed by the software itself. A consensus between all nodes.
There's not too much smart stuff you can do with the diff re-adjustment; in the end the problem simply is that a jump pool cannot be predicted and that the diff re-adjusts towards 2.5 minute blocktime. It's really hard to take 200 GH/s into account.
Fuse (and others) what do you think about the formula that the block reward is 1000/150*<seconds-since-last-block> with a max of 1000 per 150 seconds?
This makes sure that jumping with large GH/s is not profitible, because there's a max of 1000 coins being released per 150 seconds..
So IF the diff is low, a 300GH/s cluster could only be used to generate a block of 900-1000 coins close to the 2.5 minute mark, this doesn't affect the difficulty because blocks are mined at the correct time..
I think this, combined with DGW3, will cause a more stable blockchain.
|
|
|
|
Hi all,
As everyone can see DGW3 is not working as good as epxected. It's still better than KGW, but not good enough.
Forcing the price down on the exchanges seems like a bad idea to me. We need a hgih and stable price so Guldencoin can become mainstream. Forcing the price down does not move us in the right direction.
Having a miners whitelist is very difficult solution. For starters, it will make the coin more centralized. Because we need someone to decide which miners get whitelist and which don't. I for one do not intend to be that person. I think we need solution that manages itself.
Difficulty adjustment between blocks will cause more blocks to be mined than actually required... So more than 1 block per 2.5 minute on average.
There are also more complicated problems when having diff adjustment between blocks.. (could be misused easily)
A different solution I'm thinking off is to change the blockreward to be 1000/150*<secs-since-previous-block> with a maximum of 1000.
I need to do some research if this is actually possible and if it doesn't create more problems..
For now I'll contact Terk and ask if he can dial down the hashrate thrown at NLG again, this isn't in his best interest either.
Have you looked into Digishield? Well i dont know what algo adjustments are the best so i leave the choices up to you.. Yes, Digishield won't solve this problem.. |
|
|
|
|
Hi all,
As everyone can see DGW3 is not working as good as epxected. It's still better than KGW, but not good enough.
Forcing the price down on the exchanges seems like a bad idea to me. We need a hgih and stable price so Guldencoin can become mainstream. Forcing the price down does not move us in the right direction.
Having a miners whitelist is very difficult solution. For starters, it will make the coin more centralized. Because we need someone to decide which miners get whitelist and which don't. I for one do not intend to be that person. I think we need solution that manages itself.
Difficulty adjustment between blocks will cause more blocks to be mined than actually required... So more than 1 block per 2.5 minute on average.
There are also more complicated problems when having diff adjustment between blocks.. (could be misused easily)
A different solution I'm thinking off is to change the blockreward to be 1000/150*<secs-since-previous-block> with a maximum of 1000.
I need to do some research if this is actually possible and if it doesn't create more problems..
For now I'll contact Terk and ask if he can dial down the hashrate thrown at NLG again, this isn't in his best interest either.
|
|
|
|
I am right here but this was in the very capable hands of Geert-Johan, who did an amazing job. Also thanks to the community, pool operators, exchanges, miners. Great job guys! He, he, daar istie  Gefeliciteerd met deze geslaagde upgrade, Rijk en het hele team!  Geert-Johan helemaal toppie gedaan!! Thanks everyone! I must mention that Nuno Figueiredo did the android update real fast once the new software was released. Great job! WaterLooDown and Buerra made contact with most miners, exchanges and payment providers to notify them about the update. They also did a great job! Cheers! |
|
|
|
|
The magic story
So. We've been asked multiple times by several people: why don't you just pick a block in the future at which point we'll switch to DGW3? Why all this "seeds down, pick a block, seeds up" stuff?
And they were right.. I would have been easier to fork that way. Everyone could update in advance and it wouldn't create any downtime.
The truth is, we've changed more than we announced. And we have a very good reason for that.
We discovered that the protocol magic in Guldencoin was the same as Litecoin's protocol magic..
The protocol magic is a set of bytes that is sent at the beginning of a message between two nodes. If the protocol magic is correct, the nodes continue to talk with each other. If it is incorrect, the nodes simply disconnect.
Because our magic was equal to Litecoin's magic, an attacker could connect to a NLG node, and send the NLG node an ip address for a LTC node. They would connect and start arguing about blocks and transactions. This would result in one node banning the other node for "misbehaving" (sending incompatible blocks). So an attacker could connect to an exchange's LTC node and send it the addresses for our seeds. The LTC exchange node would connect to the NLG seeds and the seeds would ban the exchanges address, or the other way around.
This could've been abused by an attacker to cause fragmented networks, possibly forks, and miners/exchanges being disconnected from the network.
With 1.3, this has been fixed. We now have a new protocol magic.
The reason we didn't announce this before actually forking is quite simple; we didn't want to give an attacker this information.
Changing the magic does not affect the coin in any other way, it's really only a low-level protocol property.
/GeertJohan
|
|
|
|
We're still watching how DGW3 behaves.. I suspect it will makes some... waves... because of the long wait during the fork... Android wallet has also been updated, it could take a while before the new version is visible in the play store. New desktop wallets available at https://guldencoin.com/download |
|
|
|
|
Show Posts
