hi there Martens, i seen you back, make me worry when we have not heard
from you for awhile
looks like the coin generation has slowed down significantly, let's see the price reflect this soon..tbc
It will take some time, patience is the key.
lol..imo the underlying integrity of the code dictates results!
===> you wanna see 10 PH? ~ i'd have you all in tears
j/k
+just look at the attackers ability to get blocks w/ diff of ~ 1.0
----------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>
" Time warp attack
The time warp attack[1] is based on a bug in Bitcoin and Litecoin (and their forks) where the difficulty calculation is off by one block. This is an example of a flaw that affects all coins, especially ones with low network hash rates.
An attacker can repeatedly try to generate the last block of each retarget window, and use a fabricated timestamp of two hours into the future in order to make the time difference from the first block in the retarget window high, thus lowering the difficulty by 0.5%. Due to the bug, the bogus timestamp isn't used as the first block in the next retarget window, and therefore the two extra hours aren't being compensated for in the next difficulty calculation. Once the difficulty is low, the attacker can mine many fast coins, or in the case of a small chain, an attacker with 51% hash power could reduce the difficulty to 1 and mine a new fork from the genesis block.
This attack may not be as feasible on Bitcoin any longer because the probability of repeatedly generating the last block once every two weeks at such high difficulties may be negligible.
Although fixing this issue in Bitcoin is possible, it should be done carefully (by adding rules that encourage nodes to upgrade over time) so to avoid a chain fork, i.e. old clients who didn't upgrade might operate with another difficulty and therefore disagree regarding which blocks are valid. .... "
https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772ArtForz
Sr. Member
****
Activity: 406
View Profile Personal Message (Offline)
Ignore
Re: Possible way to make a very profitable 50 plus ish attack for pools?
September 12, 2011, 09:39:28 PM
Reply with quote #6
Erm, no, those blocks are *valid*.
By exploiting the fact that retargeting ignores one block interval every period, it's possible for an attackers' fork chain to "jump backwards in time" and create lots of blocks at low difficulty without running nTime off into the far future.
Bitcoin (and most *coin) rules re. block timestamps:
nTime has to be > median of prev 11 blocks.
nTime has to be < now() + some buffer.
let's say we have a chain with 4-block interval and 10 sec/block.
Official chain, currect diff for hashrate, blocks found at nominal time:
Code:
blk# 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
time 0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150
Now here's the weird part, we retarget after blocks 3, 7, 11, 15, and for block 3 we use 0 as first and 3 as last, for 7 we use 4 as first and 7 as last, ...
so what happens if an attackers chain has blk timestamps like this:
Code:
blk# 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
time 0 1 2 30 4 5 6 70 8 9 10 110 12 13 14 150
?
first period (#3 - #0) is 30s as before
2nd period is (#7 - #4) ... 66s
3rd period is (#11 - #8) ... 104s
Whoops.
Obviously this ignores the "problem" of the attackers chain having way lower sum-of-difficulty
but thats easy to fix:
Code:
blk# 16 17 18 19 20 21 22 23 ...
time 16 17 18 19 20 21 22 23 ...
just keep driving diff up at maximum speed until you have the same total work as the real chain.
result-> the attackers chain does not violate the block timestamp rules, finishes at a *earlier* block timestamp than the real chain, ends up at a higher total work as the real chain, but contains way more blocks.
This was done on the GeistGeld chain yesterday/today, so it's not a theoretical problem
^
^
^
see?
