delete

[nbk]

for weeks i red this timewarp shit...everyone is hating at aurora, kgw, kimoto & megacoin....
so has anyone of these professionals red the kimoto gravity well guide?
here you find it!!! http://imgur.com/a/z2AIw

[1715051681]

1715051681

[1715051681]

1715051681

[1715051681]

1715051681

[1715051681]

1715051681

[kewal]

This is a great example of why alt-coins should be implemented on top of a system like Ethereum.  A small group can have a coin, and be protected by the overall use and mining power behind the much larger community.  I'm looking forward to the pre-sale of Ether.

[molecular]

oh this is like the good ole days.

Not secure the network and get PWNED.

the good old times?

[micryon]

After integrating KGW into my own coins code.. I can see how KGW does open up an additional vulnerability of a preexisting timewarp attack/51% attack vector as described succinctly here: https://litecoin.info/Time_warp_attack

Essentially KGW just makes it easier to pull off a 51% attack, since it retargets every block using timestamps.

But it's not that easy to begin with to pull that off, and will require some special coding of a secret chain-client to do the private chain mining to be in perfect unison and publish blocks at the right time.  Not like anyone with 51% hash power just throwing at a pool will be able to pull it off... And for anyone to really bother, it has to really be worth their while... (or they are just really interested in an academic experiment)

So it's not as easy to execute the attack as people here think... and the "damage" is far less than what people think as well.  So it's not "game-over" even if it does happen, it can be repaired.

I took Hirocoin's change recently into my own coin to make it a bit harder to execute.. doesn't make it impossible.. but it's just more barriers: https://github.com/micryon/planetdollar/commit/0c3e5f2acefc77d34ac60e272ab662b6a3120366

[nbk]

Essentially KGW just makes it easier to pull off a 51% attack, since it retargets every block using timestamps.

and what about KGWs longtime adjustment?

do you set different parameter to your KGW?

[micryon]

Essentially KGW just makes it easier to pull off a 51% attack, since it retargets every block using timestamps.

and what about KGWs longtime adjustment?

do you set different parameter to your KGW?

I'm not sure exactly what you mean by longtime adjustment, do you mean the adjustment ratio?

Code:

  PastRateAdjustmentRatio                        = double(PastRateTargetSeconds) / double(PastRateActualSeconds);

What I'm referring to the vulnerability is really just this:

Code:

  PastRateActualSeconds                        = BlockLastSolved->GetBlockTime() - BlockReading->GetBlockTime();

Which basically reads system clocks... and feeds into the ratio adjustment that is used to calc the next diff..


Hirocoin's code will basically just prevent acceptance of a publishing of a bad time-warped private chain, by checking against timestamps before accepting blocks, limiting the warping factor.

Code:

if (GetBlockTime() > GetAdjustedTime() + 15 * 60) {
           return error("AcceptBlock() : block's timestamp too far in the future");
        }

[nbk]

part of the guide....

For large adjustment factors this happens earlier than for the ones closer to one. This is to have a quick adaptation if the hashrate changes a lot, and a slower one if not - then we want a longer period to get a better average. The parameters of the Kimoto formula are adjusted in such a way that one roughly adjusts in one day to a 10% change and in seven days to a 1.2% change. A minimum of 144 blocks determine the new difficulty and at most 4032 (0.25 days or 7 days for a 2.5 minute blocktime).

What happens when the minimum of 144 blocks isn't reached or the maximum of 4032 blocks is exceeded?

The minimum is 144 blocks. So if the adjustment factor is larger than 1+0.7084, then the factor for 144 blocks is taken. At 4032 the algo stops and the average for 4032 is taken no matter what. KGW gives an answer for both boundary cases.

[micryon]

part of the guide....

For large adjustment factors this happens earlier than for the ones closer to one. This is to have a quick adaptation if the hashrate changes a lot, and a slower one if not - then we want a longer period to get a better average. The parameters of the Kimoto formula are adjusted in such a way that one roughly adjusts in one day to a 10% change and in seven days to a 1.2% change. A minimum of 144 blocks determine the new difficulty and at most 4032 (0.25 days or 7 days for a 2.5 minute blocktime).

What happens when the minimum of 144 blocks isn't reached or the maximum of 4032 blocks is exceeded?

The minimum is 144 blocks. So if the adjustment factor is larger than 1+0.7084, then the factor for 144 blocks is taken. At 4032 the algo stops and the average for 4032 is taken no matter what. KGW gives an answer for both boundary cases.

The adjustment ratio may do a little to curb it.. but fundamentally the problem is in this segment:

Code:

PastRateActualSeconds                        = BlockLastSolved->GetBlockTime() - BlockReading->GetBlockTime();

Code:

if (PastRateActualSeconds != 0 && PastRateTargetSeconds != 0) {
                bnNew *= PastRateActualSeconds;
                bnNew /= PastRateTargetSeconds;

bnNew being the current difficulty.

Because of this you can continually trick the algo to lower the difficulty down to:

Code:

bnProofOfWorkLimit(~uint256(0) >> 20);

You have to imagine just mining outside of real network, in your own intranet.. with just two computers.  and then flipping the system time to the future, making algo believe that more time has passed than actually has between blocks.

[digitalindustry]

This is a great example of why alt-coins should be implemented on top of a system like Ethereum.  A small group can have a coin, and be protected by the overall use and mining power behind the much larger community.  I'm looking forward to the pre-sale of Ether.

Ha ha ha good one.

At least someone has a sense of humor in this circle jerk.

[digitalindustry]

Looks like AUR is an unmitigated success. 

It only gets harder from here on in for the monopoly capitalists.  Think about it there is next to zero infustructure on ground right now, yet price is still sky high compared to take up.

[Starlightbreaker]

so when can we expect fireworks from you?

go fuck something up, need some entertainment here.  

You sound like you missed the best money making opportunity of the year so far.

sorry, i rode AUR's pump and dump.

in at 0.03, out at 0.11, unlike idiots that end up as bagholders.

 

Tempted to post a screenshot of my wallet solomining AUR at start but don't want anymore idiots crying realizing 3x profit wasn't actually the "opportunity of the year".

 

hmm, i think i missed a zero somewhere...i'm pretty sure it was around 28-30x gain during that period.

Well don't be shy, let's just say 300x?

Hah, i wish it was 300x.

[Nite69]

Actually mikey you might want to ask Nite69, the developer brought on by the Auroracoin team to help prepare the KGW TW fix. Nite69 realizes there is a KGW TW underway and by extension so does the Auroracoin Team even though won't and can't admit it.

About the vulnerability BCX found; I'm quite sure this will fix it, like any time warp vulnerability. Shame us, we should have fixed this already earlier

Code:

+	int64 LatestBlockTime = BlockLastSolved->GetBlockTime();
 	for (unsigned int i = 1; BlockReading && BlockReading->nHeight > 0; i++) {
 		if (PastBlocksMax > 0 && i > PastBlocksMax) { break; }
 		PastBlocksMass++;
@@ -894,8 +895,10 @@ unsigned int static GravityWell(const CBlockIndex* pindexLast, const CBlock *pbl
 		if (i == 1)	{ PastDifficultyAverage.SetCompact(BlockReading->nBits); }
 		else		{ PastDifficultyAverage = ((CBigNum().SetCompact(BlockReading->nBits) - PastDifficultyAverage
Prev) / i) + PastDifficultyAveragePrev; }
 		PastDifficultyAveragePrev = PastDifficultyAverage;
-		
-		PastRateActualSeconds			= BlockLastSolved->GetBlockTime() - BlockReading->GetBlockTime();
+		if (LatestBlockTime < BlockReading->GetBlockTime()) {
+			LatestBlockTime = BlockReading->GetBlockTime();
+		}
+		PastRateActualSeconds			= LatestBlockTime - BlockReading->GetBlockTime();
 		PastRateTargetSeconds			= TargetBlocksSpacingSeconds * PastBlocksMass;
 		PastRateAdjustmentRatio			= double(1);
 		if (PastRateActualSeconds < 0) { PastRateActualSeconds = 0; }

Thank you for finding this and bringing this to general knowledge, however, I would prefer some other way to show it..

[micryon]

Actually mikey you might want to ask Nite69, the developer brought on by the Auroracoin team to help prepare the KGW TW fix. Nite69 realizes there is a KGW TW underway and by extension so does the Auroracoin Team even though won't and can't admit it.

About the vulnerability BCX found; I'm quite sure this will fix it, like any time warp vulnerability. Shame us, we should have fixed this already earlier

Code:

+	int64 LatestBlockTime = BlockLastSolved->GetBlockTime();
 	for (unsigned int i = 1; BlockReading && BlockReading->nHeight > 0; i++) {
 		if (PastBlocksMax > 0 && i > PastBlocksMax) { break; }
 		PastBlocksMass++;
@@ -894,8 +895,10 @@ unsigned int static GravityWell(const CBlockIndex* pindexLast, const CBlock *pbl
 		if (i == 1)	{ PastDifficultyAverage.SetCompact(BlockReading->nBits); }
 		else		{ PastDifficultyAverage = ((CBigNum().SetCompact(BlockReading->nBits) - PastDifficultyAverage
Prev) / i) + PastDifficultyAveragePrev; }
 		PastDifficultyAveragePrev = PastDifficultyAverage;
-		
-		PastRateActualSeconds			= BlockLastSolved->GetBlockTime() - BlockReading->GetBlockTime();
+		if (LatestBlockTime < BlockReading->GetBlockTime()) {
+			LatestBlockTime = BlockReading->GetBlockTime();
+		}
+		PastRateActualSeconds			= LatestBlockTime - BlockReading->GetBlockTime();
 		PastRateTargetSeconds			= TargetBlocksSpacingSeconds * PastBlocksMass;
 		PastRateAdjustmentRatio			= double(1);
 		if (PastRateActualSeconds < 0) { PastRateActualSeconds = 0; }

Thank you for finding this and bringing this to general knowledge, however, I would prefer some other way to show it..

wow... well that's quite simple

btw looks like balduro has also been adding static checkpoints, as an additional countermeasure... https://github.com/baldurodinsson/auroracoin-project/commits/master

[markm]

I just woke up, or maybe still mostly asleep, so maybe my orders of magnitude are off or something but... one gigahash? Isn't that kind of puny to even be considered an attack at all? How the heck is any chain so pathetic that one gigahash is even hardly noticed let alone a threat?

-MarkM-

[molecular]

Actually mikey you might want to ask Nite69, the developer brought on by the Auroracoin team to help prepare the KGW TW fix. Nite69 realizes there is a KGW TW underway and by extension so does the Auroracoin Team even though won't and can't admit it.

About the vulnerability BCX found; I'm quite sure this will fix it, like any time warp vulnerability. Shame us, we should have fixed this already earlier

Code:

+	int64 LatestBlockTime = BlockLastSolved->GetBlockTime();
 	for (unsigned int i = 1; BlockReading && BlockReading->nHeight > 0; i++) {
 		if (PastBlocksMax > 0 && i > PastBlocksMax) { break; }
 		PastBlocksMass++;
@@ -894,8 +895,10 @@ unsigned int static GravityWell(const CBlockIndex* pindexLast, const CBlock *pbl
 		if (i == 1)	{ PastDifficultyAverage.SetCompact(BlockReading->nBits); }
 		else		{ PastDifficultyAverage = ((CBigNum().SetCompact(BlockReading->nBits) - PastDifficultyAverage
Prev) / i) + PastDifficultyAveragePrev; }
 		PastDifficultyAveragePrev = PastDifficultyAverage;
-		
-		PastRateActualSeconds			= BlockLastSolved->GetBlockTime() - BlockReading->GetBlockTime();
+		if (LatestBlockTime < BlockReading->GetBlockTime()) {
+			LatestBlockTime = BlockReading->GetBlockTime();
+		}
+		PastRateActualSeconds			= LatestBlockTime - BlockReading->GetBlockTime();
 		PastRateTargetSeconds			= TargetBlocksSpacingSeconds * PastBlocksMass;
 		PastRateAdjustmentRatio			= double(1);
 		if (PastRateActualSeconds < 0) { PastRateActualSeconds = 0; }

Thank you for finding this and bringing this to general knowledge, however, I would prefer some other way to show it..

Thank you!

What would be potential drawbacks / sideeffects of this fix?

There's something I don't quite get... If the attacks works roughly like you explained (quoted here: https://bitcointalk.org/index.php?topic=504103.msg5582049#msg5582049), then why would we see any effects (as BCX says: "increasingly uneven block times"). After all, BCX only publishes his secret chain at the end of the attack, not at this point, right?

[illodin]

I just woke up

lol... your only weakness truly is hungry and sleepy. 

[kalus]

I just woke up, or maybe still mostly asleep, so maybe my orders of magnitude are off or something but... one gigahash? Isn't that kind of puny to even be considered an attack at all? How the heck is any chain so pathetic that one gigahash is even hardly noticed let alone a threat?

-MarkM-

wouldn't an attacker working on an attack chain be benefiting from low difficulty while mining future blocks?  i would have thought TW meant KGW coins could be forked with far less than 51%.

[Nite69]

Thank you!

What would be potential drawbacks / sideeffects of this fix?

There's something I don't quite get... If the attacks works roughly like you explained (quoted here: https://bitcointalk.org/index.php?topic=504103.msg5582049#msg5582049), then why would we see any effects (as BCX says: "increasingly uneven block times"). After all, BCX only publishes his secret chain at the end of the attack, not at this point, right?

I would appreciate others to comment on this: does it fix the problem? Does it have any unwanted side-effects? I have not found, but that does not mean there are no.

I'm wondering the same; there should ne no side effects before the secret attack chain is published.

Not sure if I should publish this or not. However, I think if someone is anyway doing it, then publishing this should be just good on the long run. And you cannot know if my fix works or not, if you don't know what it should fix.

This is one way of using the TW vulnerability, which that code prevents (but not the earlier fix):

1. Use isolated mining environment, as you need at this kind of attack
2. First generate blocks with long timestamps to get low diff on your own chain. This takes time, but gets easier after every block.
3. When you have a low difficulty, start generating blocks with time differences (hours:minutes) : +12:00, -11.51, +12.00 -11.51... This is for 5 minute target times

at step 3, you can generate 2 blocks every 9 minutes with a very low difficulty. Eventually, your chain is longer than the official, and you can publish it.

Every time you generate a block with +12:00, you get -10% difficulty. Every time you generate -11:51, you get +10%, ie you stay at the low difficulty. The problem is that KGW difficulty calculation counts from the latest block's time, not the latest blocktime

But note; this is also prevented with automatic checkpoints. And you have to start over after every published checkpoint.

[markm]

I just woke up, or maybe still mostly asleep, so maybe my orders of magnitude are off or something but... one gigahash? Isn't that kind of puny to even be considered an attack at all? How the heck is any chain so pathetic that one gigahash is even hardly noticed let alone a threat?

-MarkM-

wouldn't an attacker working on an attack chain be benefiting from low difficulty while mining future blocks?  i would have thought TW meant KGW coins could be forked with far less than 51%.

That part puzzles me.

On the one hand, Math claimed that to defend takes significantly more hash power than the attacker.

On the other hand, I thought the "length" of a chain is the total work, so that regardless of whether the work was done in a TARDIS or not it still takes more work than any other fork in order to be the main/real fork?

If the defenders do more work than the attacker, how is the attacker winning with less work? Or do they somehow get more work out of less hashes?

-MarkM-

[markm]

Because I am mining at a much lower difficulty than they are.

Trust me 1 GH is plenty.

Less difficulty just lets less work make more blocks, doesn't it? The amount of work is no different? Or is work being calculated as the amount more than current difficulty or somesuch instead of just the amount actually done?

I had not thought (or realised?) that the same amount of work becomes more work when it happens to be applied to a lower difficulty block; I thought work is what you actually do and difficulty is whether that is enough for a block.

Does the fact that lower work hash-results don't get onto the chain at all at higher difficulty make the difference? So that more of the attacker's hashes (and thus their work) get onto the chain than do the defender's hashes (and thus their work)?

(The defender more often than the attacker doing work that isn't enough to get a block into the chain thus never gets counted?)

(Which maybe could also be part of why faster block chains get more security sooner out of the same amount of hashpower?)

-MarkM-