Pages:
Author

Topic: Regarding Auroracoin TW exploit (Fix included) - page 7. (Read 27362 times)

sr. member
Activity: 288
Merit: 250
Yes per our agreement I will pull back the exploit and allow a fix.
Respect.


I think a whole new crop of newbies have now been indoctrinated to the legend that is BCX. There is also an interesting correlation with success of coins that have worked with BCX on security. Litecoin and Namecoin are both here today because of BCX intervention in the their infancy. Auroracoin just turned a huge corner towards success IMHO.

The conspiracy theorist in me is saying that this was the plan all along.

In other words, Aur isn't a scam at all. This was just a way of getting the developers to fix a security flaw before "they" decided to be invested. In essence, they killed two birds with one stone (drove the price down and addressed an exploit.)

Well done. 
legendary
Activity: 1025
Merit: 1000
ltex.nl

Yes per our agreement I will pull back the exploit and allow a fix.
I am most definitely a person of my word. The conditions that solve for a solution have been met.

Why does Nite69 say "allow" a fix?

As explained by Nite69 I am gaining on the chain with a current running KGW TW. In order to prevent me from gaining and over taking the current AUR blockchain AUR needs 25X my mining power at a minimum, something the miners have proven they have little interest in doing. As such, it is just a matter of time before the TW catches up and is in full implementation.

In order to deploy the "fix" a new client will need to be released and another hard fork implemented. If the TW exploit isn't pulled back before the hard fork, it will instantly catch up at the next hard fork due to diff swings and be in full full implementation. So either way I win, fix it or don't fix it.

Nite69 is very correct, I have no real desire to destroy AUR as initially I was only going to run a test for a few hundred blocks. The concesion by the AUR development is sufficient for me. Understand this is enabled by KGW and was not a vulnerability till KGW was implemented. All coins that deploy KGW are vulnerable.


~BCX~



In all fairness, despite all clashes we had over this, I have to acknowledge you are being sensible and mature in the end. For that I thank you!
legendary
Activity: 2940
Merit: 1090

Yes per our agreement I will pull back the exploit and allow a fix.

As explained by Nite69 I am gaining on the chain with a current running KGW TW.

If the TW exploit isn't pulled back before the hard fork, it will instantly catch up at the next hard fork due to diff swings and be in full full implementation. So either way I win, fix it or don't fix it.


So after month of  posting we end up seeing absolut nothing from you?

Don't get me wrong.. I don't judge what you planed to do.. I don't care... ( although I am  a BIG AUR bag holder since 1 or 2 days: I mined 0.5 AUR hurray!! )

No..but I would like to see a proof of your chain or something in any way or form because I want to know if it was indeed technical possible and not theoretical nature only and I want to see if you had the skills to do so. You talked a bit too selfconfident toward the end to really still believe it's more than just you talking.


Well hopefully some coin that still uses the gravity well and still has a pathetically feeble hashrate will be discovered so that a demonstration of a successful attack can still be done... Cheesy

Can anyone suggest any worthy candidates?

-MarkM-
hero member
Activity: 965
Merit: 515

Yes per our agreement I will pull back the exploit and allow a fix.

As explained by Nite69 I am gaining on the chain with a current running KGW TW.

If the TW exploit isn't pulled back before the hard fork, it will instantly catch up at the next hard fork due to diff swings and be in full full implementation. So either way I win, fix it or don't fix it.


So after month of  posting we end up seeing absolut nothing from you?

Don't get me wrong.. I don't judge what you planed to do.. I don't care... ( although I am  a BIG AUR bag holder since 1 or 2 days: I mined 0.5 AUR hurray!! )

No..but I would like to see a proof of your chain or something in any way or form because I want to know if it was indeed technical possible and not theoretical nature only and I want to see if you had the skills to do so. You talked a bit too selfconfident toward the end to really still believe it's more than just you talking.
legendary
Activity: 2940
Merit: 1090
Great.

So back to "why single out Aurora?"

Are there any other chains using that gravity well that enough people actually care about and/or have as many innocents standing to be scammed as in the case of Aurora?

Aurora seems like a good choice for this object-lesson since the innocent citizens of Iceland were involved.

All the other coins that use the gravity well and similarly vulnerable difficulty-adjustments might have been more deserving of being trashed, and less deserving of getting to see some other coin serve as the object-lesson, but hey, how many of them will even actually bother with the fix, maybe having already dumped their pre-mine and moved on to create more scams?

-MarkM-
full member
Activity: 232
Merit: 100
Yeah, congratulations to all on settling this with a bit of maturity and dignity.  It is a little bit of an anti climax though - maybe we can have a poll on who to hate on next. 
newbie
Activity: 51
Merit: 0
Yes per our agreement I will pull back the exploit and allow a fix.
Respect.
legendary
Activity: 2940
Merit: 1090
A particularly cute aspect of the attack is that it seems the higher the difficulty of the legitimate blockchain the more leverage (effective multiplying of hash power) the attacker enjoys.

That is not to say that a higher difficulty blockchain is easier to attack, necessarily, but merely that the fraction of the main chain's hashpower the attacker needs seems likely to shrink as the difficulty of the main chain grows.

Just how much the attack can lower the effective difficulty the attacker can enjoy would also effect this ratio though. If the attacker cannot keep the difficulty on their attack chain really really low they would not get as much advantage as they could if they could keep it minimised/minimal.

The advantage seems to be due to the chance of a hash being lucky enough to get into the blockchain.

The attacker makes more blocks, of lower difficulty, than the main chain.

The lower difficulty means each hash has a higher chance of getting a block thus getting into the chain thus counting toward the total "work" of the chain.

The higher the difficulty of the main chain blocks, the less chance any particular individual hash anyone does on it will get a block thus get into the chain, so less of the hashes it does count as "work" for purposes of checking which chain has the most "work".

-MarkM-
sr. member
Activity: 477
Merit: 500
Every coin that uses KGW should apply the fix as well asap right?
Yes, I think so.

Any idea if digishield or dgw (version2) are susceptible to the same exploit?
Have not yet dig too deeply on it, but:
Digishield: not the same, but possibly similar. KGW counts a lot of blocks to calculate adjustment, digishield only one, so it quite different. In KGW, attacker can 'jump over' the block in the future, which is not possible with only 1 block. Not yet sure, but there might be another TW exploit: Can you generate 2 blocks with dT less than 2xtarget so difficulty won't rise? If you generate block with dT 0, you get diff +25%, if I calculated correctly. next question: can you generate a block with -25% difficulty with less than 2*timespan? I think you get only -12.5% with 2 blocks time, so this hole is not open :-). But not sure if there are others.
 Edit: this is dogecoin digishiel, don't know others..

DGW: possibly, quick peek reveals no fix, but it might be there, have to make deeper look at it to be sure.
member
Activity: 76
Merit: 10
Every coin that uses KGW should apply the fix as well asap right?

Any idea if digishield or dgw (version2) are susceptible to the same exploit?

Every coin using 1 block retargeting should take note. BCX has correctly identified an attack vector that an attacker (like himself) with enough resources could exploit. We will indeed have to make appropriate changes in light of this.
hero member
Activity: 966
Merit: 1003
Every coin that uses KGW should apply the fix as well asap right?

Any idea if digishield or dgw (version2) are susceptible to the same exploit?
member
Activity: 92
Merit: 10
why is this even fucking being discussed in such detail over AUR?!? What is it with AUR that is attracting so much attention on whether or not it will be hacked and crashed?!?

I see no other discussions about this regarding other alt-coins.

It's almost as if because of the nature of AUR, there are certain individuals that are hellbent in destroying it before it gains any kind of popularity.

Just leave it the fuck alone and let it die on it's own if it's a scam. Why the hell is there a concerted effort in trying to make it crash and burn???
sr. member
Activity: 477
Merit: 500
It is April Fools day today, but this is no april fool trick. I believe BCX stands behind his words, even on April Fools day.

The exploit BCX has found in KGW implememtation is real and, I believe, he is most likely attacking with the exploit just now. However, we have also found a fix to it which will close the case. BCX has confirmed that the fix, when effective, will prevent using the exploit.

Since we are in a kind of stalemate we have agreed to settle down. Continuing this battle is worthless and would only cause harm to all participants. The fix is not yet effective and it is quite likely much damage would be caused if attack would get to the end. Also we all have achieved what we were after; BCX has made his point clear and the coin will be fixed. From the beginning, no one, not even BCX has wanted to destroy the coin.

BCX, do you agree? Is this an agreement?

EDIT: Here is the fix, feel free to update your coins. just change the hard fork block number

Code:
diff --git a/src/main.cpp b/src/main.cpp
index fd881d1..7687d3a 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -886,7 +886,7 @@ unsigned int static GravityWell(const CBlockIndex* pindexLast, const CBlock *pbl
        double                          EventHorizonDeviationSlow;
      
     if (BlockLastSolved == NULL || BlockLastSolved->nHeight == 0 || (uint64)BlockLastSolved->nHeight < PastBlocksMin) { return bnProofOfWorkLimit.GetCompact
-      
+       int64 LatestBlockTime = BlockLastSolved->GetBlockTime();
        for (unsigned int i = 1; BlockReading && BlockReading->nHeight > 0; i++) {
                if (PastBlocksMax > 0 && i > PastBlocksMax) { break; }
                PastBlocksMass++;
@@ -895,10 +895,14 @@ unsigned int static GravityWell(const CBlockIndex* pindexLast, const CBlock *pbl
                else            { PastDifficultyAverage = ((CBigNum().SetCompact(BlockReading->nBits) - PastDifficultyAveragePrev) / i) + PastDifficultyAvera
                PastDifficultyAveragePrev = PastDifficultyAverage;
              
-               PastRateActualSeconds                   = BlockLastSolved->GetBlockTime() - BlockReading->GetBlockTime();
+               if (LatestBlockTime < BlockReading->GetBlockTime()) {
+                       if (BlockReading->nHeight > XXXXX) // HARD Fork block number
+                               LatestBlockTime = BlockReading->GetBlockTime();
+               }
+               PastRateActualSeconds                   = LatestBlockTime - BlockReading->GetBlockTime();
                PastRateTargetSeconds                   = TargetBlocksSpacingSeconds * PastBlocksMass;
                PastRateAdjustmentRatio                 = double(1);
-               if (PastRateActualSeconds < 0) { PastRateActualSeconds = 0; }
+               if (BlockReading->nHeight > XXXXX) { // HARD Fork block number
+                       if (PastRateActualSeconds < 1) { PastRateActualSeconds = 1; }
+               } else {
+                       if (PastRateActualSeconds < 0) { PastRateActualSeconds = 0; }
+               }
                if (PastRateActualSeconds != 0 && PastRateTargetSeconds != 0) {
                PastRateAdjustmentRatio                 = double(PastRateTargetSeconds) / double(PastRateActualSeconds);
                }


Edit2: small modification for the fix
Edit3: added a missing an opening curly bracket, ty Cannacoin!
Pages:
Jump to: