Bitcoin Forum
November 16, 2024, 07:54:06 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 [269] 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 ... 676 »
  Print  
Author Topic: NA  (Read 893613 times)
/GeertJohan
Sr. Member
****
Offline Offline

Activity: 409
Merit: 250


View Profile
October 21, 2014, 08:22:17 AM
 #5361

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 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?
Coincookie
Sr. Member
****
Offline Offline

Activity: 249
Merit: 250


View Profile
October 21, 2014, 08:30:25 AM
 #5362


"He said he "has an obligation to his miners",
"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

This. If he's nice, we'll ne nicer, he wants to play hard? We'll play harder, find some way and cut this shit, cut the multipools somehow and get it done, stay on target, finish the mission, allways.

NLG: GNszAQ7Nwhz2E5ygqucYjVV36gV2Nkikzj
24Kilo
Sr. Member
****
Offline Offline

Activity: 672
Merit: 250


View Profile
October 21, 2014, 09:13:55 AM
 #5363

Apologies for the short reply... but any retarget method that rejects blocks based on time(example - reject a block that is found less than 60(or whatever number you choose) seconds after the previous block... is a huge exploit and leaves the network wide open for a fatal attack... both time warp and double spend.

Here is my recommendation...

Bring Terk and Clevermining on board, so we can real world test the algo and either tweak DGW3 or implement Digishield which has been successfull in POT.

I am opposed to IP banning, but if that is what needs to be done to protect the network and is the voice of the community, then so be it.

NLG has become virtually unusable... more damage is being done by doing nothing than by openly admitting that we are looking for a solution and announcing that there will be a period weeks or months of code and wallet updates to find a solution... being proactive and vocal will let the wider community know that NLG is adapting and maturing, if there are some growing pains.
LTEX
Legendary
*
Offline Offline

Activity: 1025
Merit: 1000


ltex.nl


View Profile WWW
October 21, 2014, 09:36:23 AM
 #5364


Time to put our Guldens where our mouth is  Wink

A fool will just look at the finger, even if it points to paradise!
strataghyst
Sr. Member
****
Offline Offline

Activity: 393
Merit: 250


View Profile
October 21, 2014, 09:41:24 AM
 #5365


Time to put our Guldens where our mouth is  Wink

Did you hear something from nite yet?
Digithusiast
Hero Member
*****
Offline Offline

Activity: 886
Merit: 504



View Profile
October 21, 2014, 09:47:59 AM
 #5366

Sorry, but I am getting the feeling Guldencoin's planning and decision making is influenced a lot by the (foreign) Mining pools.

Is that really what the Guldencoin team wants?

What happened to the primary goal of Guldencoin to become the new digital currency for the Dutch people to be used in daily life in stores in The Netherlands?

The foreign pools and their miners are in for trading and making a buck, -and that is fine-, but is not really helping the Guldencoin goal mentioned above.

Maybe Guldencoin could work out a way to have more NLG distributed among the Dutch.
There are already a lot of merchants but far too little Dutch consumers having a wallet or even using NLG.

If we can increase the number of Guldencoin users in The Netherlands, it will boost the coin and also the value for the current big holders and miners that might not like this domestic focus.

How about starting a free distribution model among open wallets with IP's coming from The Netherlands? (like the new MCL coin is doing rather sucesfully at this time with over 5000 wallets in less than 2 weeks; every hour 5000 coins are divided by the number of opened wallets) If we would start such a campaign through social media informing the people to download and keep the the Guldencoin wallet open from i.e. 1 nov to 1 dec. to receive a percentage of coins [x coins every hour/divided by the number of open wallets] that could become a big hype and boost for Guldencoin.

Or maybe change to a cpu-mining algo like M7M (see XMG) to make mining more fair.

LTEX
Legendary
*
Offline Offline

Activity: 1025
Merit: 1000


ltex.nl


View Profile WWW
October 21, 2014, 09:58:50 AM
 #5367

Sorry, but I am getting the feeling Guldencoin's planning and decision making is influenced a lot by the (foreign) Mining pools.

Is that really what the Guldencoin team wants?

What happened to the primary goal of Guldencoin to become the new digital currency for the Dutch people to be used in daily life in stores in The Netherlands?

The foreign pools and their miners are in for trading and making a buck, -and that is fine-, but is not really helping the Guldencoin goal mentioned above.

Maybe Guldencoin could work out a way to have more NLG distributed among the Dutch.
There are already a lot of merchants but far too little Dutch consumers having a wallet or even using NLG.


If we can increase the number of Guldencoin users in The Netherlands, it will boost the coin and also the value for the current big holders and miners that might not like this domestic focus.

How about starting a free distribution model among open wallets with IP's coming from The Netherlands? (like the new MCL coin is doing rather sucesfully at this time with over 5000 wallets in less than 2 weeks; every hour 5000 coins are divided by the number of opened wallets) If we would start such a campaign through social media informing the people to download and keep the the Guldencoin wallet open from i.e. 1 nov to 1 dec. to receive a percentage of coins [x coins every hour/divided by the number of open wallets] that could become a big hype and boost for Guldencoin.

Or maybe change to a cpu-mining algo like M7M (see XMG) to make mining more fair.


work is in progress my friend, but at present time attention needs to be devided. But in case you have forgotten....:





Sometimes, when following a coin with a long term vision, one has to practice patience  Wink

A fool will just look at the finger, even if it points to paradise!
LTEX
Legendary
*
Offline Offline

Activity: 1025
Merit: 1000


ltex.nl


View Profile WWW
October 21, 2014, 10:00:06 AM
 #5368


Time to put our Guldens where our mouth is  Wink

Did you hear something from nite yet?

Not yet, and I mailed him to his direct address, but this might draw his attention ;-)

A fool will just look at the finger, even if it points to paradise!
Buerra
Legendary
*
Offline Offline

Activity: 980
Merit: 1000


View Profile
October 21, 2014, 10:06:39 AM
 #5369

Sorry, but I am getting the feeling Guldencoin's planning and decision making is influenced a lot by the (foreign) Mining pools.

Is that really what the Guldencoin team wants?

What happened to the primary goal of Guldencoin to become the new digital currency for the Dutch people to be used in daily life in stores in The Netherlands?

The foreign pools and their miners are in for trading and making a buck, -and that is fine-, but is not really helping the Guldencoin goal mentioned above.

Maybe Guldencoin could work out a way to have more NLG distributed among the Dutch.
There are already a lot of merchants but far too little Dutch consumers having a wallet or even using NLG.

If we can increase the number of Guldencoin users in The Netherlands, it will boost the coin and also the value for the current big holders and miners that might not like this domestic focus.

How about starting a free distribution model among open wallets with IP's coming from The Netherlands? (like the new MCL coin is doing rather sucesfully at this time with over 5000 wallets in less than 2 weeks; every hour 5000 coins are divided by the number of opened wallets) If we would start such a campaign through social media informing the people to download and keep the the Guldencoin wallet open from i.e. 1 nov to 1 dec. to receive a percentage of coins [x coins every hour/divided by the number of open wallets] that could become a big hype and boost for Guldencoin.

Or maybe change to a cpu-mining algo like M7M (see XMG) to make mining more fair.



Proof of Dutch eh? Haha. I hear what you are saying. Mining is an important aspect of the network though, but your points are also valid. We're at some sort of crossroads. More users outside of cryptocurrency is what's needed in my opinion. And getting NLG used in NL as currency is still going on, Bitcointalk forums aren't really the place to follow Guldencoin's progress all too much. If you go to guldencoinforum.com (also have an English section) you'll see there is more done than just the DGW3.

To let everyone know. I've been contacting a lot of merchants and there will be a few new ones installing NLG and BTC in their checkout system in the next following days. Some also signed up for the official forums. Official big announcements will follow of course Wink

One more thing:
Litepaid has a referral system that pays out a percentage of each transaction fee and total purchase amount from merchants you bring on. The best part is. They pay out in Bitcoin, Litecoin and you guessed it Guldencoin! Even more incentive to get merchants now Wink
BioMike
Legendary
*
Offline Offline

Activity: 1658
Merit: 1001


View Profile
October 21, 2014, 10:34:20 AM
 #5370

Sorry, but I am getting the feeling Guldencoin's planning and decision making is influenced a lot by the (foreign) Mining pools.

Is that really what the Guldencoin team wants?

Exactly the same issue I have with this as well. I started renting hashing power again (~2GH/s now) to combat this. It worked before my "forced" leave, it will work again (check price ramp up from 28 sept to 5 Oct). If more people would do it this, the whole switched mining issue would be non-existent. My last batch of mined NLGs via this way would sell for 630 sat to break even... that is not so much (especially when clevermining isn't dumping so much anymore).
Buerra
Legendary
*
Offline Offline

Activity: 980
Merit: 1000


View Profile
October 21, 2014, 10:40:42 AM
 #5371

Sorry, but I am getting the feeling Guldencoin's planning and decision making is influenced a lot by the (foreign) Mining pools.

Is that really what the Guldencoin team wants?

Exactly the same issue I have with this as well. I started renting hashing power again (~2GH/s now) to combat this. It worked before my "forced" leave, it will work again (check price ramp up from 28 sept to 5 Oct). If more people would do it this, the whole switched mining issue would be non-existent. My last batch of mined NLGs via this way would sell for 630 sat to break even... that is not so much (especially when clevermining isn't dumping so much anymore).

I rented 210MHs for 3 days.
LTEX
Legendary
*
Offline Offline

Activity: 1025
Merit: 1000


ltex.nl


View Profile WWW
October 21, 2014, 10:58:54 AM
 #5372

Sorry, but I am getting the feeling Guldencoin's planning and decision making is influenced a lot by the (foreign) Mining pools.

Is that really what the Guldencoin team wants?

Exactly the same issue I have with this as well. I started renting hashing power again (~2GH/s now) to combat this. It worked before my "forced" leave, it will work again (check price ramp up from 28 sept to 5 Oct). If more people would do it this, the whole switched mining issue would be non-existent. My last batch of mined NLGs via this way would sell for 630 sat to break even... that is not so much (especially when clevermining isn't dumping so much anymore).

Good one Mike! Some of us are looking into that as well. I also purchased a couple of the new Zeus Miners, expect LTEX on top of the pools again soon ;-)

Maybe we could setup a dedicated 1680-pool for NLG. "Fearless miners ONLY!"  Grin

A fool will just look at the finger, even if it points to paradise!
24Kilo
Sr. Member
****
Offline Offline

Activity: 672
Merit: 250


View Profile
October 21, 2014, 11:07:22 AM
Last edit: October 21, 2014, 11:57:15 AM by 24Kilo
 #5373

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...
veertje
Legendary
*
Offline Offline

Activity: 952
Merit: 1000


View Profile
October 21, 2014, 11:14:59 AM
Last edit: October 21, 2014, 11:35:30 AM by veertje
 #5374

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.

Good post 24Kilo. We need experienced people. We will solve this networkissue with you guys!

We will come stronger out of this and good things to come, don't forget.
LTEX
Legendary
*
Offline Offline

Activity: 1025
Merit: 1000


ltex.nl


View Profile WWW
October 21, 2014, 11:39:48 AM
 #5375

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.

Good post 24Kilo. We need experienced people. We will solve this networkissue with you guys!

We will come stronger out of this and good things to come, don't forget.

Hi 24Kilo, we welcome you to add to the solution! I have read your earlier posts more careful than I did before and you are absolutely right about your above statement.

Although the 500K won't impress you that much, we hope you will help us out, so we can create one of the most amazing coins in Crypto to date!

A fool will just look at the finger, even if it points to paradise!
Wildwest
Sr. Member
****
Offline Offline

Activity: 1569
Merit: 327


Vave.com - Crypto Casino


View Profile
October 21, 2014, 12:07:37 PM
 #5376

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.

Good post 24Kilo. We need experienced people. We will solve this networkissue with you guys!

We will come stronger out of this and good things to come, don't forget.

Hi 24Kilo, we welcome you to add to the solution! I have read your earlier posts more careful than I did before and you are absolutely right about your above statement.

Although the 500K won't impress you that much, we hope you will help us out, so we can create one of the most amazing coins in Crypto to date!

It's funny how life is, when you finally find a coin that is the truth and actually has the brightest of futures it ends up with a real issue. Luckily this one can be solved it would seem with a effort from the experienced miners and development team. I would say don't be shy to get other trustworthy and experienced developers to have a look. Since we using dgw3 maybe the darkcoin dev could review the algorithm implementation?

Wildwest
Sr. Member
****
Offline Offline

Activity: 1569
Merit: 327


Vave.com - Crypto Casino


View Profile
October 21, 2014, 12:10:36 PM
 #5377

Sorry, but I am getting the feeling Guldencoin's planning and decision making is influenced a lot by the (foreign) Mining pools.

Is that really what the Guldencoin team wants?

Exactly the same issue I have with this as well. I started renting hashing power again (~2GH/s now) to combat this. It worked before my "forced" leave, it will work again (check price ramp up from 28 sept to 5 Oct). If more people would do it this, the whole switched mining issue would be non-existent. My last batch of mined NLGs via this way would sell for 630 sat to break even... that is not so much (especially when clevermining isn't dumping so much anymore).

Good one Mike! Some of us are looking into that as well. I also purchased a couple of the new Zeus Miners, expect LTEX on top of the pools again soon ;-)

Maybe we could setup a dedicated 1680-pool for NLG. "Fearless miners ONLY!"  Grin

This could help a lot until the price rises beyond a point that the added hash rate from dedicated miners is not good enough, but for short term it's a great solution.

Wildwest
Sr. Member
****
Offline Offline

Activity: 1569
Merit: 327


Vave.com - Crypto Casino


View Profile
October 21, 2014, 02:03:15 PM
 #5378

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.

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

ny2cafuse
Legendary
*
Offline Offline

Activity: 1582
Merit: 1002


HODL for life.


View Profile
October 21, 2014, 02:39:37 PM
 #5379

I believe this is the solution:

unsigned int static DarkGravityWave3(const CBlockIndex* pindexLast, const CBlockHeader *pblock) {
    /* current difficulty formula, darkcoin - DarkGravity v3, written by Evan Duffield - evan@darkcoin.io */
    const CBlockIndex *BlockLastSolved = pindexLast;
    const CBlockIndex *BlockReading = pindexLast;
    const CBlockHeader *BlockCreating = pblock;
    BlockCreating = BlockCreating;
    int64 nActualTimespan = 0;
    int64 LastBlockTime = 0;
    int64 PastBlocksMin = 12;
    int64 PastBlocksMax = 12;

    int64 CountBlocks = 0;
    CBigNum PastDifficultyAverage;
    CBigNum PastDifficultyAveragePrev;

    if (BlockLastSolved == NULL || BlockLastSolved->nHeight == 0 || BlockLastSolved->nHeight < PastBlocksMin) {
        // This is the first block or the height is < PastBlocksMin
        // Return minimal required work. (1e0fffff)
        return bnProofOfWorkLimit.GetCompact();
    }
   
    // loop over the past n blocks, where n == PastBlocksMax
    for (unsigned int i = 1; BlockReading && BlockReading->nHeight > 0; i++) {
        if (PastBlocksMax > 0 && i > PastBlocksMax) { break; }
        CountBlocks++;

        // Calculate average difficulty based on the blocks we iterate over in this for loop
        if(CountBlocks <= PastBlocksMin) {
            if (CountBlocks == 1) { PastDifficultyAverage.SetCompact(BlockReading->nBits); }
            else { PastDifficultyAverage = ((PastDifficultyAveragePrev * CountBlocks)+(CBigNum().SetCompact(BlockReading->nBits))) / (CountBlocks+1); }
            PastDifficultyAveragePrev = PastDifficultyAverage;
        }

        // If this is the second iteration (LastBlockTime was set)
        if(LastBlockTime > 0){
            // Calculate time difference between previous block and current block
            int64 Diff = (LastBlockTime - BlockReading->GetBlockTime());
            // Increment the actual timespan
            nActualTimespan += Diff;
        }
        // Set LasBlockTime to the block time for the block in current iteration
        LastBlockTime = BlockReading->GetBlockTime();     

        if (BlockReading->pprev == NULL) { assert(BlockReading); break; }
        BlockReading = BlockReading->pprev;
    }
   
    // bnNew is the difficulty
    CBigNum bnNew(PastDifficultyAverage);

    // nTargetTimespan is the time that the CountBlocks should have taken to be generated.
    int64 nTargetTimespan = CountBlocks*nTargetSpacing;

    // Limit the re-adjustment to 2x or 0.5x
    // We don't want to increase/decrease diff too much.
    if (nActualTimespan < nTargetTimespan/2)
        nActualTimespan = nTargetTimespan/2;
    if (nActualTimespan > nTargetTimespan*2)
        nActualTimespan = nTargetTimespan*2;


    // Calculate the new difficulty based on actual and target timespan.
    bnNew *= nActualTimespan;
    bnNew /= nTargetTimespan;

    // If calculated difficulty is lower than the minimal diff, set the new difficulty to be the minimal diff.
    if (bnNew > bnProofOfWorkLimit){
        bnNew = bnProofOfWorkLimit;
    }
   
    // Some logging.
    // TODO: only display these log messages for a certain debug option.
    printf("Difficulty Retarget - Dark Gravity Wave 3\n");
    printf("Before: %08x %s\n", BlockLastSolved->nBits, CBigNum().SetCompact(BlockLastSolved->nBits).getuint256().ToString().c_str());
    printf("After: %08x %s\n", bnNew.GetCompact(), bnNew.getuint256().ToString().c_str());

    // Return the new diff.
    return bnNew.GetCompact();
}


Essentially we need the difficulty change to happen faster, but it would be a lesser change.  Calculating the difficulty on 24 blocks would mean at least 2 HIGH difficulty blocks.  That jacks up the moving average.  The difficulty on average would be higher, but it should even out a little bit better.  At least in my mind that's how it would work.

-Fuse

Community > Devs
/GeertJohan
Sr. Member
****
Offline Offline

Activity: 409
Merit: 250


View Profile
October 21, 2014, 02:59:33 PM
 #5380

@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.
Pages: « 1 ... 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 [269] 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 ... 676 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!