Wait a minute... the diff algo does not confirm or reject blocks, it adjusts the difficulty... nothing more or less.
Confirming or rejecting blocks based on time stamp requires fundamental changes to the codebase, not tinkering with the diff algo.
Using time stamps to calculate difficulty is one thing, but to use timestamps to confirm or reject blocks is a hacker's delight... you just opened up a massive security hole that lets an attacker use both the codebase and the diff algo to do all sorts of nasty stuff with the network and blockchain.
Topic: NA - page 305. (Read 893613 times)
Sorry I haven't looked at the code.. busy busy busy..
assuming nTargetSpacing == 150, you recommend rejecting a solved block that comes in less than 50 seconds after the last one?.. maybe this is a little too aggressive?.. or not?.. I'm on the fence.. would be interested in other's thoughts.
Does the default digi code actually reject a solved block with timestamp earlier than the previously accepted? or is this just something you are suggesting?
Thanks --Mark
assuming nTargetSpacing == 150, you recommend rejecting a solved block that comes in less than 50 seconds after the last one?.. maybe this is a little too aggressive?.. or not?.. I'm on the fence.. would be interested in other's thoughts.
Does the default digi code actually reject a solved block with timestamp earlier than the previously accepted? or is this just something you are suggesting?
Thanks --Mark
There is no code in place in the algo to reject blocks under a certain time. This is something he is proposing as a new feature. I like the idea, but this would require testing. Not to prove it's validity, but rather it's vulnerabilities. Timestamps can be altered, like I mentioned, and are the basis for TW attacks. Delaying a set of blocks past the accepted time limit could be easily achieved by someone with enough know-how and patience. I would suppose that 24Kilo could do it with his knowledge of TW attacks, but we would have to test this.
While it's a valid proposal, IMO it's not likely something that will be immediately needed with the DIGI implementation. I would like to look into the possibility of implementing something like this in the future, although not as aggressive as suggested by c_e_d. Maybe a community led testnet?
-Fuse
Agreed. Towards the end of January I'd be more than willing to run a node on the testnet and do some blockchain analysis. I even have a few scrypt miners that I've retired that I can dust off.
Sorry I haven't looked at the code.. busy busy busy..
assuming nTargetSpacing == 150, you recommend rejecting a solved block that comes in less than 50 seconds after the last one?.. maybe this is a little too aggressive?.. or not?.. I'm on the fence.. would be interested in other's thoughts.
Does the default digi code actually reject a solved block with timestamp earlier than the previously accepted? or is this just something you are suggesting?
Thanks --Mark
assuming nTargetSpacing == 150, you recommend rejecting a solved block that comes in less than 50 seconds after the last one?.. maybe this is a little too aggressive?.. or not?.. I'm on the fence.. would be interested in other's thoughts.
Does the default digi code actually reject a solved block with timestamp earlier than the previously accepted? or is this just something you are suggesting?
Thanks --Mark
There is no code in place in the algo to reject blocks under a certain time. This is something he is proposing as a new feature. I like the idea, but this would require testing. Not to prove it's validity, but rather it's vulnerabilities. Timestamps can be altered, like I mentioned, and are the basis for TW attacks. Delaying a set of blocks past the accepted time limit could be easily achieved by someone with enough know-how and patience. I would suppose that 24Kilo could do it with his knowledge of TW attacks, but we would have to test this.
While it's a valid proposal, IMO it's not likely something that will be immediately needed with the DIGI implementation. I would like to look into the possibility of implementing something like this in the future, although not as aggressive as suggested by c_e_d. Maybe a community led testnet?
-Fuse
I don't see a problem today to reject those blocks instead of accepting them into the chain. A submitting miner should be able to keep his clock within a few seconds of synced time nowadays, which should always lead to a positive nActualTimespan. If a miner mines a block faster than his clock is off, than bad luck for him (his own fault).
Or they are doing a time-warp attack by adjusting the times on purpose. 24Kilo has successfully done this with lesser coins, as "taught" in a way by the master of the TW attack via PM bragging.
-Fuse
I even would reject every block that took less time than nTargetSpacing/3, which still allows 'lucky blocks' but denies blocks of only a few seconds (*hint*) and even helps DIGI to catch up faster to the needed diff for high spikes in hashrate. MPs like clever would need to adjust their hashrate down alot to not fall into the trap of their very fast blocks getting rejected. And the spikes in diff would not be that high, only leaving us stuck for far less time.
Sorry I haven't looked at the code.. busy busy busy..
assuming nTargetSpacing == 150, you recommend rejecting a solved block that comes in less than 50 seconds after the last one?.. maybe this is a little too aggressive?.. or not?.. I'm on the fence.. would be interested in other's thoughts.
Does the default digi code actually reject a solved block with timestamp earlier than the previously accepted? or is this just something you are suggesting?
Thanks --Mark
I don't see a problem today to reject those blocks instead of accepting them into the chain. A submitting miner should be able to keep his clock within a few seconds of synced time nowadays, which should always lead to a positive nActualTimespan. If a miner mines a block faster than his clock is off, than bad luck for him (his own fault).
Or they are doing a time-warp attack by adjusting the times on purpose. 24Kilo has successfully done this with lesser coins, as "taught" in a way by the master of the TW attack via PM bragging.
-Fuse
I even would reject every block that took less time than nTargetSpacing/3, which still allows 'lucky blocks' but denies blocks of only a few seconds (*hint*) and even helps DIGI to catch up faster to the needed diff for high spikes in hashrate. MPs like clever would need to adjust their hashrate down alot to not fall into the trap of their very fast blocks getting rejected. And the spikes in diff would not be that high, only leaving us stuck for far less time.
Just a friendly reminder...
Digishield is not going to be a magic bullet against Clevermining. In fact, expect network difficulty to hit new record highs and be 'stuck' for long periods of time.
If Clevermining hits the NLG network with 10x or 20x hash-rate of the base nethash, the difficulty will hit 10x or 20x in a blink. Digishield deals very aggressively with hash-rate spikes, and when Clevermining exits, taking the hash-rate with them, the network is going to be 'stuck' at a very high difficulty.
This Digishield doing its job, reacting quick enough to make it unprofitable to attack the network with high hash-rate.
No one knows how Clevermining or its profitability algo will react to this change. Terk may continue to test the network looking for a way to get coins at a discount. Depends on the tenacity of the Clevermining team as to how many cycles the network has to go through till Clevermining discovers how to best handle the changed diff algo. Do not expect Clevermining to go quietly, NLG has been their cash cow for many months.
I am expecting new record highs of difficulty and some long, grinding sessions before the network achieves equilibrium. What I don't expect to see is false difficulty lows and Clevermining minting the majority of the blocks in a 24hr period by attacking. If Terk decides to park 20x hash-rate on the NLG network for a few days or weeks, Clevermining will own the NLG network by brute force, but not at a discount as they have been.
The NLG dev team and community need to have realistic expectations of the upcoming difficulty algo change and the above is what I expect to happen.
The strong characters, opinions and egos of the team and community have been highlighted in the process, which has reconfirmed that NLG has the best team and community in the industry.
GuldenCoin... the currency of the future.
Community Alert!!!
Digishield is not going to be a magic bullet against Clevermining. In fact, expect network difficulty to hit new record highs and be 'stuck' for long periods of time.
If Clevermining hits the NLG network with 10x or 20x hash-rate of the base nethash, the difficulty will hit 10x or 20x in a blink. Digishield deals very aggressively with hash-rate spikes, and when Clevermining exits, taking the hash-rate with them, the network is going to be 'stuck' at a very high difficulty.
This Digishield doing its job, reacting quick enough to make it unprofitable to attack the network with high hash-rate.
No one knows how Clevermining or its profitability algo will react to this change. Terk may continue to test the network looking for a way to get coins at a discount. Depends on the tenacity of the Clevermining team as to how many cycles the network has to go through till Clevermining discovers how to best handle the changed diff algo. Do not expect Clevermining to go quietly, NLG has been their cash cow for many months.
I am expecting new record highs of difficulty and some long, grinding sessions before the network achieves equilibrium. What I don't expect to see is false difficulty lows and Clevermining minting the majority of the blocks in a 24hr period by attacking. If Terk decides to park 20x hash-rate on the NLG network for a few days or weeks, Clevermining will own the NLG network by brute force, but not at a discount as they have been.
The NLG dev team and community need to have realistic expectations of the upcoming difficulty algo change and the above is what I expect to happen.
The strong characters, opinions and egos of the team and community have been highlighted in the process, which has reconfirmed that NLG has the best team and community in the industry.
GuldenCoin... the currency of the future.
Great work guys working together like a team! Looking forward to the implementation.
So just to be clear on the plan.. 1.3.1 released Thursday? But hardfork end of January?
From announcement JPEG "Guldencoin Wallet 1.3.1 available this Thursday / Digishield / Mandatory Update"
It will be aimed towards the end of january so everyone has time to update.
Thanks guys!
So just to be clear on the plan.. 1.3.1 released Thursday? But hardfork end of January?
From announcement JPEG "Guldencoin Wallet 1.3.1 available this Thursday / Digishield / Mandatory Update"
What block will the hardfork start?
It will be aimed towards the end of january so everyone has time to update.
Thanks guys!
Ah cool. Yes it took some time but I believe I have a pretty neat piece of code now 
Link below
Link below
Looks great, mate. Nice and clean. I wouldn't doubt if coins implementing DIGI in the future use this new trimmed down code code.
I think the problem you are mentioning on your lines 59-56 (negative timespan) are solved by the limiter at your lines 74-78. Right?
Even if the previously timed blocks aren't rejected in the difficulty algorithm, wouldn't the blocks be rejected by the confirming nodes anyway when broadcast to the network? Not discrediting the question that c_e_d raised, just wondering how any other algo handles this. After all the DIGI algo is a direct copy of the standard diff algo, with a 1 block retarget instead of 14 days(as noted in the original comments).
I don't see a problem today to reject those blocks instead of accepting them into the chain. A submitting miner should be able to keep his clock within a few seconds of synced time nowadays, which should always lead to a positive nActualTimespan. If a miner mines a block faster than his clock is off, than bad luck for him (his own fault).
Or they are doing a time-warp attack by adjusting the times on purpose. 24Kilo has successfully done this with lesser coins, as "taught" in a way by the master of the TW attack via PM bragging.
-Fuse
I think the problem you are mentioning on your lines 59-56 (negative timespan) are solved by the limiter at your lines 74-78. Right?
Cheers!
Not really.
Since history shows there are blocks where nActualTimespan becomes negative, DIGI will resolve to nActualTimespan = (retargetTimespan - (retargetTimespan/4)) and the diff jumps up max. This happens because of the wrong time of 1 block, not because the hashrate jumped up; hashrate might even go down at that time.
I don't see a problem today to reject those blocks instead of accepting them into the chain. A submitting miner should be able to keep his clock within a few seconds of synced time nowadays, which should always lead to a positive nActualTimespan. If a miner mines a block faster than his clock is off, than bad luck for him (his own fault).
Your cleanup was even far more radical than mine
I only think we chould leave the testnet code in there for now (only my opinion).
Oh, you could even replace retargetTimespan with nTargetSpacing and save another line and variable
Than it's cleaned to the minimum beside the basic comments.
Isn't the difficulty changing between a min of 66.7% (1/0.75) and a max of 133% (1/1.5) or did I read something wrong there?
I've cleaned up the Digishield code.. there was a lot of dead and unused code from the time it was used to adjust every x blocks (we're adjusting every block).
To be honest, now that the code is clean and "simple to understand", I have quite good hopes for this!
To be honest, now that the code is clean and "simple to understand", I have quite good hopes for this!
Cheers!
I know what you're talking about with the old dead code. CED even mentioned it in PM. I just left it as is, as almost every single DIGI code implementation I looked at still had it included. I didn't want to stray from the norm, but I'm glad you were able to clean it up! Kudos, mate.
Can you post the code block here for reference? I'd love to see the cleaned up function.
-Fuse
Ah cool. Yes it took some time but I believe I have a pretty neat piece of code now
Link below
LOL
Just uploaded a cleaned version but with many comments here:
https://github.com/cydg/NLG_difftest/tree/master/DigiShield_NLG
Just uploaded a cleaned version but with many comments here:
https://github.com/cydg/NLG_difftest/tree/master/DigiShield_NLG
Thats awesome!
I haven't pushed the commits on guldencoin to the github repo yet, but here is the DIGI I have right now:
https://gist.github.com/GeertJohan/0694cb20b5fa48f7820b
Here are the comments I made in the commit that cleans up the Digi code, so you can see why I removed certain pieces of code:
https://gist.github.com/GeertJohan/14fa6f23e5c0105972e4
I think the problem you are mentioning on your lines 59-56 (negative timespan) are solved by the limiter at your lines 74-78. Right?
Cheers!
LOL
Just uploaded a cleaned version but with many comments here:
https://github.com/cydg/NLG_difftest/tree/master/DigiShield_NLG
Just uploaded a cleaned version but with many comments here:
https://github.com/cydg/NLG_difftest/tree/master/DigiShield_NLG
I've cleaned up the Digishield code.. there was a lot of dead and unused code from the time it was used to adjust every x blocks (we're adjusting every block).
To be honest, now that the code is clean and "simple to understand", I have quite good hopes for this!
To be honest, now that the code is clean and "simple to understand", I have quite good hopes for this!
well at least you approve and NLG can finally move in a direction again. Thanks for taking action, GJ. I would still keep working on your algo just in case, a "Plan D" if you will. Plan A was original specs, B was DGW3, C is DIGI, D could be your custom algo. Let's not just assume DIGI will fix the problem, although it should.Although this switch may not entirely fix the problem, it should be better than what we have now. We just don't know how the MP's will react until the algo is in effect. Terk's MP may be in question if he continues to mine.
Thanks to everyone who participated in this (GJ, Fuse, community commentors). It really does take a community to ensure a coin's success, and we all grow with the coin along the way. I thank everyone for protecting mine and everyone's investment as best they could.
I've cleaned up the Digishield code.. there was a lot of dead and unused code from the time it was used to adjust every x blocks (we're adjusting every block).
To be honest, now that the code is clean and "simple to understand", I have quite good hopes for this!
To be honest, now that the code is clean and "simple to understand", I have quite good hopes for this!
Cheers!
I know what you're talking about with the old dead code. CED even mentioned it in PM. I just left it as is, as almost every single DIGI code implementation I looked at still had it included. I didn't want to stray from the norm, but I'm glad you were able to clean it up! Kudos, mate.
Can you post the code block here for reference? I'd love to see the cleaned up function.
-Fuse
I've cleaned up the Digishield code.. there was a lot of dead and unused code from the time it was used to adjust every x blocks (we're adjusting every block).
To be honest, now that the code is clean and "simple to understand", I have quite good hopes for this!
To be honest, now that the code is clean and "simple to understand", I have quite good hopes for this!
What block will the hardfork start?
It will be aimed towards the end of january so everyone has time to update.
What block will the hardfork start?
It will be aimed towards the end of january so everyone has time to update.
Faise is everything ok??
I'm in private chat now. All is ok, problems with (mail)server... Jump to: