and the 0.00000000 blocks?
That is only coins moved and not generated. Guessing the 1000 generated is not included.
Topic: NA - page 432. (Read 893613 times)
Switching pool losing interest? Or do they still jump in and out?
and the 0.00000000 blocks?
I've seen the future and it will be!.....
We'll see at 9th of December... Someone been doing some photoshopping?
I hope this is NLG and not the other gulden.
I can not say this wouldn't be freaking awesome and would blow the guldencoin past anything else a side from btc maybe but I due tend to believe it's simple photoshop..
http://www.mcdonalds.nl/over-mcdonalds/pers
C.
This would be too good to be true... I call Hoax.
I've seen the future and it will be!.....
We'll see at 9th of December... Someone been doing some photoshopping?
I hope this is NLG and not the other gulden.
I can not say this wouldn't be freaking awesome and would blow the guldencoin past anything else a side from btc maybe but I due tend to believe it's simple photoshop..
http://www.mcdonalds.nl/over-mcdonalds/pers
C.
I've seen the future and it will be!.....
That would be such a great day!
I've seen the future and it will be!.....
We'll see at 9th of December... Someone been doing some photoshopping?
I hope this is NLG and not the other gulden.
DGW3 still adjusting? We are at 1760 new blocks now, 1760 calculations to adjust. I can't see any reason in the code why it could take that long.
Because of the spike at the start from 0 to 9 GH/s. It was adjusting to that and meanwhile the multipool added swings as well between 5 GH/s and 11 GH/s. Couldn't handle that all from the start? Too much to handle at once. But maybe I am wrong about this.
Fact is that the big gaps in blockfindingtime are not there at the moment. http://www.guldencointrader.nl/
When the big gaps come back, then we know for sure that this DGW3 isn't the best solution and needs some adjustment or replaced by something else.
Hey Veertje,
I have to agree it is looking much better, but lets see what happens if NLG price goes back over 1000 sat again.
The below are up to date now:
https://timeline.guldencoin.com
https://guldencoin.com/pay-here
DGW3 still adjusting? We are at 1760 new blocks now, 1760 calculations to adjust. I can't see any reason in the code why it could take that long.
Because of the spike at the start from 0 to 9 GH/s. It was adjusting to that and meanwhile the multipool added swings as well between 5 GH/s and 11 GH/s. Couldn't handle that all from the start? Too much to handle at once. But maybe I am wrong about this.
Fact is that the big gaps in blockfindingtime are not there at the moment. http://www.guldencointrader.nl/
When the big gaps come back, then we know for sure that this DGW3 isn't the best solution and needs some adjustment or replaced by something else.
I have to run the numbers, but retargeting difficulty with a time component will create vulnerability to a TW(Time Warp) attack. Just doing a quick simulation here tells me that a TW attack would be successful with less than 10% of the total nethash.
I could very easily create a side chain by manipulating timestamps on the blocks to appear to have 150sec block times with minimal hash-rate that could be merged into the main chain at any point even if you implemented a centralised network time server because the blocks are no longer comfirmed by proof of work, but by time stamp.
As I see it, you would need very little nethash for a successful TW attack.
I could very easily create a side chain by manipulating timestamps on the blocks to appear to have 150sec block times with minimal hash-rate that could be merged into the main chain at any point even if you implemented a centralised network time server because the blocks are no longer comfirmed by proof of work, but by time stamp.
As I see it, you would need very little nethash for a successful TW attack.
Thanks for stepping in. But I get the impression you are talking about the example I gave with 149.99 seconds reject? If thats the case, yep, doesn't work. But leaving everything as is, exept for the fact you reject the first N seconds - in my example 75 seconds - does not change the POW. The diff will lower the same percentage you reject blocks because it has to compensate those missing fast blocks and get the system to an average of 150 sec blocktime. I looked at it from different angles and can't find an exploit other then the ones that also are present in the current system. One thing is different though, the blockmass is less because the diff is less so that can open up an exploit. But I don't know exactly how the timewarp is fixed in DGW2 & 3 - read was too lazy to dig into the code - so that has to be checked.
I have to run the numbers, but retargeting difficulty with a time component will create vulnerability to a TW(Time Warp) attack. Just doing a quick simulation here tells me that a TW attack would be successful with less than 10% of the total nethash.
I could very easily create a side chain by manipulating timestamps on the blocks to appear to have 150sec block times with minimal hash-rate that could be merged into the main chain at any point even if you implemented a centralised network time server because the blocks are no longer comfirmed by proof of work, but by time stamp.
As I see it, you would need very little nethash for a successful TW attack.
I could very easily create a side chain by manipulating timestamps on the blocks to appear to have 150sec block times with minimal hash-rate that could be merged into the main chain at any point even if you implemented a centralised network time server because the blocks are no longer comfirmed by proof of work, but by time stamp.
As I see it, you would need very little nethash for a successful TW attack.
Example:
nTargetSpacing = 2.5 min
minBlockTime = 1 min
A solved block comes in that took less than minBlockTime (using time diff between blocks like it is used for diff recalculation anyway).
Block gets rejected, diff recalculates to i.e. 1.5 times what it was before (so that the expected time for this block gets above the minBlockTime) and the network notified about the new diff.
This catch would only kick in if the times to solve a block are getting below the set minimum.
If the times are in the allowed range, the normal diff adjusting will do its work and level it out again.
How would a time warp attack work here? What am I missing?
Wouldn't the normal diff calculation (DGW3 here) be vulnerable to it too if you can use the number of blocks of an interval in a row for it?
Coins like UTIL or SLG are using an algo with far less blocks per interval and giving the actual block time double weight to calculate the diff modification factor. Wouldn't they be vulnerable even more?
I have to run the numbers, but retargeting difficulty with a time component will create vulnerability to a TW(Time Warp) attack. Just doing a quick simulation here tells me that a TW attack would be successful with less than 10% of the total nethash.
I could very easily create a side chain by manipulating timestamps on the blocks to appear to have 150sec block times with minimal hash-rate that could be merged into the main chain at any point even if you implemented a centralised network time server because the blocks are no longer comfirmed by proof of work, but by time stamp.
As I see it, you would need very little nethash for a successful TW attack.
I could very easily create a side chain by manipulating timestamps on the blocks to appear to have 150sec block times with minimal hash-rate that could be merged into the main chain at any point even if you implemented a centralised network time server because the blocks are no longer comfirmed by proof of work, but by time stamp.
As I see it, you would need very little nethash for a successful TW attack.
You are amongst many people who say "rejecting blocks seems a bad idea" At first I got a little tired but thats not in the interest of the coin so I will explain why its not so strange...
I will refer to pooled mining. When you join a pool and start hashing on the current block, you get a diff from the pool that's less as the network diff. So you start hashing and find a matching block. You submit it to the pool and because it's hashed at a lower diff, good chance it does not comply with the network diff. And then comes the fun... your block gets rejected by the pool!
So your machine starts again and again and again, until you or another pooled miner finds a block that matches the network diff. At that moment the block is send onto the network and is accepted by the network.
So when you enter a pool you are hashing for John Doe most of the time and you get reject on reject. Your work however is recorded because the pool has to calculate how much effort you put in finding the block. The latter is the reason pools work this way otherwise they don't know how much effort you put in hashing.
I said it sounds bad I will refer to pooled mining. When you join a pool and start hashing on the current block, you get a diff from the pool that's less as the network diff. So you start hashing and find a matching block. You submit it to the pool and because it's hashed at a lower diff, good chance it does not comply with the network diff. And then comes the fun... your block gets rejected by the pool!
So your machine starts again and again and again, until you or another pooled miner finds a block that matches the network diff. At that moment the block is send onto the network and is accepted by the network.
So when you enter a pool you are hashing for John Doe most of the time and you get reject on reject. Your work however is recorded because the pool has to calculate how much effort you put in finding the block. The latter is the reason pools work this way otherwise they don't know how much effort you put in hashing.
Your reference to pooled mining did help a lot so I am now able to hopefully describe better what I ment with my vague words of "resending blocks with a corrected diff sounds far better".
Acting like a pool saying 'try it again with this higher diff' if block times are too short.
A bit more complicated on the other side, when block times are getting to long. 'Try it gain with this lower diff" doesn't work here. But with an intelligent algo we should be able to keep the upper block times limited too.
DGW3 still adjusting? We are at 1760 new blocks now, 1760 calculations to adjust. I can't see any reason in the code why it could take that long.
On the bride site: Looks like the heavy dump of ~900k coins this morning cleared the way to a nice price improvement during the last hours. Monday still coming, so there is something to look forward to during the coming week.
It looks like DGW3 handles it better atm with not that very deep lows in diff anymore. Blocktime also relative better atm.
Maybe DGW3 still needs time to settle from a cold start a few days ago and 2.5 minute blocktime? It was designed for 1 minuteblocktime I believe and needed time maybe to adjust with multiple GH/s swings at the cold start. Still adjusting is my opinion.
http://www.guldencointrader.nl/
Maybe DGW3 still needs time to settle from a cold start a few days ago and 2.5 minute blocktime? It was designed for 1 minuteblocktime I believe and needed time maybe to adjust with multiple GH/s swings at the cold start. Still adjusting is my opinion.
http://www.guldencointrader.nl/
Does it do corrections over longer time frames?
I think it couldn't handle the spike in hashrate (from 0 to 9 GH/s) at the start and swings short thereafter. But maybe I am totally wrong on this, but it seems like the lows in diff. swings are getting higher and the spike less high, but it is still far from stable ofcourse atm. But maybe it can adjust more and more in time?
Jump to: