Topic: NA - page 303. (Read 893613 times)

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

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.

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

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.


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.

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.

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

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.

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?

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.

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.



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.



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

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.

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.

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

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.

Haha ja inderdaad!! Ik vond het wel grappig dat gratis btc mining door op knopjes te drukken en affliates krijg je sneller wat meer  Ik lees vrijwel nooit de gebruikersvoorwaarden op een forum zolang je maar netjes blijft toch?

Wel luisteren naar de senior members he Sven! 

Oh alverwijderd, mag je zelf ook wel even doen als je wil

fat32 4 gig
fat16 2 gig

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

ntfs 16tb?

+ I wouldn't want to re-sync a 16Tb blockchain on my Macbook. I might run a bit low on my SSD  

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.