Bitcoin Forum
July 19, 2018, 06:14:25 PM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 [24] 25 »  All
  Print  
Author Topic: delete  (Read 112877 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
nbk
Member
**
Offline Offline

Activity: 130
Merit: 10

MEGACOIN


View Profile WWW
March 31, 2014, 07:34:55 PM
 #461

Huh 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

MΣC:  MDnML1znxhbfrSX5nU2GqP5FjbB4Gwpqsj
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
kewal
Newbie
*
Offline Offline

Activity: 5
Merit: 0


View Profile
March 31, 2014, 08:15:05 PM
 #462

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
Donator
Legendary
*
Offline Offline

Activity: 2520
Merit: 1006



View Profile
March 31, 2014, 08:16:19 PM
 #463

oh this is like the good ole days.

Not secure the network and get PWNED.

the good old times?

Smiley Smiley Smiley

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
micryon
Full Member
***
Offline Offline

Activity: 154
Merit: 100


View Profile WWW
March 31, 2014, 08:28:21 PM
 #464

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

VTC: Vi5NxyF6FPCCEQDrsDcA34P8pXe1Yck21y
PDR: PP3EQsV3oX9bBkjpsnESguMHz3tfMqHXhy PlanetDollar
nbk
Member
**
Offline Offline

Activity: 130
Merit: 10

MEGACOIN


View Profile WWW
March 31, 2014, 08:48:56 PM
 #465

Quote
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?

MΣC:  MDnML1znxhbfrSX5nU2GqP5FjbB4Gwpqsj
micryon
Full Member
***
Offline Offline

Activity: 154
Merit: 100


View Profile WWW
March 31, 2014, 09:04:31 PM
 #466

Quote
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");
        }

VTC: Vi5NxyF6FPCCEQDrsDcA34P8pXe1Yck21y
PDR: PP3EQsV3oX9bBkjpsnESguMHz3tfMqHXhy PlanetDollar
nbk
Member
**
Offline Offline

Activity: 130
Merit: 10

MEGACOIN


View Profile WWW
March 31, 2014, 09:14:23 PM
 #467

part of the guide....

Quote
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.

MΣC:  MDnML1znxhbfrSX5nU2GqP5FjbB4Gwpqsj
micryon
Full Member
***
Offline Offline

Activity: 154
Merit: 100


View Profile WWW
April 01, 2014, 12:46:20 AM
 #468

part of the guide....

Quote
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.

VTC: Vi5NxyF6FPCCEQDrsDcA34P8pXe1Yck21y
PDR: PP3EQsV3oX9bBkjpsnESguMHz3tfMqHXhy PlanetDollar
digitalindustry
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000


wubba lubba dub dub


View Profile WWW
April 01, 2014, 02:25:56 AM
 #469

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.

tiny rick !
- https://voat.co/v/Contact/
- Twitter @Kolin_Quark
digitalindustry
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000


wubba lubba dub dub


View Profile WWW
April 01, 2014, 02:28:30 AM
 #470

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.

tiny rick !
- https://voat.co/v/Contact/
- Twitter @Kolin_Quark
Starlightbreaker
Legendary
*
Offline Offline

Activity: 1764
Merit: 1006



View Profile
April 01, 2014, 03:14:00 AM
 #471

so when can we expect fireworks from you?

go fuck something up, need some entertainment here.  Angry

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.

 Grin

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".

 Grin

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
Sr. Member
****
Offline Offline

Activity: 477
Merit: 500


View Profile
April 01, 2014, 03:40:06 AM
 #472

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 Undecided
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..

Sync: ShiSKnx4W6zrp69YEFQyWk5TkpnfKLA8wx
Bitcoin: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
Litecoin: LhbDew4s9wbV8xeNkrdFcLK5u78APSGLrR
AuroraCoin: AXVoGgYtSVkPv96JLL7CiwcyVvPxXHXRK9
micryon
Full Member
***
Offline Offline

Activity: 154
Merit: 100


View Profile WWW
April 01, 2014, 03:56:00 AM
 #473

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 Undecided
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 Smiley

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

VTC: Vi5NxyF6FPCCEQDrsDcA34P8pXe1Yck21y
PDR: PP3EQsV3oX9bBkjpsnESguMHz3tfMqHXhy PlanetDollar
markm
Legendary
*
Offline Offline

Activity: 2072
Merit: 1000



View Profile WWW
April 01, 2014, 04:38:41 AM
 #474

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-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
molecular
Donator
Legendary
*
Offline Offline

Activity: 2520
Merit: 1006



View Profile
April 01, 2014, 05:43:43 AM
 #475

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 Undecided
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?

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
illodin
Hero Member
*****
Offline Offline

Activity: 966
Merit: 1003


View Profile
April 01, 2014, 05:52:13 AM
 #476

I just woke up

lol... your only weakness truly is hungry and sleepy.  Cheesy
kalus
Sr. Member
****
Offline Offline

Activity: 336
Merit: 250

let's make a deal.


View Profile
April 01, 2014, 05:57:46 AM
 #477

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%.

DC2ngEGbd1ZUKyj8aSzrP1W5TXs5WmPuiR wow need noms
Nite69
Sr. Member
****
Offline Offline

Activity: 477
Merit: 500


View Profile
April 01, 2014, 06:01:57 AM
 #478



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.

Sync: ShiSKnx4W6zrp69YEFQyWk5TkpnfKLA8wx
Bitcoin: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
Litecoin: LhbDew4s9wbV8xeNkrdFcLK5u78APSGLrR
AuroraCoin: AXVoGgYtSVkPv96JLL7CiwcyVvPxXHXRK9
markm
Legendary
*
Offline Offline

Activity: 2072
Merit: 1000



View Profile WWW
April 01, 2014, 06:16:25 AM
 #479

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-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
markm
Legendary
*
Offline Offline

Activity: 2072
Merit: 1000



View Profile WWW
April 01, 2014, 06:34:33 AM
 #480

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-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 [24] 25 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!