binnenkort weer eens chatten op http://www.guldencoinlinks.nl/chat
soon chat meeting at http://www.guldencoinlinks.nl/chat
Topic: NA - page 293. (Read 893613 times)
Guldencoin Forum
http://www.guldencoinforum.com
http://www.guldencoinforum.com
Guldencoin links
http://www.guldencoinlinks.nl
http://www.guldencoinlinks.nl
http://www.guldencoinforum.com
http://www.guldencoinforum.com
Guldencoin links
http://www.guldencoinlinks.nl
http://www.guldencoinlinks.nl
@c_e_d,
Some out of order timestamps may cause a few bumps in the difficulty, but nothing to cause any concern.
And this is one of the reasons that I am recommending that we consider halving the block target time from 150sec to 75sec... this will immediately smooth out any difficulty bumps.
For example... if the diff spikes to 10X... that means a 15 minute block time... where as with a 75sec block time, it is only 7.5 minutes... which is a significant difference.
This would greatly improve wallet to wallet transaction times and make NLG much more user-friendly for micro-transactions.
Some out of order timestamps may cause a few bumps in the difficulty, but nothing to cause any concern.
And this is one of the reasons that I am recommending that we consider halving the block target time from 150sec to 75sec... this will immediately smooth out any difficulty bumps.
For example... if the diff spikes to 10X... that means a 15 minute block time... where as with a 75sec block time, it is only 7.5 minutes... which is a significant difference.
This would greatly improve wallet to wallet transaction times and make NLG much more user-friendly for micro-transactions.
Hi all,
I'm back
Looks like the update is converging nicely over the network.
It also looks like the estimated time is changing slowly because (on average) blocks are mined less often than normal.
See: https://digi.guldencoin.com/
This is nothing to worry about though, just a heads up.
I'm back
Looks like the update is converging nicely over the network.
It also looks like the estimated time is changing slowly because (on average) blocks are mined less often than normal.
See: https://digi.guldencoin.com/
This is nothing to worry about though, just a heads up.
Thanks for the update!
Good feedback as always Geert Johan.
Hi all,
I'm back
Looks like the update is converging nicely over the network.
It also looks like the estimated time is changing slowly because (on average) blocks are mined less often than normal.
See: https://digi.guldencoin.com/
This is nothing to worry about though, just a heads up.
I'm back
Looks like the update is converging nicely over the network.
It also looks like the estimated time is changing slowly because (on average) blocks are mined less often than normal.
See: https://digi.guldencoin.com/
This is nothing to worry about though, just a heads up.
Thanks for the update!
Hi all,
I'm back
Looks like the update is converging nicely over the network.
It also looks like the estimated time is changing slowly because (on average) blocks are mined less often than normal.
See: https://digi.guldencoin.com/
This is nothing to worry about though, just a heads up.
I'm back
Looks like the update is converging nicely over the network.
It also looks like the estimated time is changing slowly because (on average) blocks are mined less often than normal.
See: https://digi.guldencoin.com/
This is nothing to worry about though, just a heads up.
Can we stop fretting about timestamps?!?!?!
The blockchain does not give a stuff about the timestamps of a block... zip, zilch, zero, nada, nothing... because the blocks have to be in mathematical order and thus are in chronological order regardless of the timestamps.
You could completely remove the timestamps from the blocks and it would make no difference to the order of the blocks or blockchain. Timestamps are only part of the block header for human convenience and calculating difficulty. So stop concerning yourselves with timestamps... the following blocks are in correct order as mathematically hashed(or whatever the technical term is) regardless of the timestamp.
The blockchain does not give a stuff about the timestamps of a block... zip, zilch, zero, nada, nothing... because the blocks have to be in mathematical order and thus are in chronological order regardless of the timestamps.
You could completely remove the timestamps from the blocks and it would make no difference to the order of the blocks or blockchain. Timestamps are only part of the block header for human convenience and calculating difficulty. So stop concerning yourselves with timestamps... the following blocks are in correct order as mathematically hashed(or whatever the technical term is) regardless of the timestamp.
Never said the block numbers became unsorted. Never said the blockchain was damaged.
It was about the part above that I marked bold.
So yes... out-of-order timestamps can cause the diff algo to freak out, but do not determine the order of the blocks, block order is a function of irreversable mathematics and hashing.
I know, the order of the blocks is NOT determined by the timestamps.
See the part marked in bold again? So you got what I was talking about.
Instead of only seeing them once in a while with many blocks/hours in between, we have far more now.
Mid of October we had an average of 1 per 143 blocks.
How does it look now? From 2 ranges I checked:
Block 185115 - 185195: 5!
Block 186074 - 186190: 8!
Often 2 or 3 within a few blocks.
Like Fuse said earlier: Single bad timestamps are giving single spikes in diff, leveling out after a few blocks.
I don't want to see the diff algo 'freak out' because the out-of-order timestamps become too many.
Hope you understand my concern now.
On favoring bitcoin over altcoins:
http://www.coindesk.com/11-top-responses-andreas-antonopoulos-reddit-ama/
Well, Andreas Antonopoulos just told everything we need to know. To all those people who say that Altcoins are "Shit" because they don't offer something new, here is Andreas telling you that that does not always matter. Yes Bitcoin is a fantastic digital currency, but that does not mean that it has to be the only fantastic digital currency.
http://www.coindesk.com/11-top-responses-andreas-antonopoulos-reddit-ama/
Well, Andreas Antonopoulos just told everything we need to know. To all those people who say that Altcoins are "Shit" because they don't offer something new, here is Andreas telling you that that does not always matter. Yes Bitcoin is a fantastic digital currency, but that does not mean that it has to be the only fantastic digital currency.
We knew that already, its like having the internet and just 1 provider of something, ridiculous
On favoring bitcoin over altcoins:
http://www.coindesk.com/11-top-responses-andreas-antonopoulos-reddit-ama/
Well, Andreas Antonopoulos just told everything we need to know. To all those people who say that Altcoins are "Shit" because they don't offer something new, here is Andreas telling you that that does not always matter. Yes Bitcoin is a fantastic digital currency, but that does not mean that it has to be the only fantastic digital currency.
http://www.coindesk.com/11-top-responses-andreas-antonopoulos-reddit-ama/
Well, Andreas Antonopoulos just told everything we need to know. To all those people who say that Altcoins are "Shit" because they don't offer something new, here is Andreas telling you that that does not always matter. Yes Bitcoin is a fantastic digital currency, but that does not mean that it has to be the only fantastic digital currency.
Can we stop fretting about timestamps?!?!?!
The blockchain does not give a stuff about the timestamps of a block... zip, zilch, zero, nada, nothing... because the blocks have to be in mathematical order and thus are in chronological order regardless of the timestamps.
You could completely remove the timestamps from the blocks and it would make no difference to the order of the blocks or blockchain. Timestamps are only part of the block header for human convenience and calculating difficulty. So stop concerning yourselves with timestamps... the following blocks are in correct order as mathematically hashed(or whatever the technical term is) regardless of the timestamp.
So yes... out-of-order timestamps can cause the diff algo to freak out, but do not determine the order of the blocks, block order is a function of irreversable mathematics and hashing.
The blockchain does not give a stuff about the timestamps of a block... zip, zilch, zero, nada, nothing... because the blocks have to be in mathematical order and thus are in chronological order regardless of the timestamps.
You could completely remove the timestamps from the blocks and it would make no difference to the order of the blocks or blockchain. Timestamps are only part of the block header for human convenience and calculating difficulty. So stop concerning yourselves with timestamps... the following blocks are in correct order as mathematically hashed(or whatever the technical term is) regardless of the timestamp.
186138 2015-01-17 19:49:39 criptoe
186139 2015-01-17 20:13:09 criptoe
186140 2015-01-17 20:10:53 * hardcore
186141 2015-01-17 20:20:04 criptoe
186142 2015-01-17 20:20:41 clever
186143 2015-01-17 20:17:03 * hardcore
186144 2015-01-17 20:22:14 * hardcore
186145 2015-01-17 20:26:54 clever
186146 2015-01-17 20:27:01 clever
186139 2015-01-17 20:13:09 criptoe
186140 2015-01-17 20:10:53 * hardcore
186141 2015-01-17 20:20:04 criptoe
186142 2015-01-17 20:20:41 clever
186143 2015-01-17 20:17:03 * hardcore
186144 2015-01-17 20:22:14 * hardcore
186145 2015-01-17 20:26:54 clever
186146 2015-01-17 20:27:01 clever
So yes... out-of-order timestamps can cause the diff algo to freak out, but do not determine the order of the blocks, block order is a function of irreversable mathematics and hashing.
Actually another mystery.....
Its 2 seconds ahead. But the block explorer shows Criptoe & Clever ahead...
Its 2 seconds ahead. But the block explorer shows Criptoe & Clever ahead...
Time on Criptoe is synced via ntpd to time.nist.gov. If the time is off, then the National Institute of Standards and Technology needs to fix their atomic clock
Hardcore, can you check your debug.log file on those blocks HCM submitted that are earlier in time than the blocks following them? I'd like to see what the wallet is outputting to the log about the blocks.
-Fuse
@Fuse
Can you take a look at block 185676, there is an enormous timediff between the next one... Is this ok? Think it's not mined by CM...
Can you take a look at block 185676, there is an enormous timediff between the next one... Is this ok? Think it's not mined by CM...
Last night we had 5 blocks with 'funny' times during like 3 hours I checked.
Wonder what's going on.
And I think I saw what looked like short rows of only a few fast blocks during the last days.
Probably not related.
@Fuse: GNDA5MZW... = http://nlg.hardcoreminers.com (search this thread for it)
Blocks 185117, 185120, 185125, 185161, 185190, 185676, 185924 are all from them and giving negative timediff for the following block.
A little hint to get their pools clock back under control should be enough I think.
The server time was a couple of minutes off, for some reason NTP isnt updating correctly. Correct server time is adjusted now (to dutch time) so if you look at the block overview and compare it to blockchain it should match up.
Thnx! Great service
Another mystery resolved. All guldencoin services has been notified about the Digishield update. So things should transition over smoothly on that front.
Great to hear.
A service like http://guldencointrader.nl/ showing diff/hash graphs etc etc is very usefull after the soft fork. They updated too?
Is there a list of all services? Should be nice to have one and add future services there also...
Last night we had 5 blocks with 'funny' times during like 3 hours I checked.
Wonder what's going on.
And I think I saw what looked like short rows of only a few fast blocks during the last days.
Probably not related.
@Fuse: GNDA5MZW... = nlg.hardcoreminers.com (search this thread for it)
Blocks 185117, 185120, 185125, 185161, 185190, 185676 are all from them and giving negative timediff for the following block.
A little hint to get their pools clock back under control should be enough I think.
Wonder what's going on.
And I think I saw what looked like short rows of only a few fast blocks during the last days.
Probably not related.
@Fuse: GNDA5MZW... = nlg.hardcoreminers.com (search this thread for it)
Blocks 185117, 185120, 185125, 185161, 185190, 185676 are all from them and giving negative timediff for the following block.
A little hint to get their pools clock back under control should be enough I think.
Winner, winner chicken dinner!
Good eyes, mate!
-Fuse
@Fuse
Can you take a look at block 185676, there is an enormous timediff between the next one... Is this ok? Think it's not mined by CM...
Can you take a look at block 185676, there is an enormous timediff between the next one... Is this ok? Think it's not mined by CM...
Last night we had 5 blocks with 'funny' times during like 3 hours I checked.
Wonder what's going on.
And I think I saw what looked like short rows of only a few fast blocks during the last days.
Probably not related.
@Fuse: GNDA5MZW... = nlg.hardcoreminers.com (search this thread for it)
Blocks 185117, 185120, 185125, 185161, 185190, 185676, 185924 are all from them and giving negative timediff for the following block.
A little hint to get their pools clock back under control should be enough I think.
@Fuse
Can you take a look at block 185676, there is an enormous timediff between the next one... Is this ok? Think it's not mined by CM...
Can you take a look at block 185676, there is an enormous timediff between the next one... Is this ok? Think it's not mined by CM...
The 4vrnY8 address isn't Criptoe. Blocks 185675 and 185677 were mined by Criptoe, but they don't give us any insight into block 185676. We need to figure out who 4vrnY8 is and see what their debug.log file shows.
-Fuse
Jump to: