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 hashrateThe 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 orderThe 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 poolsWouldn'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 minutesThe 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.
