GoldCoin Talk
Main Category => Technical Discussion => Topic started by: Aurophilicity on June 22, 2016, 04:51:02 AM
-
Let me first ask you if I'm getting this right:
GLD uses a 45-second window for the timestamp into the future
whereas BTC has a two-hour tolerance.
The timestamps must be in chronological order - unlike BTC.
The GLD clients synchronise their internal clocks with some tolerance against the local system clocks.
BTC doesn't have such a mechanism.
If my assumptions are right, wouldn't it be possible to programme a client that adds up to 45 seconds to the timestamp
when it has found a new block?
Wouldn't this bar other clients from submitting their blocks especially when this rogue client has a high hashrate?
I'm asking this because I've observed some weird behaviour in the last two weeks or so:
Every now and then, a string of blocks with a size of 249 shows up in the block-explorer
unless there is more than one transaction per block.
The age of the newest of these blocks is frequently '0 minutes 0 seconds.'
During such a period, mining only produces orphans.
Transactions between clients are not affected whatsoever.
Am I on the right track?
-
Look what happens after block 438508 when the atta...susp...activity of interest abruptly stops:
http://gld.cryptocoinexplorer.com/blockrange?start=438500&range=30
-
Let me first ask you if I'm getting this right:
GLD uses a 45-second window for the timestamp into the future
whereas BTC has a two-hour tolerance.
The timestamps must be in chronological order - unlike BTC.
The GLD clients synchronise their internal clocks with some tolerance against the local system clocks.
BTC doesn't have such a mechanism.
If my assumptions are right, wouldn't it be possible to programme a client that adds up to 45 seconds to the timestamp
when it has found a new block?
Wouldn't this bar other clients from submitting their blocks especially when this rogue client has a high hashrate?
I'm asking this because I've observed some weird behaviour in the last two weeks or so:
Every now and then, a string of blocks with a size of 249 shows up in the block-explorer
unless there is more than one transaction per block.
The age of the newest of these blocks is frequently '0 minutes 0 seconds.'
During such a period, mining only produces orphans.
Transactions between clients are not affected whatsoever.
Am I on the right track?
Hi,
GLD uses a 45-second window for the timestamp into the future - This is true
We also use a 2 minute and 45 second window for timestamps into the past. Under the 51% defense algorithm even if you manage to exploit this somehow you wouldn't be able to get 6 blocks in a row needed for double spending.
whereas BTC has a two-hour tolerance. - Also true, they're even more vulnerable, only defense BTC has is their extremely large network hashrate
The timestamps must be in chronological order - unlike BTC. - This is not true, the only reason it may seem like it is because our difficulty algorithm (Golden River) stays near the maximum speed allowed by our 51% defense algorithm. Thus it is merely a co-incidence.. Its very possible to have some time stamps that are not in chronological order
The GLD clients synchronise their internal clocks with some tolerance against the local system clocks. - This is not true, GLD will not synchronize with system time, but rather will record time-zone prior to mining. For this reason it is necessary that if you wish to mine GLD, your system time be within 45 seconds of NETWORK TIME(which is a median of the time of clients on the network).
If my assumptions are right, wouldn't it be possible to programme a client that adds up to 45 seconds to the timestamp
when it has found a new block? - It is possible to do this and we recommend doing so to all pools
Wouldn't this bar other clients from submitting their blocks especially when this rogue client has a high hashrate? No because everyone else can do the same thing(not to mention that by default system time's across the world are usually off by a few dozen seconds anyways), and the 51% defense algorithm bars, one client from submitting more than 5 block every 10 minutes
The details of our 51% defense algorithm are complex and not covered fully in the old lamen white paper.. I suggest you take a look at the following function:
bool ProcessBlock(CNode* pfrom, CBlock* pblock)
in main.cpp, for details.
-
Look what happens after block 438508 when the ata...susp...activity of interest abruptly stops:
http://gld.cryptocoinexplorer.com/blockrange?start=438500&range=30
If you look at the payouts from the address, it looks like a mining pool to me.
-
Thanks, akumaburn. :)
-
Akumaburn is the man!