NA

[WaterLooDown]

Just to echo what has been said already by others. Fantastic effort and Collaboration has been put in by the community and team in order to get us to the next step for the algorithm. There is a reason why I approached Fuse to be apart of this project because of his ethics and seriousness towards crypto, together with the knowledge of /GJ the next move has been made that will give us some time to perfect a custom algorithm for Guldencoin.

I am so excited for 2015 and the growth I expect us to have.

[1713999201]

1713999201

[1713999201]

1713999201

[1713999201]

1713999201

[c_e_d]

IIRC theoretically there's no limit, except physical and logical storage limits. I think 16TB is a typical limit for NTFS, not sure for other storage types.

fat32 4 gig
fat16 2 gig

NTFS max? more than 1tb  , but the max for a program is 2 gig

ntfs 16tb?

FAT volumes have a maximum size of 4GB and a file size limit of 2GB.
FAT32 file systems have a maximum volume size of 32GB with a file size limit of 4GB.
NTFS volumes can be up to 2TB on an MBR disk and 16 Exabytes (EB) on GPT disks.
The maximum size NTFS volume that has been tested by Microsoft is 16 TB.
The maximum size of a VHD is 2040 GB (8 GB short of 2 TB).
The maximum size of a VHDX is 64 TB.

That's the theory. BIOS, controller, drivers or the OS type might force a lower limit for an individual machine

[c_e_d]

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

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

To make it clear: Rejecting blocks is not part of any diff algo code. There are parts like CheckBlock or CheckProofOfWork that do rejects of blocks under certain conditions.

Why do I think that it is needed now?
Let's look at the following (it does not matter that those blocks are from Oct 2014):
 Block          Date            Time
135199   16.10.2014   17:06:53
135200   16.10.2014   17:07:38
135201   16.10.2014   17:07:19
135202   16.10.2014   17:08:19
135203   16.10.2014   17:14:55

The diff algo takes a negative timespan for block 135201 and is using that for further calculations. Doesn't matter if you use DGW3 or DIGI. Only the min/max checks before the final diff calculation are keeping it someway under control. There is no way I can see to know what the real block time should be. Think of it as a normal or long block and lets use DIGI as example. DIGI would see it as a very short block and would increase the diff as much as allowed. While the block should maintain or lower the next diff, it will increase it heavy.

Hope this explains the problem I see.

From what I see, this problem have been in the code from long before NLG exists. It was always covert by long intervals of blocks used to calculate the next diff.
The more blocks you use for the diff calculation, the less influence a single bad timestamp has.
With DGW3 a single bad timestamp had only 4% influence, with the new DIGI it has 100% influence as explained above.

What does that mean?
DIGI does what it is supposed to do, react as fast as possible to changes in hashrate. It's not trying to smooth them like DGW3 does with it's 24 blocks interval.
On the other side it takes the cover off from the timestamp problem and this can not be fixed in the diff algo. It does not belong there. It belongs into places where blocks are checked before inserted into the chain or are getting rejected because of various reasons.
Can it be that hard for a miner of today to keep his clock synced within a few seconds variance? It is easy to do and lazy not to do it.

So the first and most important point would be to reject blocks with bad timestamps.
There is already code in place to reject blocks with a time stamp too far into the future. We can add some lines of code to reject blocks with time stamps too far into the past.
But this alone will not do it. Atleast I can't see it. Still I would add it.

What I would do is to make sure every new block has a time stamp newer than the previous block. And this leads to a minimum time diff between blocks.
How high should this minimum be? 1 second? 10 seconds? 20 seconds? 30 seconds? 50 seconds? For sure that needs to be discussed and agreed on!
We wouldn't be the first coin to check to a certain amount of work time between blocks and reject those that are coming in too fast.
I know I have seen it in the code of atleast 1 or 2 coins but for the heck of it I can't remember which coin code it was.

[Halofire]

What is the allowance for computers and clocks to be non-time-aligned across the world for mining? Isn't it something like 60 seconds? There is a window.

[ny2cafuse]

To make it clear: Rejecting blocks is not part of any diff algo code. There are parts like CheckBlock or CheckProofOfWork that do rejects of blocks under certain conditions.

Why do I think that it is needed now?
Let's look at the following (it does not matter that those blocks are from Oct 2014):
 Block          Date            Time
135199   16.10.2014   17:06:53
135200   16.10.2014   17:07:38
135201   16.10.2014   17:07:19
135202   16.10.2014   17:08:19
135203   16.10.2014   17:14:55

The diff algo takes a negative timespan for block 135201 and is using that for further calculations. Doesn't matter if you use DGW3 or DIGI. Only the min/max checks before the final diff calculation are keeping it someway under control. There is no way I can see to know what the real block time should be. Think of it as a normal or long block and lets use DIGI as example. DIGI would see it as a very short block and would increase the diff as much as allowed. While the block should maintain or lower the next diff, it will increase it heavy.

Hope this explains the problem I see.

From what I see, this problem have been in the code from long before NLG exists. It was always covert by long intervals of blocks used to calculate the next diff.
The more blocks you use for the diff calculation, the less influence a single bad timestamp has.
With DGW3 a single bad timestamp had only 4% influence, with the new DIGI it has 100% influence as explained above.

I wish we could understand the circumstances behind how this block was generated and submitted.  I hate that it was found by our good friend Terk, because if it was on my pool we could try to at least track it in the debug logs or db.

Still though, even if DIGI reacted by hitting the max increase, it would be a single block in the difficulty adjustment.  A blip on the radar of sorts.  The next block or two would be found, and the timestamps would eventually even out the blip.  I agree that it's an anomoly that shouldn't have happened in the first place, but it's effect on the chain would be marginal, and mostly unnoticed.

What does that mean?
DIGI does what it is supposed to do, react as fast as possible to changes in hashrate. It's not trying to smooth them like DGW3 does with it's 24 blocks interval.
On the other side it takes the cover off from the timestamp problem and this can not be fixed in the diff algo. It does not belong there. It belongs into places where blocks are checked before inserted into the chain or are getting rejected because of various reasons.
Can it be that hard for a miner of today to keep his clock synced within a few seconds variance? It is easy to do and lazy not to do it.

I'll reiterate this again, though... You are 100% correct in that time should be accurate on the miner's or pool's side.  Unless it is being manipulated to introduce invalid timestamped blocks.

So the first and most important point would be to reject blocks with bad timestamps.
There is already code in place to reject blocks with a time stamp too far into the future. We can add some lines of code to reject blocks with time stamps too far into the past.
But this alone will not do it. Atleast I can't see it. Still I would add it.

What I would do is to make sure every new block has a time stamp newer than the previous block. And this leads to a minimum time diff between blocks.
How high should this minimum be? 1 second? 10 seconds? 20 seconds? 30 seconds? 50 seconds? For sure that needs to be discussed and agreed on!
We wouldn't be the first coin to check to a certain amount of work time between blocks and reject those that are coming in too fast.
I know I have seen it in the code of atleast 1 or 2 coins but for the heck of it I can't remember which coin code it was.

Banning a block time with a negative difference from the previous block time is the only way I would see this working.  Essentially shutting out any blocks that had a timestamp earlier than the last block height.  However, you then run the risk of the time being advanced on the miner's side purposefully to create future timestamps.  If done correctly, you have a TW attack, and we're in a situation that is far worse than a single blip in the blockchain.

These are just my thoughts on this though.  I've never attempted the TW attack, but I know that it can be done, and has been done by 24Kilo.  It has always intrigued me though how things like this can exist, and how to try to prevent it.

-Fuse

[Halofire]

To make it clear: Rejecting blocks is not part of any diff algo code. There are parts like CheckBlock or CheckProofOfWork that do rejects of blocks under certain conditions.

Why do I think that it is needed now?
Let's look at the following (it does not matter that those blocks are from Oct 2014):
 Block          Date            Time
135199   16.10.2014   17:06:53
135200   16.10.2014   17:07:38
135201   16.10.2014   17:07:19
135202   16.10.2014   17:08:19
135203   16.10.2014   17:14:55

The diff algo takes a negative timespan for block 135201 and is using that for further calculations. Doesn't matter if you use DGW3 or DIGI. Only the min/max checks before the final diff calculation are keeping it someway under control. There is no way I can see to know what the real block time should be. Think of it as a normal or long block and lets use DIGI as example. DIGI would see it as a very short block and would increase the diff as much as allowed. While the block should maintain or lower the next diff, it will increase it heavy.

Hope this explains the problem I see.

From what I see, this problem have been in the code from long before NLG exists. It was always covert by long intervals of blocks used to calculate the next diff.
The more blocks you use for the diff calculation, the less influence a single bad timestamp has.
With DGW3 a single bad timestamp had only 4% influence, with the new DIGI it has 100% influence as explained above.

I wish we could understand the circumstances behind how this block was generated and submitted.  I hate that it was found by our good friend Terk, because if it was on my pool we could try to at least track it in the debug logs or db.

Still though, even if DIGI reacted by hitting the max increase, it would be a single block in the difficulty adjustment.  A blip on the radar of sorts.  The next block or two would be found, and the timestamps would eventually even out the blip.  I agree that it's an anomoly that shouldn't have happened in the first place, but it's effect on the chain would be marginal, and mostly unnoticed.

What does that mean?
DIGI does what it is supposed to do, react as fast as possible to changes in hashrate. It's not trying to smooth them like DGW3 does with it's 24 blocks interval.
On the other side it takes the cover off from the timestamp problem and this can not be fixed in the diff algo. It does not belong there. It belongs into places where blocks are checked before inserted into the chain or are getting rejected because of various reasons.
Can it be that hard for a miner of today to keep his clock synced within a few seconds variance? It is easy to do and lazy not to do it.

I'll reiterate this again, though... You are 100% correct in that time should be accurate on the miner's or pool's side.  Unless it is being manipulated to introduce invalid timestamped blocks.

So the first and most important point would be to reject blocks with bad timestamps.
There is already code in place to reject blocks with a time stamp too far into the future. We can add some lines of code to reject blocks with time stamps too far into the past.
But this alone will not do it. Atleast I can't see it. Still I would add it.

What I would do is to make sure every new block has a time stamp newer than the previous block. And this leads to a minimum time diff between blocks.
How high should this minimum be? 1 second? 10 seconds? 20 seconds? 30 seconds? 50 seconds? For sure that needs to be discussed and agreed on!
We wouldn't be the first coin to check to a certain amount of work time between blocks and reject those that are coming in too fast.
I know I have seen it in the code of atleast 1 or 2 coins but for the heck of it I can't remember which coin code it was.

Banning a block time with a negative difference from the previous block time is the only way I would see this working.  Essentially shutting out any blocks that had a timestamp earlier than the last block height.  However, you then run the risk of the time being advanced on the miner's side purposefully to create future timestamps.  If done correctly, you have a TW attack, and we're in a situation that is far worse than a single blip in the blockchain.

These are just my thoughts on this though.  I've never attempted the TW attack, but I know that it can be done, and has been done by 24Kilo.  It has always intrigued me though how things like this can exist, and how to try to prevent it.

-Fuse

Here's the same thing but in Smartcoin. SMC had a lot of these, I had asked about it way back when. Nothing bad happened, it's normal because of the time window that's built into CGminer. This is data from July, but shows the same thing. It usually means someone's computer time isn't synced with internet time. Could be someone screwing around or just someone didn't sync their clock.
289849    Jul 23, 2014 7:38:56 PM    
289848    Jul 23, 2014 7:38:28 PM    
289847    Jul 23, 2014 7:38:46 PM

Addition: if you adjust your computers clock while the cgminer is running, you can create these, but once you hit a limit (in repetitive advancing time or opposite), then cgminer shuts off the items mining, i.e. gpu or asic.

[Jero]

block 169145 timestamp 2014-12-17 22:39:21 +0100 mined by GYcuT85n197Rfb2Jz3sPmQ65B3gsggo5tv/GMWbS9iT21ozoV4agQ7NMKm9MSnz6LjMQz Diff 599.63113256
block 169146 timestamp 2014-12-17 22:56:43 +0100 mined by GNDA5MZWcm4AjLtNuEmYpgH8qsxo4vrnY8 Diff 649.28121791
block 169147 timestamp 2014-12-17 22:56:03 +0100 mined by Gf7wGAwJGDLfoHcNCRLKZqpk2EQU5ixA6c Diff 485.24787413
block 169148 timestamp 2014-12-17 22:56:11 +0100 mined by Gf7wGAwJGDLfoHcNCRLKZqpk2EQU5ixA6c Diff 486.58487775
block 169149 timestamp 2014-12-17 22:56:14 +0100 mined by Gf7wGAwJGDLfoHcNCRLKZqpk2EQU5ixA6c Diff 488.22745395
block 169150 timestamp 2014-12-17 22:56:41 +0100 mined by Gf7wGAwJGDLfoHcNCRLKZqpk2EQU5ixA6c Diff 490.65481239
block 169151 timestamp 2014-12-17 22:56:53 +0100 mined by Gf7wGAwJGDLfoHcNCRLKZqpk2EQU5ixA6c Diff 509.92249476

Well, I'm a noob in this stuff, but even a noob can see there is a match between timestamps and diffs... Main questions remains I suppose?

[Halofire]

block 169145 timestamp 2014-12-17 22:39:21 +0100 mined by GYcuT85n197Rfb2Jz3sPmQ65B3gsggo5tv/GMWbS9iT21ozoV4agQ7NMKm9MSnz6LjMQz Diff 599.63113256
block 169146 timestamp 2014-12-17 22:56:43 +0100 mined by GNDA5MZWcm4AjLtNuEmYpgH8qsxo4vrnY8 Diff 649.28121791
block 169147 timestamp 2014-12-17 22:56:03 +0100 mined by Gf7wGAwJGDLfoHcNCRLKZqpk2EQU5ixA6c Diff 485.24787413
block 169148 timestamp 2014-12-17 22:56:11 +0100 mined by Gf7wGAwJGDLfoHcNCRLKZqpk2EQU5ixA6c Diff 486.58487775
block 169149 timestamp 2014-12-17 22:56:14 +0100 mined by Gf7wGAwJGDLfoHcNCRLKZqpk2EQU5ixA6c Diff 488.22745395
block 169150 timestamp 2014-12-17 22:56:41 +0100 mined by Gf7wGAwJGDLfoHcNCRLKZqpk2EQU5ixA6c Diff 490.65481239
block 169151 timestamp 2014-12-17 22:56:53 +0100 mined by Gf7wGAwJGDLfoHcNCRLKZqpk2EQU5ixA6c Diff 509.92249476

Well, I'm a noob in this stuff, but even a noob can see there is a match between timestamps and diffs... Main questions remains I suppose?

I'll say again, I think the window is 60 seconds to the next found block. If we notice the times are more than 60 seconds, then we should start to worry.

[Jero]

block 169145 timestamp 2014-12-17 22:39:21 +0100 mined by GYcuT85n197Rfb2Jz3sPmQ65B3gsggo5tv/GMWbS9iT21ozoV4agQ7NMKm9MSnz6LjMQz Diff 599.63113256
block 169146 timestamp 2014-12-17 22:56:43 +0100 mined by GNDA5MZWcm4AjLtNuEmYpgH8qsxo4vrnY8 Diff 649.28121791
block 169147 timestamp 2014-12-17 22:56:03 +0100 mined by Gf7wGAwJGDLfoHcNCRLKZqpk2EQU5ixA6c Diff 485.24787413
block 169148 timestamp 2014-12-17 22:56:11 +0100 mined by Gf7wGAwJGDLfoHcNCRLKZqpk2EQU5ixA6c Diff 486.58487775
block 169149 timestamp 2014-12-17 22:56:14 +0100 mined by Gf7wGAwJGDLfoHcNCRLKZqpk2EQU5ixA6c Diff 488.22745395
block 169150 timestamp 2014-12-17 22:56:41 +0100 mined by Gf7wGAwJGDLfoHcNCRLKZqpk2EQU5ixA6c Diff 490.65481239
block 169151 timestamp 2014-12-17 22:56:53 +0100 mined by Gf7wGAwJGDLfoHcNCRLKZqpk2EQU5ixA6c Diff 509.92249476

Well, I'm a noob in this stuff, but even a noob can see there is a match between timestamps and diffs... Main questions remains I suppose?

I'll say again, I think the window is 60 seconds to the next found block. If we notice the times are more than 60 seconds, then we should start to worry.

Is there someone or a tool who/which can query the blockchain to find out if there are gaps of >= 60 sec? Wonder if it is even possible in the real situation...

[Halofire]

Here, check this out.

https://en.bitcoin.it/wiki/Block_timestamp

It's not a limit of 60 seconds in the block chain, sorry about that. It's 60 seconds in cgminer though. I was confusing two issues.

[c_e_d]

Banning a block time with a negative difference from the previous block time is the only way I would see this working.  Essentially shutting out any blocks that had a timestamp earlier than the last block height.

Right.
We have a default timespan of 150 seconds.
Even if the miners time is off by 1 minute, a block with adjusted difficulty should still have a time diff of +90 seconds.
Take into account a hashrate doubling, you still have +15 seconds for a miner with a clock 1 minute behind.

However, you then run the risk of the time being advanced on the miner's side purposefully to create future timestamps.  If done correctly, you have a TW attack, and we're in a situation that is far worse than a single blip in the blockchain.

-Fuse

See my example above. A normal miner with a half way synced clock has no need to create false timestamps.
A malicious miner with enough hash power can find a way to harm.
Looks at nlgstats of today: Clever has 70% of todays blocks. That's not harming? Their hash power on NLG network not dangerous?

That risk is there anyway and timestamps into the future are limited in the (std) coin code. This limit into the future is far too high for my taste, but for the moment I guess there was a good reason to set it that high.
Like Halofire pointed out: The lower limit for the time stamp (found in coin code) is the time stamp from 6 blocks back + 1. 
Use blocks with a timestamp back in time and send them in in a row. What happens?
See what I mean?

During the last days on /GJ's block explorer I have seen a few times blocks that took less than 10 seconds. Wanna guess who it was?
Kick blocks far below any reasonable time off the chain or atleast give them a heavy penalty (pay them far less for those very short blocks) and we have 1 thing less to worry about.

[ny2cafuse]

See my example above. A normal miner with a half way synced clock has no need to create false timestamps.
A malicious miner with enough hash power can find a way to harm.
Looks at nlgstats of today: Clever has 70% of todays blocks. That's not harming? Their hash power on NLG network not dangerous?

That risk is there anyway and timestamps into the future are limited in the (std) coin code. This limit into the future is far too high for my taste, but for the moment I guess there was a good reason to set it that high.
Like Halofire pointed out: The lower limit for the time stamp (found in coin code) is the time stamp from 6 blocks back + 1. 
Use blocks with a timestamp back in time and send them in in a row. What happens?
See what I mean?

During the last days on /GJ's block explorer I have seen a few times blocks that took less than 10 seconds. Wanna guess who it was?
Kick blocks far below any reasonable time off the chain or atleast give them a heavy penalty (pay them far less for those very short blocks) and we have 1 thing less to worry about.

You're debating for a change that will most likely not be needed when DIGI is implemented.  I feel like you're ignoring that variable in this equation.  In our current state, timestamp rejection could be an option, if substantiated.  In 3 weeks, it isn't going going to matter as much.

Yes, CM is a cancer on our chain.  It's the reason I've rallied for a change in the algo for the last 4 months.  I agree 1000% that it is harming our network, there's no debate there.

The reason CM is able to pull those consecutive blocks in less than 10 seconds is because the algo did not react fast enough.  It needed time to average the block times and make a difficulty change based on that moving average.  A delayed increase in difficulty, and a false low where these delays occur is the reason CM takes our coins and wipes their butt with them.

For reference, here is the visual, as provided by Markanth(kudos for this):



When the difficulty doesn't drop below that baseline border between blue and red that's apparent in this graph, CM is essentially dead on our chain.  This is of course if they are mining based on profitability vs difficulty.  If they are mining based on Terk's emotions, then we're in trouble, and nothing we do will stop him from causing issues with this coin... timestamps or otherwise.

-Fuse

[ontopicplease]

Hoi,

Ik probeer via https://guldencoin.com/nl/download een wallet te downloaden op mijn iPhone. Ik kreeg de message; "safari kan dit niet downloaden"
Iemand een idee?

Bedankt.

[veertje]

New windows wallet 1.3.1 synced here   Which block will be the hardfork?

[LTEX]

Hoi,

Ik probeer via https://guldencoin.com/nl/download een wallet te downloaden op mijn iPhone. Ik kreeg de message; "safari kan dit niet downloaden"
Iemand een idee?

Bedankt.

Werkt niet op een iPhone, alleen OSX...

Binnenkort is er wellicht wel de IOS app beschikbaar, die is inmiddels aangemeld bij Apple...

[/GeertJohan]

New windows wallet 1.3.1 synced here   Which block will be the hardfork?

194300

[BioMike]

New windows wallet 1.3.1 synced here   Which block will be the hardfork?

Two posts above:

Countdown: https://digi.guldencoin.com (https://digi.guldencoin.com)

[bram_vnl]

Hoi,

Ik probeer via https://guldencoin.com/nl/download een wallet te downloaden op mijn iPhone. Ik kreeg de message; "safari kan dit niet downloaden"
Iemand een idee?

Bedankt.

http://guldenwallet.com

[ontopicplease]

Hoi,

Ik probeer via https://guldencoin.com/nl/download een wallet te downloaden op mijn iPhone. Ik kreeg de message; "safari kan dit niet downloaden"
Iemand een idee?

Bedankt.

Werkt niet op een iPhone, alleen OSX...

Binnenkort is er wellicht wel de IOS app beschikbaar, die is inmiddels aangemeld bij Apple...

Thanks

[veertje]

New windows wallet 1.3.1 synced here   Which block will be the hardfork?

Two posts above:

Countdown: https://digi.guldencoin.com (https://digi.guldencoin.com)

Overlooked it  Nice that countdown