Quote from: guldencoin on October 21, 2014, 01:33:52 PM

Quote from: 24Kilo on October 21, 2014, 11:07:22 AM

What I can't understand is why the advice of experienced community members whose expertise is in mining and network security is being ignored, and instead the dev team and community keeps running simulations and chasing some elusive solution.

The Criptoe group is a mining group, between the 5 of us, we have nearly 10 years of mining experience using CPU's, GPU's, and ASIC's across a broad range of coins. We have been involved behind the scenes with a number of coins to test and implement code. I have successfully executed time warp, double spends, and 51% attacks against several coin networks to better learn how to keep a coin network secure and healthy. Criptoe is not a loud and flashy outfit, but we all have real life experience with mining crypto-currency.

This is not a 'told-you-so' or a 'we-are-so-good' post, but the dev team did approach Criptoe to set-up a NLG pool shortly after the launch of NLG. I have been mining NLG since it was a difficulty of 2 or so. I have sold less than 10% of all the NLG I have mined. I am most likely the largest stakeholder of NLG in the world. I am still mining and buying NLG. I have a very vested interest in seeing NLG succeed. And I believe that NLG will succeed for all the same reasons each of you do.

I am not active on the Gulden Forum nor have I joined the 1680 Club, because I don't have time to visit another forum. Just like I don't have time for Twitter, Facebook or any other social media.

Review the posts of Criptoe members, Fuse, JohnDec2, and myself in particular, and you find that our advice was not heeded and we were quite confident in the current outcome.

The problem is being over complicated and confused. Give those of us with experience the opportunity to help and I am pretty confident that a solution can be found with minimal pain and delay.

EDIT - the difficulty on the network just jumped from the high 200's to 699... the network will be unusable for a few hours now... meaning that no transactions will be able to be executed or confirmed outside of LitePaid...

24kilo I am sorry we give you the feeling you are being ignored, we are not ignoring anyone. Of course we welcome you and the other devs to help us find a solution. Let's continue the following discussion about possible solutions.

Quote from: /GeertJohan on October 21, 2014, 08:22:17 AM

replied inline in green

Quote from: thsminer on October 21, 2014, 07:47:30 AM

Quote from: /GeertJohan on October 20, 2014, 09:35:25 PM

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

It would be great to get 24kilos or one of the criptoe crews comments on the above. I also want to see a good solution for Guldencoin as it's the only altcoin I invest in outside of bitcoin.