Bitcoin Forum

Alternate cryptocurrencies => Altcoin Discussion => Topic started by: Nite69 on April 01, 2014, 02:40:53 PM



Title: Regarding Auroracoin TW exploit (Fix included)
Post by: Nite69 on April 01, 2014, 02:40:53 PM
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!


Title: Re: Regarding Auroracoin TW exploit
Post by: lphelps on April 01, 2014, 03:30:31 PM
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???


Title: Re: Regarding Auroracoin TW exploit
Post by: illodin on April 01, 2014, 04:10:21 PM
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?


Title: Re: Regarding Auroracoin TW exploit
Post by: balduro on April 01, 2014, 06:04:51 PM
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.


Title: Re: Regarding Auroracoin TW exploit
Post by: Nite69 on April 01, 2014, 06:18:18 PM
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.


Title: Re: Regarding Auroracoin TW exploit
Post by: markm on April 01, 2014, 06:18:59 PM
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-


Title: Re: Regarding Auroracoin TW exploit
Post by: ElMariachi on April 01, 2014, 06:48:30 PM
Yes per our agreement I will pull back the exploit and allow a fix.
Respect.


Title: Re: Regarding Auroracoin TW exploit
Post by: WompRat on April 01, 2014, 06:59:13 PM
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. 


Title: Re: Regarding Auroracoin TW exploit
Post by: markm on April 01, 2014, 06:59:49 PM
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-


Title: Re: Regarding Auroracoin TW exploit
Post by: gadado on April 01, 2014, 07:22:12 PM

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.


Title: Re: Regarding Auroracoin TW exploit
Post by: markm on April 01, 2014, 07:27:48 PM

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... :D

Can anyone suggest any worthy candidates?

-MarkM-


Title: Re: Regarding Auroracoin TW exploit
Post by: LTEX on April 01, 2014, 07:42:50 PM

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!


Title: Re: Regarding Auroracoin TW exploit
Post by: count_cyrpto on April 01, 2014, 07:51:05 PM
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. 


Title: Re: Regarding Auroracoin TW exploit
Post by: gadado on April 01, 2014, 07:56:33 PM

Did you read the post by Balduro, the founder and Nite69, the developer brought on by the Auroracoin Team? The exploit is live and is working or else I can assure you an agreement would not have been reached. I am satisfied with the agreement and you as an investor should be satisfied with that.

Of note also, it appears that Balduro is actually delivering the Air Drop as promised. I cannot 100% verify that yet and the method he used screams scam. However I am not above admitting mistakes and it is certainly appearing that Balduro has made the all time mother of implementing the right idea with the wrong execution!

More to come on this as I dig deeper.


~BCX~


I am not an investor. If I believed in Aurora I had mined it from the start.. but I thought that it is so obvious to anyone that it's a concept to make the dev rich that no one will mine or buy it. I guess I was wrong at that.

I am more into other coins and didn't read up what the Aurora dev posted.
I can check however then this are just 3 ppl for me that say it is so which has not much more value to me except there are some data and that's what I had liked to see. I am curious of such things. :)


Title: Re: Regarding Auroracoin TW exploit
Post by: Nite69 on April 01, 2014, 08:46:28 PM
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~

BCX, in the tecnical point of view; you are perfectly right. The algorithm implementation calculating the difficulty adjustments allow you to use your hashing power to generate a competing blockchain which would win the official blockchain. There is no doubt of that.

But the technical point of view is not the only one. The foundation of all cryptocurrencies is an agreement of all nodes to follow certain rules, which ends up in the possibility to agree about the generation and transaction of the currencies. The implementation of that agreement is the algorithms behind the currency.

This is also one protetion of the coins; if majority of the nodes agrees not to choose a hostile chain, they really can do it, they can reject it, regardless of the hashing power behind it. Technically this rejection would be accomplished by publishing a checkpoint from the official chain and all nodes accepting it. I'm not sure if it would have happened on this case, but I want to believe so. If this community values the coin enought, they will also protect it against all threats.

There is also no doubt, that a succesfull attack like that would in any case cause a lot of damage. But my opinion is, it likely would not have destroyed the coin.

However, this case also emphasizes the importance of the strength of the algorithms behind the coin. Those algorithms are the agreement and they should be tested all the time. In the end, these tests only strenghten the agreements and also the coin and increase trust to it. So however asshole you are BCX, you are an asshole in a good way, thank you!


Title: Re: Regarding Auroracoin TW exploit
Post by: YarkoL on April 01, 2014, 09:52:31 PM
So however asshole you are BCX, you are an asshole in a good way, thank you!

There's a special term (http://en.wikipedia.org/wiki/Trickster) for this kind of individual.

Quote
The trickster deity breaks the rules of the gods or nature, sometimes maliciously (for example, Loki) but usually with ultimately positive effects (though the trickster's initial intentions may have been either positive or negative). Often, the bending/breaking of rules takes the form of tricks (e.g. Eris) or thievery.


Title: Re: Regarding Auroracoin TW exploit
Post by: micryon on April 01, 2014, 10:52:10 PM
Good stuff guys.

Glad to see the community coming together on this one..


Title: Re: Regarding Auroracoin TW exploit
Post by: Bimmerhead on April 01, 2014, 11:32:18 PM

Of note also, it appears that Balduro is actually delivering the Air Drop as promised. I cannot 100% verify that yet and the method he used screams scam. However I am not above admitting mistakes and it is certainly appearing that Balduro has made the all time mother of implementing the right idea with the wrong execution!

More to come on this as I dig deeper.


~BCX~

Well I didn't see that one coming.  Kudos to BCX for being the man and admitting his error.


Title: Re: Regarding Auroracoin TW exploit
Post by: s4w3d0ff on April 01, 2014, 11:58:18 PM
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~

BCX, in the tecnical point of view; you are perfectly right. The algorithm implementation calculating the difficulty adjustments allow you to use your hashing power to generate a competing blockchain which would win the official blockchain. There is no doubt of that.

But the technical point of view is not the only one. The foundation of all cryptocurrencies is an agreement of all nodes to follow certain rules, which ends up in the possibility to agree about the generation and transaction of the currencies. The implementation of that agreement is the algorithms behind the currency.

This is also one protetion of the coins; if majority of the nodes agrees not to choose a hostile chain, they really can do it, they can reject it, regardless of the hashing power behind it. Technically this rejection would be accomplished by publishing a checkpoint from the official chain and all nodes accepting it. I'm not sure if it would have happened on this case, but I want to believe so. If this community values the coin enought, they will also protect it against all threats.

There is also no doubt, that a succesfull attack like that would in any case cause a lot of damage. But my opinion is, it likely would not have destroyed the coin.

However, this case also emphasizes the importance of the strength of the algorithms behind the coin. Those algorithms are the agreement and they should be tested all the time. In the end, these tests only strenghten the agreements and also the coin and increase trust to it. So however asshole you are BCX, you are an asshole in a good way, thank you!


This has been a well known exploit ever since KGW was starting to get popular, I was lucky with my coin and was notified of this exploit early so that I could make a hasty update and stop it from happening. I am surprised that NO ONE in the AUR knew about the exploit and/or said anything until BCX implemented the TW. Even Darkcoin saw it coming and made a supposed "fix".


Title: Re: Regarding Auroracoin TW exploit
Post by: CHAOSiTEC on April 02, 2014, 12:16:21 AM
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~

BCX, in the tecnical point of view; you are perfectly right. The algorithm implementation calculating the difficulty adjustments allow you to use your hashing power to generate a competing blockchain which would win the official blockchain. There is no doubt of that.

But the technical point of view is not the only one. The foundation of all cryptocurrencies is an agreement of all nodes to follow certain rules, which ends up in the possibility to agree about the generation and transaction of the currencies. The implementation of that agreement is the algorithms behind the currency.

This is also one protetion of the coins; if majority of the nodes agrees not to choose a hostile chain, they really can do it, they can reject it, regardless of the hashing power behind it. Technically this rejection would be accomplished by publishing a checkpoint from the official chain and all nodes accepting it. I'm not sure if it would have happened on this case, but I want to believe so. If this community values the coin enought, they will also protect it against all threats.

There is also no doubt, that a succesfull attack like that would in any case cause a lot of damage. But my opinion is, it likely would not have destroyed the coin.

However, this case also emphasizes the importance of the strength of the algorithms behind the coin. Those algorithms are the agreement and they should be tested all the time. In the end, these tests only strenghten the agreements and also the coin and increase trust to it. So however asshole you are BCX, you are an asshole in a good way, thank you!


This has been a well known exploit ever since KGW was starting to get popular, I was lucky with my coin and was notified of this exploit early so that I could make a hasty update and stop it from happening. I am surprised that NO ONE in the AUR knew about the exploit and/or said anything until BCX implemented the TW. Even Darkcoin saw it coming and made a supposed "fix".

the principles or kgw was used, but the code was rewritten with new algorithms to make it react better to incoming changes regarding block generation time. also the potential attack vector of time delution was automatically fixed in what became dgw


Title: Re: Regarding Auroracoin TW exploit
Post by: bigc1984 on April 02, 2014, 01:50:44 AM
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.

DGW is not exploitable. It is not effected by this exploit, this has been confirmed. Darkcoin > *.


Title: Re: Regarding Auroracoin TW exploit
Post by: lajz99 on April 02, 2014, 02:09:24 AM
DGW is not exploitable. It is not effected by this exploit, this has been confirmed. Darkcoin > *.

Sounds like a challenge if I ever read one...


Title: Re: Regarding Auroracoin TW exploit
Post by: andyatcrux on April 02, 2014, 03:35:33 AM
Wow, BCX has a conscience! I am sure there will be no "I may have been wrong about the devs intentions" or "sorry." This will be touted as an abject lesson. That said, as awkward as this may all be for both parties to come to terms here, it is good to see that BCX is keeping his word. Both the threat of attack and now working on a resolution to mitigate the harm. Well done sir, just wish it could have been directed at more deserving coins. In the end you are making a contribution.


Title: Re: Regarding Auroracoin TW exploit
Post by: kalus on April 02, 2014, 03:37:54 AM
Wow, BCX has a conscience! I am sure there will be no "I may have been wrong about the devs intentions" or "sorry." This will be touted as an abject lesson.
yeah i doubt anybody will apologize to BCX either for all that shittalk, but nbd it's only altcoins.


Title: Re: Regarding Auroracoin TW exploit
Post by: andyatcrux on April 02, 2014, 03:47:26 AM
Please try to keep my post in context. Thanks. I hear what you are saying though. I think BCX is probably not expecting any sorry.

EDIT: I did fail to read this:


Of note also, it appears that Balduro is actually delivering the Air Drop as promised. I cannot 100% verify that yet and the method he used screams scam. However I am not above admitting mistakes and it is certainly appearing that Balduro has made the all time mother of implementing the right idea with the wrong execution!

More to come on this as I dig deeper.


~BCX~

Well I didn't see that one coming.  Kudos to BCX for being the man and admitting his error.

I guess this is fair enough. I do think many were trying to tell him this, some in a not so nice way, but many were trying to use level reasoning. I am gonna chalk it up to the fact that there are many horrible scams out there and there is no doubt that AUR (I believe unintentionally) opened the door to scamcoins to use this model of coin.


Title: Re: Regarding Auroracoin TW exploit
Post by: ElMariachi on April 02, 2014, 04:55:05 AM
The foundation of all cryptocurrencies is an agreement
[...]
So however asshole you are BCX, you are an asshole in a good way, thank you!
First thing is a nice idea but as has become more than obvious again and again basing things solely on trust is usually a very bad idea. You talked about algorithms having to be improved too and that being part of that "agreement" to which I entirely agree.

The last thing however was unneeded imho though, but hey, I doubt BCX will cry about it ;)


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Nite69 on April 02, 2014, 05:57:50 AM
I added the fix to the original post, feel free to update your coins. If someone want to give this a fancy name, just go ahead!


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: LTEX on April 02, 2014, 07:31:17 AM
I added the fix to the original post, feel free to update your coins. If someone want to give this a fancy name, just go ahead!

Great job mate! How about "GoodNite"  ;D


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: _noname_ on April 02, 2014, 07:39:00 AM
Good going BCX. This is what I want to see from old/senior members. And apology for calling you a scammer in other threads. I will remove those.


Title: Re: Regarding Auroracoin TW exploit
Post by: Nite69 on April 02, 2014, 01:30:08 PM
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.



I must make a re-estimate on digishield. It does allow back to median 11 blocks, ie one can go back in time.
1 Go to the future 12:00:00 -> get diff -50%
2 Go back 11:59:30 -> get diff +25%

Yes, there is attack vector.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: ghostlander on April 02, 2014, 11:39:02 PM
This bug is possible due to no hard limiter at all for difficulty adjustments as well as a large allowance for the future time stamps. EventHorizonDeviation is an averaging factor and doesn't work as a limiting factor. It isn't really supposed to. A retarget code which allows difficulty abuse of such extreme magnitude like with AUR recently isn't a good one. By the way, how many coin developers have copied KGW to their coins without having a good understanding of the internals just because it's a popular trend? That's a rhetorical question.


Title: Re: Regarding Auroracoin TW exploit
Post by: ZeroBarrier on April 03, 2014, 01:09:40 AM
I have looked over Dogecoin's implementation, and it is more than likely vulnerable as well.  It is hard to say however, because Dogecoin has a significantly higher hash rate than most other coins and has included a dampening on the adjustment.

Correct me if I am wrong, but I don't think DOGE uses KGW.

Edit: NVM, just read the dev blog and saw they implemented DigiShield in the last update, v1.6.


Title: Re: Regarding Auroracoin TW exploit
Post by: Dabs on April 03, 2014, 01:37:13 AM
So however asshole you are BCX, you are an asshole in a good way, thank you!



Please I work hard to be a regular asshole, don't paint me in a good light. :D


~BCX~

I confirm that BCX is an asshole. :)


Title: Re: Regarding Auroracoin TW exploit
Post by: MegaHertz on April 03, 2014, 06:22:43 AM
So however asshole you are BCX, you are an asshole in a good way, thank you!



Please I work hard to be a regular asshole, don't paint me in a good light. :D


~BCX~

I confirm that BCX is an asshole. :)

one that i find very interesting though. 

though, i have only joined since Auroracoin....  ( hold the tomato's please ) 

but programming since 83, so lets just say its been quite a ride.   very impressed with the "new" generation.

MHz


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: markm on April 03, 2014, 07:23:40 AM

By the way, how many coin developers have copied KGW to their coins without having a good understanding of the internals just because it's a popular trend? That's a rhetorical question.

Billions and billions.

That's a rhetorical answer. :)

-MarkM-


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: illodin on April 03, 2014, 07:53:36 AM

By the way, how many coin developers have copied KGW to their coins without having a good understanding of the internals just because it's a popular trend? That's a rhetorical question.

Billions and billions.

That's a rhetorical answer. :)

-MarkM-


And how many of those coins have insanely insecure hashrates?  :P

-illodin-


Title: Re: Regarding Auroracoin TW exploit
Post by: MegaHertz on April 03, 2014, 07:56:41 AM

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.



Did you read the post by Balduro, the founder and Nite69, the developer brought on by the Auroracoin Team? The exploit is live and is working or else I can assure you an agreement would not have been reached. I am satisfied with the agreement and you as an investor should be satisfied with that.

Of note also, it appears that Balduro is actually delivering the Air Drop as promised. I cannot 100% verify that yet and the method he used screams scam. However I am not above admitting mistakes and it is certainly appearing that Balduro has made the all time mother of implementing the right idea with the wrong execution!

More to come on this as I dig deeper.


~BCX~

I can state honestly, so help me God, that what I have seen here in Reykjavik is fair distribution of the coins.  

Of course, there were some who had difficulties.   That "resolved itself" a few days ago.  Actually, I am sure Baldur and crew made some changes to improve claim rates.

Also, of course, there have been who have claiming for many relatives, however that is up to the family and relatives in question.

Have there been some "thefts" ?  I honestly don't know, I'm sure some small percentage.   Just like there was a small percentage who may have lost their coins due to Server Overload and unsuccessful transactions from the pre-mined mint -> verification -> blockchain -> wallet.   There were even people who just clicked ahead, past the page that said to print out their wallet... so...

my thoughts (continued) are that as we are creeping towards 10 percent claimed, in as many days, I sense a general feeling of fairness from the hundreds ( okay, five dozen or so ) of Icelanders I have questioned.  ( friends, taxi drivers, store owners, restaurant owners )

So, yes, BCX, Baldur does seem to be delivering.    AND perhaps his strategy (Facebook and SMS) had flaws.     But when I came to think about it (that night when the details became obvious)    it actually made ALOT of sense to use FB as there are many checks available, cross references, and what? about 95% Facebook usage in Iceland ?  

So, for getting out 10% of 330,000 people, and 10,500,000 coins  ( 31.8)   I would say it is as open as possible.

And then of course we have round 2 and round 3 and round 4 of the airdrop still to come..... Which I am quite sure will even be an improvement over previous rounds.....    

Anyway, that is my 1 AUR worth.       Thank you for contributing to the strength of Auroracoin.   I can promise you that when all of the dust settles the Icelandic people will be much more informed about all the developments and responsibilities of this coin.  

takk takk frá Íslandi.... come to visit some day, we welcome you as a friend.

MHz


Title: Re: Regarding Auroracoin TW exploit
Post by: ZeroBarrier on April 03, 2014, 08:22:34 AM
I can state honestly, so help me God, that what I have seen here in Reykjavik is fair distribution of the coins.  

Of course, there were some who had difficulties.   That "resolved itself" a few days ago.  Actually, I am sure Baldur and crew made some changes to improve claim rates.

Also, of course, there have been who have claiming for many relatives, however that is up to the family and relatives in question.

Have there been some "thefts" ?  I honestly don't know, I'm sure some small percentage.   Just like there was a small percentage who may have lost their coins due to Server Overload and unsuccessful transactions from the pre-mined mint -> verification -> blockchain -> wallet.   There were even people who just clicked ahead, past the page that said to print out their wallet... so...

my thoughts (continued) are that as we are creeping towards 10 percent claimed, in as many days, I sense a general feeling of fairness from the hundreds ( okay, five dozen or so ) of Icelanders I have questioned.  ( friends, taxi drivers, store owners, restaurant owners )

So, yes, BCX, Baldur does seem to be delivering.    AND perhaps his strategy (Facebook and SMS) had flaws.     But when I came to think about it (that night when the details became obvious)    it actually made ALOT of sense to use FB as there are many checks available, cross references, and what? about 95% Facebook usage in Iceland ?  

So, for getting out 10% of 330,000 people, and 10,500,000 coins  ( 31.8)   I would say it is as open as possible.

And then of course we have round 2 and round 3 and round 4 of the airdrop still to come..... Which I am quite sure will even be an improvement over previous rounds.....    

Anyway, that is my 1 AUR worth.       Thank you for contributing to the strength of Auroracoin.   I can promise you that when all of the dust settles the Icelandic people will be much more informed about all the developments and responsibilities of this coin.  

takk takk frá Íslandi.... come to visit some day, we welcome you as a friend.

MHz

The unfortunate fact remains that unless Iceland does some sort of official AUR census and asks every single household whether they claimed and received their 31.8 AUR, we might never know if the dev has been laundering and siphoning AUR from the premine into random undisclosed wallets that he and his team hold to dump at a slow and controlled rate to keep the market from crashing and thus maximize profits because of the extreme lack of liquidity of AUR. There is still a huge potential for scam surrounding AUR because of the lack of transparency; and I don't think that will ever really change.


Title: Re: Regarding Auroracoin TW exploit
Post by: Bimmerhead on April 03, 2014, 12:35:41 PM

The unfortunate fact remains that unless Iceland does some sort of official AUR census and asks every single household whether they claimed and received their 31.8 AUR, we might never know if the dev has been laundering and siphoning AUR from the premine into random undisclosed wallets that he and his team hold to dump at a slow and controlled rate to keep the market from crashing and thus maximize profits because of the extreme lack of liquidity of AUR. There is still a huge potential for scam surrounding AUR because of the lack of transparency; and I don't think that will ever really change.

Potential for scam and actual scam are two entirely different things.  We have to work with the world we live in.

No one has yet offered one iota of evidence that a scam is being perpetrated here yet, but evidence does exist that the airdrop is proceeding as advertised.  If you're looking for guarantees you'll have to call the FDIC.


Title: Re: Regarding Auroracoin TW exploit
Post by: pepo on April 03, 2014, 03:18:05 PM

The unfortunate fact remains that unless Iceland does some sort of official AUR census and asks every single household whether they claimed and received their 31.8 AUR, we might never know if the dev has been laundering and siphoning AUR from the premine into random undisclosed wallets that he and his team hold to dump at a slow and controlled rate to keep the market from crashing and thus maximize profits because of the extreme lack of liquidity of AUR. There is still a huge potential for scam surrounding AUR because of the lack of transparency; and I don't think that will ever really change.

Potential for scam and actual scam are two entirely different things.  We have to work with the world we live in.

No one has yet offered one iota of evidence that a scam is being perpetrated here yet, but evidence does exist that the airdrop is proceeding as advertised.  If you're looking for guarantees you'll have to call the FDIC.

I dont think that aurora is a scam , you have to give time , it took bitcoin 4 years to get some value. 1 aurora in a few years could cost 500 USd.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: MatthewLM on April 03, 2014, 08:43:05 PM
How is this exploitable as a fork attack exactly? The "exploited" chain allows for more blocks at lower difficulty, but the same amount of work goes into those blocks, so even though you have more blocks, you have less work and thus the chain shouldn't be regarded as the main chain by the software. Can anyone explain why this is wrong?

Of-course miners could deliberately try to push the difficulty down and decrease the time between blocks, increasing inflation of coins and the blockchain. Maybe some existing attacks could be made worse by this issue, but not critically so.

Please explain why I'm wrong if anyone can.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Prominence on April 03, 2014, 10:27:40 PM
Shall we keep calling it KGW or should we call the updated version: KGW+?


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: forzendiablo on April 04, 2014, 01:01:49 AM
we should call it BCX+ !


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Jilixi on April 04, 2014, 02:06:29 AM
Should have kept the exploit to himself and only ask people if they want to help kill off some coins. Would benefit everyone in crypto not having to see 20 coins come out each day...

Blackcoin multipool is one way to dump on other coins, exploits like this should be used as well, on as many coins as possible...


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Omnivion on April 04, 2014, 02:54:46 AM
How is this exploitable as a fork attack exactly? The "exploited" chain allows for more blocks at lower difficulty, but the same amount of work goes into those blocks, so even though you have more blocks, you have less work and thus the chain shouldn't be regarded as the main chain by the software. Can anyone explain why this is wrong?

Of-course miners could deliberately try to push the difficulty down and decrease the time between blocks, increasing inflation of coins and the blockchain. Maybe some existing attacks could be made worse by this issue, but not critically so.

Please explain why I'm wrong if anyone can.

I believe the main chain is the one which is longest, rather than which has the highest sum of work or difficulty.  I'm sure someone can correct me if this is mistaken.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: romang on April 04, 2014, 03:04:14 AM
This coin is a total waste.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Cryddit on April 04, 2014, 04:49:36 AM
Honestly I believe that the proof-of-work is better measured without regard to the difficulty level.

The way difficulty works, you might need some particular number of  leading zeros to make a block.  If the number is thirty, approximately one in a million hashes actually are capable of making a block.  But regardless of what you need to make a block, every hash that *actually has* thirty-one leading zeros is evidence of approximately two million hashes being done, every hash that *actually has* thirty-two leading zeros is evidence of approximately four million hashes having been done, every hash that *actually has* thirty-three leading zeros is evidence of approximately eight million hashes having been done, and so on.

I'm just saying that you can compare like with like in terms of estimating block difficulty.  Pick a target that definitely would have formed a block, regardless of the time, regardless of which branch -- corresponding to the highest of any difficulty for either branch during the time in question, and count the number of blocks with a hash below that target.  Whichever chain has the most such blocks is, as best anyone can tell, the chain that's had the most hashes done in support of it, regardless of where the difficulty level for the chain was set at the time or how many total blocks are in that chain.



Title: Re: Regarding Auroracoin TW exploit
Post by: CartmanSPC on April 04, 2014, 05:33:12 AM
So however asshole you are BCX, you are an asshole in a good way, thank you!
Please I work hard to be a regular asshole, don't paint me in a good light. :D
~BCX~
I confirm that BCX is an asshole. :)

It's good to see BCX still around and kicking....and living up to his namesake. Maybe it's me who hasn't been around as much (just now finding out about this) but I miss the days where he would wreak havoc on a regular basis ;)

In the end it's beneficial IMO.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Nite69 on April 04, 2014, 06:36:40 AM
How is this exploitable as a fork attack exactly? The "exploited" chain allows for more blocks at lower difficulty, but the same amount of work goes into those blocks, so even though you have more blocks, you have less work and thus the chain shouldn't be regarded as the main chain by the software. Can anyone explain why this is wrong?

Of-course miners could deliberately try to push the difficulty down and decrease the time between blocks, increasing inflation of coins and the blockchain. Maybe some existing attacks could be made worse by this issue, but not critically so.

Please explain why I'm wrong if anyone can.

I believe the main chain is the one which is longest, rather than which has the highest sum of work or difficulty.  I'm sure someone can correct me if this is mistaken.

I think saying the 'longest' chain is the valid chain is a misnomer.  Longest implies a length or a count, but if I am not mistaken, the valid chain is the one with the greatest proof-of-work.  In other words, the sum of the difficulty from each block in the chain.  A quick search brings up this link (http://bitcoin.stackexchange.com/questions/17837/longer-fake-block-chain-with-valid-transactions) which suggests what I have just said.

If we think back to science class, it was taught that work was equal to the product of force and distance.  For example, a 100 force by 5 distance results in 500 work, and a 10 force by 50 distance results in 500 work.  Both examples result in the same amount of work being accomplished, but they have arrived at that result from different paths.  This would be comparative to the main Auroracoin chain and BCX's attack chain.  The main chain was solving less blocks at a higher difficulty (the first example), while BCX was solving significantly more blocks at a lower difficulty (the second example).  Eventually, if given enough hashing power and time, BCX would have caught up with the main chain in amount of work done.  

As always, I could be wrong, and point out any mistakes I have made if I am wrong.

WTF? If that is true, then all this hassle is just bullshit. BCX would never have succeeded. Well, there is some source code where to check this.
Also, if it is so, it means all the other alt coins should be safe also.

Edit: As allways, I could have been wrong and you may just have pointed out mistake I have done.. Embarrassing :-\ Why didn't point this out earlier?


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Dabs on April 04, 2014, 06:59:45 AM
WTF? If that is true, then all this hassle is just bullshit. BCX would never have succeeded. Well, there is some source code where to check this.
Also, if it is so, it means all the other alt coins should be safe also.

Is that a challenge? Would you like to find out? You can't be too careful when dealing with money.

I've never lost important files but I always back up and do a check restore on them every now and then. Don't wait for any kind of possible attack to succeed, prevent it from even becoming an issue.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: markm on April 04, 2014, 07:10:15 AM
How is this exploitable as a fork attack exactly? The "exploited" chain allows for more blocks at lower difficulty, but the same amount of work goes into those blocks, so even though you have more blocks, you have less work and thus the chain shouldn't be regarded as the main chain by the software. Can anyone explain why this is wrong?

Of-course miners could deliberately try to push the difficulty down and decrease the time between blocks, increasing inflation of coins and the blockchain. Maybe some existing attacks could be made worse by this issue, but not critically so.

Please explain why I'm wrong if anyone can.

I believe the main chain is the one which is longest, rather than which has the highest sum of work or difficulty.  I'm sure someone can correct me if this is mistaken.

I think saying the 'longest' chain is the valid chain is a misnomer.  Longest implies a length or a count, but if I am not mistaken, the valid chain is the one with the greatest proof-of-work.  In other words, the sum of the difficulty from each block in the chain.  A quick search brings up this link (http://bitcoin.stackexchange.com/questions/17837/longer-fake-block-chain-with-valid-transactions) which suggests what I have just said.

If we think back to science class, it was taught that work was equal to the product of force and distance.  For example, a 100 force by 5 distance results in 500 work, and a 10 force by 50 distance results in 500 work.  Both examples result in the same amount of work being accomplished, but they have arrived at that result from different paths.  This would be comparative to the main Auroracoin chain and BCX's attack chain.  The main chain was solving less blocks at a higher difficulty (the first example), while BCX was solving significantly more blocks at a lower difficulty (the second example).  Eventually, if given enough hashing power and time, BCX would have caught up with the main chain in amount of work done.  

As always, I could be wrong, and point out any mistakes I have made if I am wrong.

WTF? If that is true, then all this hassle is just bullshit. BCX would never have succeeded. Well, there is some source code where to check this.
Also, if it is so, it means all the other alt coins should be safe also.

Edit: As allways, I could have been wrong and you may just have pointed out mistake I have done.. Embarrassing :-\ Why didn't point this out earlier?

Haven't you people been following along? It seems not.

Low difficulty means more chance any one hash gets a block so gets into the blockchain so counts when adding up work.

The higher the difficulty the less chance any one hash happens to get a block so less of the hashes done get into the blockchain to count as work.

So with lots of low difficulty blocks more of the hashes done to get them got into the chain to count as work so the more of the work done to make that chain gets counted when adding up height/length of the chain (the total work). This might also be part of why faster block chains achieve more security in less time; more confirmations (blocks) in the same amount of time is likely to be more actual work counted due to more of the work (hashes) done actually managing to make it into the blockchain.

-MarkM-


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: YarkoL on April 04, 2014, 07:14:09 AM

As always, I could be wrong, and point out any mistakes I have made if I am wrong.

I think that is the correct explanation.
The attack chain has individual blocks of low difficulty, but because it's longer, it has higher sum of difficulty.

Or as the discoverer of this exploit wrote:

That's the whole point, the current network will happily accept chain-of-massive-number-of-low-diff-blocks over chain-of-less-harder-blocks as long as the sum of difficulty of the first is higher and it follows the "rules set in stone" (no invalid tx, generation amount <= calculated amount, difficulty == getNextDifficulty(prevblock), block nTime > median of prev 11 blocks, block nTime can't be more than 2 h in the future, ...).


ArtForz also noted that any asymmetrical algorithm will be vulnerable. Because KGW is designed to deal with multipool problems and abrupt jumps in difficulty that are caused by fast increases in hashrate, it makes increasing diff harder than decreasing it. Because of that, attacker can get a lot of lower difficulty blocks at the cost of few larger difficulty blocks when he jumps back and forth in time.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Klacik on April 04, 2014, 07:40:22 AM
This coin is a total waste.

just like your post..


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Nite69 on April 04, 2014, 07:46:52 AM

As always, I could be wrong, and point out any mistakes I have made if I am wrong.

I think that is the correct explanation.
The attack chain has individual blocks of low difficulty, but because it's longer, it has higher sum of difficulty.

Or as the discoverer of this exploit wrote:

That's the whole point, the current network will happily accept chain-of-massive-number-of-low-diff-blocks over chain-of-less-harder-blocks as long as the sum of difficulty of the first is higher and it follows the "rules set in stone" (no invalid tx, generation amount <= calculated amount, difficulty == getNextDifficulty(prevblock), block nTime > median of prev 11 blocks, block nTime can't be more than 2 h in the future, ...).


ArtForz also noted that any asymmetrical algorithm will be vulnerable. Because KGW is designed to deal with multipool problems and abrupt jumps in difficulty that are caused by fast increases in hashrate, it makes increasing diff harder than decreasing it. Because of that, attacker can get a lot of lower difficulty blocks at the cost of few larger difficulty blocks when he jumps back and forth in time.

Hmm.. ok.. so in the end there really is a attack vector (however not so easy I have been thinking)? But that means summing the difficulty is a wrong way to measure the height of a blockchain. There should be a way (some algorithm) to assure a certain blockchain has been done with more work than the other, regardless of are they done with lots of low diff blocks or a few high diff blocks.

It should be possible to count the total amount of needed hashes calculated to generate a certain blockchain. And that should quite explicitely tell which blockchain really has been generated with most work.

Before I chitchat more bullshit, I guess I have to make some homework and familiarize myself more with the source.. and what block difficulty really relates to.

That's nice link to ArtForz comments. I have been wondering the same; does it need to be symmetric to protect the chain better? I think it is somehow weaker, if it is not, but that's not as big 'hole' than what other issues cause.

And, with symmetric algorithm and one block retarget, you have the problem not being able to calulate with zero or negative timespans. Truly symmetric would approach infinite difficulty when time difference approaches zero.


Title: Re: Regarding Auroracoin TW exploit
Post by: ghur on April 04, 2014, 08:09:02 AM
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~

So, there still isn't a new Auroracoin release, nor has the fix shown up on git...

When can we expect the fireworks? :)


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Zulandio on April 04, 2014, 10:20:48 AM
I still question if it didn't go something like this. IRS says coins are now considered personal property. Destroying a coin intentionally is destroying someone's personal property. Destroying thousands of dollars worth of property and your a felon and going to prison. OP Shit coin doesn't look like a really good idea anymore. Better not destroy shit coins...  ::)

This of course is just a conspiracy theory and not based on any facts.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: ghur on April 04, 2014, 11:00:12 AM
I still question if it didn't go something like this. IRS says coins are now considered personal property. Destroying a coin intentionally is destroying someone's personal property. Destroying thousands of dollars worth of property and your a felon and going to prison. OP Shit coin doesn't look like a really good idea anymore. Better not destroy shit coins...  ::)

This of course is just a conspiracy theory and not based on any facts.

Yeah.. good luck with that. That's not how it works.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: MatthewLM on April 04, 2014, 12:24:20 PM
Hmm.. ok.. so in the end there really is a attack vector (however not so easy I have been thinking)? But that means summing the difficulty is a wrong way to measure the height of a blockchain. There should be a way (some algorithm) to assure a certain blockchain has been done with more work than the other, regardless of are they done with lots of low diff blocks or a few high diff blocks.

It should be possible to count the total amount of needed hashes calculated to generate a certain blockchain. And that should quite explicitely tell which blockchain really has been generated with most work.


The main chain is calculated by total work done already. If it wasn't, this would actually open a vulnerability in Bitcoin. Unless you can trick the software into calculating more work at a lower difficulty I do not see how this is a critical issue. No one has explains why my logic is wrong yet. It's not critical that coins update KGW. The best any coin can do to increase security is to have a higher and well distributed hashrate.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: sonysasankan on April 04, 2014, 12:58:57 PM
I still question if it didn't go something like this. IRS says coins are now considered personal property. Destroying a coin intentionally is destroying someone's personal property. Destroying thousands of dollars worth of property and your a felon and going to prison. OP Shit coin doesn't look like a really good idea anymore. Better not destroy shit coins...  ::)

This of course is just a conspiracy theory and not based on any facts.

Yeah.. good luck with that. That's not how it works.

LOL.... some people just don't get how decentralization works :)


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: ghostlander on April 04, 2014, 01:29:06 PM
That's the whole point, the current network will happily accept chain-of-massive-number-of-low-diff-blocks over chain-of-less-harder-blocks as long as the sum of difficulty of the first is higher and it follows the "rules set in stone" (no invalid tx, generation amount <= calculated amount, difficulty == getNextDifficulty(prevblock), block nTime > median of prev 11 blocks, block nTime can't be more than 2 h in the future, ...).

ArtForz also noted that any asymmetrical algorithm will be vulnerable. Because KGW is designed to deal with multipool problems and abrupt jumps in difficulty that are caused by fast increases in hashrate, it makes increasing diff harder than decreasing it. Because of that, attacker can get a lot of lower difficulty blocks at the cost of few larger difficulty blocks when he jumps back and forth in time.

Hmm.. ok.. so in the end there really is a attack vector (however not so easy I have been thinking)? But that means summing the difficulty is a wrong way to measure the height of a blockchain. There should be a way (some algorithm) to assure a certain blockchain has been done with more work than the other, regardless of are they done with lots of low diff blocks or a few high diff blocks.

It should be possible to count the total amount of needed hashes calculated to generate a certain blockchain. And that should quite explicitely tell which blockchain really has been generated with most work.

Before I chitchat more bullshit, I guess I have to make some homework and familiarize myself more with the source.. and what block difficulty really relates to.

That's nice link to ArtForz comments. I have been wondering the same; does it need to be symmetric to protect the chain better? I think it is somehow weaker, if it is not, but that's not as big 'hole' than what other issues cause.

In order to succeed, an attacker needs to put more hash power into his chain than the other miners can supply. Their pools may be DDoS'ed or they may just autoswitch to a more profitable coin. There are also checkpoints, either hard coded or synchronised. No matter how much cumulative difficulty or trust score you have on a forked chain, it always fails against a checkpoint. KGW is just an overcomplicated solution with no difficulty limiting. This is what needs to be fixed actually.

Quote
And, with symmetric algorithm and one block retarget, you have the problem not being able to calulate with zero or negative timespans. Truly symmetric would approach infinite difficulty when time difference approaches zero.

A long averaging window can be used even for every block retargets. There are no zero or negative time spans.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Zulandio on April 04, 2014, 02:37:26 PM
I still question if it didn't go something like this. IRS says coins are now considered personal property. Destroying a coin intentionally is destroying someone's personal property. Destroying thousands of dollars worth of property and your a felon and going to prison. OP Shit coin doesn't look like a really good idea anymore. Better not destroy shit coins...  ::)

This of course is just a conspiracy theory and not based on any facts.

Yeah.. good luck with that. That's not how it works.

LOL.... some people just don't get how decentralization works :)

Pretty sure that's how it would work in the US. Now that it has a label of property it's like any other property and the law states personal property destruction etc. Decentralization has nothing to do with what I'm talking about. Cyber crimes are still cyber crimes anywhere you live on the planet and off it for that matter. Just like Gox has to answer to it's US customers. Crypto may be decentralized but the law is not. I could be wrong about this but so could you. Nobody really knows for sure what courts will rule. But I feel like a lawsuit or criminal charge in this area is on the horizon.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: btcdrak on April 04, 2014, 03:05:49 PM
I still question if it didn't go something like this. IRS says coins are now considered personal property. Destroying a coin intentionally is destroying someone's personal property. Destroying thousands of dollars worth of property and your a felon and going to prison. OP Shit coin doesn't look like a really good idea anymore. Better not destroy shit coins...  ::)

This of course is just a conspiracy theory and not based on any facts.

Yeah.. good luck with that. That's not how it works.

LOL.... some people just don't get how decentralization works :)

Pretty sure that's how it would work in the US. Now that it has a label of property it's like any other property and the law states personal property destruction etc. Decentralization has nothing to do with what I'm talking about. Cyber crimes are still cyber crimes anywhere you live on the planet and off it for that matter. Just like Gox has to answer to it's US customers. Crypto may be decentralized but the law is not. I could be wrong about this but so could you. Nobody really knows for sure what courts will rule. But I feel like a lawsuit or criminal charge in this area is on the horizon.

You are probably correct here. US, EU and UK all have laws which make it illegal to cause malicious damage to computer systems and computer networks. You can be sure, if the amounts of money involved warranted it, the police could and would probably get involved. Whether that can be applied to decentralized blockchains which actually have a "voting" mechanism to decide which chain is valid or not, would be a matter for the police to decide. It's certainly not clear cut in this case (by virtue of the fact the coins have a chain voting mechanism, proving malicious intent would be difficult I think).

That being said, I support making it hard for shitcoins to survive because frankly, it's far worse for people to release coins they have no idea how to maintain and thus endangering all their users. Not to mention all the scams that are being executed by shitcoin creators...


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: defaced on April 04, 2014, 03:46:56 PM
Hmm.. ok.. so in the end there really is a attack vector (however not so easy I have been thinking)? But that means summing the difficulty is a wrong way to measure the height of a blockchain. There should be a way (some algorithm) to assure a certain blockchain has been done with more work than the other, regardless of are they done with lots of low diff blocks or a few high diff blocks.

It should be possible to count the total amount of needed hashes calculated to generate a certain blockchain. And that should quite explicitely tell which blockchain really has been generated with most work.


The main chain is calculated by total work done already. If it wasn't, this would actually open a vulnerability in Bitcoin. Unless you can trick the software into calculating more work at a lower difficulty I do not see how this is a critical issue. No one has explains why my logic is wrong yet. It's not critical that coins update KGW. The best any coin can do to increase security is to have a higher and well distributed hashrate.

this


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: sonysasankan on April 04, 2014, 04:08:22 PM
I still question if it didn't go something like this. IRS says coins are now considered personal property. Destroying a coin intentionally is destroying someone's personal property. Destroying thousands of dollars worth of property and your a felon and going to prison. OP Shit coin doesn't look like a really good idea anymore. Better not destroy shit coins...  ::)

This of course is just a conspiracy theory and not based on any facts.

Yeah.. good luck with that. That's not how it works.

LOL.... some people just don't get how decentralization works :)

Pretty sure that's how it would work in the US. Now that it has a label of property it's like any other property and the law states personal property destruction etc. Decentralization has nothing to do with what I'm talking about. Cyber crimes are still cyber crimes anywhere you live on the planet and off it for that matter. Just like Gox has to answer to it's US customers. Crypto may be decentralized but the law is not. I could be wrong about this but so could you. Nobody really knows for sure what courts will rule. But I feel like a lawsuit or criminal charge in this area is on the horizon.

You are probably correct here. US, EU and UK all have laws which make it illegal to cause malicious damage to computer systems and computer networks. You can be sure, if the amounts of money involved warranted it, the police could and would probably get involved. Whether that can be applied to decentralized blockchains which actually have a "voting" mechanism to decide which chain is valid or not, would be a matter for the police to decide. It's certainly not clear cut in this case (by virtue of the fact the coins have a chain voting mechanism, proving malicious intent would be difficult I think).

That being said, I support making it hard for shitcoins to survive because frankly, it's far worse for people to release coins they have no idea how to maintain and thus endangering all their users. Not to mention all the scams that are being executed by shitcoin creators...

For any law to take effect, there needs to be jurisdiction. If I sit in Afghanistan and access a a network of computers in US and format them, that needs to be illegal in Afghanistan for me to be charged with a crime. Moreover there needs to be a complaint, friendly ties between the two govt, and enough volume/damage to warrant an Interpol case.  I believe shooting down a shitcoin's blockchain does not fall into that category  :D

Then there is the anonymity and decentralization issue. Crypto addresses are not tied to a physical location or person and there is no "court order" that you hand to someone to spill the beans of sorts. No way to prove anyone did anything here, neither is there any way to prove you lost fiat money.

BCX could be Morgan Freeman sitting in a cafe looking at Batman for all you know  ;)


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Cryddit on April 04, 2014, 05:51:49 PM

Destroying a coin intentionally is destroying someone's personal property. Destroying thousands of dollars worth of property and your a felon and going to prison.

If someone owned coins that had a higher value than they were actually worth, because of misrepresentations or in spite of flaws in the implementation, and the coins have become less valuable due to a correction precipitated by the exposure of this misrepresentation or flaw, that person joins the ranks of the millions of people who owned houses whose value was artificially inflated due to misrepresentations during the mortgage meltdown.  When the misrepresentations were exposed, the market corrected and the houses became less valuable.  Sucks to be them, but they're not getting that money back.

To blame BCX here here is the equivalent of blaming the people who exposed the fraud for the lost value of the homes.  It isn't their fault the mortgages were fraudulent.  And it isn't BCX's fault that somebody was misrepresenting a blockchain they hadn't secured as trustworthy.  Sucks to be the bagholder, but you were the victim of fraud, not vandalism, and if anybody deserves to go to jail, it's the people who made the fraudulent claims in the first place. 

Heck, if you consider anyone who destroys the value of coins, through an otherwise legal action, to be a criminal, you might as well try to prosecute the IRS for declaring that cryptocurrencies are property and subject to capital gains taxes. :D I predict you wouldn't get very far with that either.



Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: dE_logics on April 04, 2014, 06:15:39 PM
Ok, this DOES sound like an April fool's joke. The patch does not apply.

Code:
patching file src/main.cpp
Hunk #1 FAILED at 886.
patch: **** malformed patch at line 31: +


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: ghostlander on April 04, 2014, 07:33:06 PM
The main chain is calculated by total work done already. If it wasn't, this would actually open a vulnerability in Bitcoin. Unless you can trick the software into calculating more work at a lower difficulty I do not see how this is a critical issue. No one has explains why my logic is wrong yet. It's not critical that coins update KGW. The best any coin can do to increase security is to have a higher and well distributed hashrate.

this

What is to prevent me from creating a chain of greater proof-of-work comprised of lower difficulty blocks?  If I'm following protocol, nothing.  I more than likely don't need anywhere close to a majority of the hashing power since I am manipulating time.

Time warps can decrease or increase difficulty, but they cannot make you more hash power than you have actually. You still need 50%+ of the network hash rate.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: MatthewLM on April 04, 2014, 08:03:42 PM
Yes, the blockchain work has nothing to do with time. I still don't think this is an exploit and it's annoying because many exchanges have bought into it and are asking everyone to upgrade needlessly.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: ghur on April 04, 2014, 08:04:03 PM
Time warps can decrease or increase difficulty, but they cannot make you more hash power than you have actually. You still need 50%+ of the network hash rate.


No, the point of the time warp attack is that you don't need more than 50% of the network hashrate to execute the attack.
With that much hashing power you can always attack the chain, regardless of how the coin adjusts difficulty.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: btcdrak on April 04, 2014, 08:10:29 PM
Yes, the blockchain work has nothing to do with time. I still don't think this is an exploit and it's annoying because many exchanges have bought into it and are asking everyone to upgrade needlessly.

If you can drive the difficulty down you can generate a longer chain regardless of the power of the rest of the network. You could do this in isolation and then rejoin the main network and force a reorg. The exploit is very serious and if you pull it off, you can wreak havoc. Checkpoints wont help since you can rinse and repeat over and over and that much disruption to the network is simply a game over for the coin.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Nite69 on April 04, 2014, 08:24:14 PM
Now some puzzle for all you: What is a tricky hole this one fixes? Well I could be wrong, maybe this is just my imagination, but I think there was a funny attack vector. Please confirm or bust! (BCX, this is a special challenge for you!):
Code:
-               if (PastRateActualSeconds < 0) { PastRateActualSeconds = 0; }
+               if (BlockReading->nHeight > XXXXX) // HARD Fork block number
+                       if (PastRateActualSeconds < 1) { PastRateActualSeconds = 1; }
+               } else {
+                       if (PastRateActualSeconds < 0) { PastRateActualSeconds = 0; }
+               }



Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: MatthewLM on April 04, 2014, 08:32:26 PM
The main chain is not selected by "the longer chain". This is a myth which has been around for a long time. It is completely false. The main chain is selected by the amount of calculated work in the chain. You can produce loads of low difficulty blocks, but the total work will be stochastically (probabilistically) related to the total number of hashes done. You still need to do more work, meaning you need majority hashpower to catch up, whatever the difficulty is.

People need to understand this before going around shouting that there is an exploit with KGW that allows for blockchain forks. There is no need for pandemonium.

If there is a real exploit please explain how it works. No one has explained a real exploit yet.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: MatthewLM on April 04, 2014, 08:52:20 PM
51% attacks exist with or without KGW. You can't say KGW introduces a new attack if it makes an existing attack worse. Though I fail to see how it makes a 51% attack easier to perform.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: ghostlander on April 05, 2014, 12:15:05 AM
Time warps can decrease or increase difficulty, but they cannot make you more hash power than you have actually. You still need 50%+ of the network hash rate.

No, the point of the time warp attack is that you don't need more than 50% of the network hashrate to execute the attack.
With that much hashing power you can always attack the chain, regardless of how the coin adjusts difficulty.

It seems the original point of time warp attack as explained by ArtForz over 2 years ago has been missed by you. No matter how you play this game, you have to follow the rules and cumulative difficulty is one of them. You can mine at a lower difficulty or even attempt to double spend, but you still need to catch up with the original chain. It's up to your skills how to do that. In fact, time warps have never been a real problem for Bitcoin or Litecoin even though the latter addressed one of the issues in their code. This trouble is for those new "fast" coins and their developers who hardly understand what they're doing. Finally, ability to execute an attack doesn't imply ability to benefit from it.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Lamarth on April 05, 2014, 02:07:06 AM
Nite69, I think you're fixing a difficulty freeze hole - it's possible to spike difficulty up to an unlimited value if you have the following pattern
Block time A
Block time B (much larger than A)
... Many Blocks with time < B ...
Block time B + dx

Difficulty is raised by a factor of (found blocks * target time per block / dx). Now you need 70(ish) blocks in the middle, not sure how far forward you can stick a time stamp, but you don't need to be the source of those 72 blocks. e.g. you could predict when a multipool was about to hit and then try to set your attack block B. Finally, you close with the B + dx, a microsecond (or less) after B, and can start trying at any time after there are enough in the middle.

I'd like a difficulty 21 billion times higher, kkthx. Although, I'd say you're only limiting it to 21,000 times higher, or 73 days for the next block, if such an attack is performed, so I'm not convinced if this is what you were going for after all.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: coinoisgreat on April 05, 2014, 03:24:57 AM
Yes, the blockchain work has nothing to do with time. I still don't think this is an exploit and it's annoying because many exchanges have bought into it and are asking everyone to upgrade needlessly.



Would you like to back that statement up and offer your coin as a sacrificial lamb?


~BCX~

where is the evidence that you even attacked aur. it seems most these people here don't agree with you so i think most of our coins are probably safe.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: coinoisgreat on April 05, 2014, 06:42:02 AM
Yes, the blockchain work has nothing to do with time. I still don't think this is an exploit and it's annoying because many exchanges have bought into it and are asking everyone to upgrade needlessly.



Would you like to back that statement up and offer your coin as a sacrificial lamb?


~BCX~

where is the evidence that you even attacked aur. it seems most these people here don't agree with you so i think most of our coins are probably safe.


I see you hide behind a new registered account today with a single post while making that "bold" statement. Shows real confidence doesn't it.

All you and your fellow "devs" are whining about is that you paid someone to create a basic shitcoin clone and lack the technical ability to update it LOL

Maybe I really do need to kill a few to convince the masses.

Since you're so sure it's not possible, don't be a wanker, volunteer your coin!


~BCX~


if i was actually in charge of a coin i would be all about it. im not though. the guy with the charity coin doesn't seem to think that the flaw is such a big deal so why should i? so far we haven't seen any evidence that anyone has the know how to attack a coin like you talk about. especially since aur is still here and you gave a "pass" to the charity guy.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: vilgem on April 05, 2014, 10:21:53 AM
I looked at the diff file you proposed very thoroughly. And I must conclude that your fix is nothing more but a bullshit. The only thing your fix does - it protects PastRateActualSeconds varibale in a way that it is always >= 1 (second). Old code assumed it was always >= 0. You probably cared about PastRateAdjustmentRatio variable which is equal to 1 if PastRateActualSeconds happens to be 0. But the point is that it never happens. KGW takes at least PastBlocksMin and at most PastBlocksMax blocks into the calculation. You will never have PastRateActualSeconds == 0 except for the case if your blockchain has only one block.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Nite69 on April 05, 2014, 01:28:55 PM
I looked at the diff file you proposed very thoroughly. And I must conclude that your fix is nothing more but a bullshit. The only thing your fix does - it protects PastRateActualSeconds varibale in a way that it is always >= 1 (second). Old code assumed it was always >= 0. You probably cared about PastRateAdjustmentRatio variable which is equal to 1 if PastRateActualSeconds happens to be 0. But the point is that it never happens. KGW takes at least PastBlocksMin and at most PastBlocksMax blocks into the calculation. You will never have PastRateActualSeconds == 0 except for the case if your blockchain has only one block.

You have misunderstood the fix. There are 2 fixes and the one you are referring fixes another attack vector.

The fix to usual TW attack (which BCX was planning was to use) was to use LatestBlockTime instead of BlockLastSolved->GetBlockTime() to count the timespan. Without this one can timetravel back without diff rise, with this the benefit attacker gets by travellin past is lost.

The another fix (preventing PastRateActualSeconds to go to 0) takes care of another attack vector. Here is a short explanation of the attack:
1. generate a block 2 weeks to the future. You cannot publish it, it is not on current time window.
2. Start generating blocks with the same timestamp (ie the moment 2 weeks in the future)

See what would happen: after there is PastBlocksMax blocks in the private chain, *the diff would not change* at all!

That would mean you have 2 weeks to generate blocks with 0 difficulty. With decent hashrate, you easily get 1 block in a second. In 2 weeks you get 1209600 blocks.

When that 2 weeks has passed, what would happen to the blockchain, if you suddenly publish 1209600 perfectly valid blocks? The whole network would be doing nothing but checking those 1209600 blocks... and finding nothing wrong with them. That would be the end of the coin.

Quote
You will never have PastRateActualSeconds == 0 except for the case if your blockchain has only one block.
Thats not true. You can generate blocks with the same timestamp. Or is there something that would prevent it (I have not read all the code, it might be prevented somewhere) ? If there is, then this attack vector was already closed and this part was not necessary.

EDIT: Actually, it *is* prevented somewhere else. One can generate only 5 blocks with the same timestamp. So this #2 fix is not necessary to prevent that attack vector, it is already closed elsewhere. However that means the whole if clauses are never true, ie they are itself worthless. But leaving them as they were would keep there an unecessary dependancy between the code blocks, so it is nevertheless better to change it. Also, the main fix is #1, which has been confirmed to work.
Code:
    // Check timestamp against prev
    if (GetBlockTime() <= pindexPrev->GetMedianTimePast())
        return error("AcceptBlock() : block's timestamp is too early");


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: travwill on April 05, 2014, 02:19:22 PM
USDe has updated its KGW code to close the potential exploit gaps - thanks to users in this discussion for assistance in the solution.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: ghostlander on April 05, 2014, 03:05:06 PM
The another fix (preventing PastRateActualSeconds to go to 0) takes care of another attack vector. Here is a short explanation of the attack:
1. generate a block 2 weeks to the future. You cannot publish it, it is not on current time window.
2. Start generating blocks with the same timestamp (ie the moment 2 weeks in the future)

See what would happen: after there is PastBlocksMax blocks in the private chain, *the diff would not change* at all!

That would mean you have 2 weeks to generate blocks with 0 difficulty. With decent hashrate, you easily get 1 block in a second. In 2 weeks you get 1209600 blocks.

When that 2 weeks has passed, what would happen to the blockchain, if you suddenly publish 1209600 perfectly valid blocks? The whole network would be doing nothing but checking those 1209600 blocks... and finding nothing wrong with them. That would be the end of the coin.

First, an attacker still needs to exceed the cumulative difficulty score of the original chain. Second, there must not be any checkpoints on the original chain for those 2 weeks, neither hard coded nor synchronised. Third if the second is true, this is a huge reorganisation which won't pass unnoticed and a smart developer would secure his chain with a checkpoint immediately, release an updated client and ask the community to upgrade.

Quote
EDIT: Actually, it *is* prevented somewhere else. One can generate only 5 blocks with the same timestamp.

Median of 11 is 6 blocks. Although AUR has changed this to median of 3 which is a bad idea actually.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Cryddit on April 05, 2014, 03:25:39 PM
The problem that makes the time warp possible at all is that difficulty is being measured wrong. 

Having a lower difficulty threshold and more blocks, generated by a small fraction of the main chain's hashing power, should NEVER result in the difficulty calculation thinking that you have more total work than the main chain.

Consider two forks, one with a difficulty of, say 20 and one with a difficulty of, say, 11.  If there is actually more work on the chain with 11 difficulty, it will have more blocks that meet the 20 difficulty than the other chain has total blocks.  It shouldn't be getting any work credit at all for blocks that don't meet the hardest branch's difficulty.





Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: YarkoL on April 05, 2014, 04:03:07 PM
Having a lower difficulty threshold and more blocks, generated by a small fraction of the main chain's hashing power, should NEVER result in the difficulty calculation thinking that you have more total work than the main chain.

Your opinion, then, is that one really can make TW exploit with less than majority hashing power. I would be very grateful to know the reasoning behind that statement.







Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Nite69 on April 05, 2014, 04:08:27 PM
Median of 11 is 6 blocks. Although AUR has changed this to median of 3 which is a bad idea actually.

Saying it is a bad idea does not yet make it a bad idea. Can you give some reasoning behind this? If there is good reasoning, why didnt you tell that when it was only being planned?


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: ghostlander on April 05, 2014, 05:04:48 PM
Median of 11 is 6 blocks. Although AUR has changed this to median of 3 which is a bad idea actually.

Saying it is a bad idea does not yet make it a bad idea. Can you give some reasoning behind this? If there is good reasoning, why didnt you tell that when it was only being planned?

Why have you not asked? I'm not a part of your community, not supposed to monitor what you do and to give advice on every matter.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: memecoin on April 05, 2014, 09:41:05 PM
Yes, the blockchain work has nothing to do with time. I still don't think this is an exploit and it's annoying because many exchanges have bought into it and are asking everyone to upgrade needlessly.



Would you like to back that statement up and offer your coin as a sacrificial lamb?


~BCX~

where is the evidence that you even attacked aur. it seems most these people here don't agree with you so i think most of our coins are probably safe.


I see you hide behind a new registered account today with a single post while making that "bold" statement. Shows real confidence doesn't it.

All you and your fellow "devs" are whining about is that you paid someone to create a basic shitcoin clone and lack the technical ability to update it LOL

Maybe I really do need to kill a few to convince the masses.

Since you're so sure it's not possible, don't be a wanker, volunteer your coin!


~BCX~









Please do. I've found a comfortable seat, and I have plenty of snacks.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Cannacoin on April 05, 2014, 11:52:41 PM
Cannacoin has updated its protocol to patch the potential KGW/Time-Warp exploit. Thanks to everyone involved in the discussion and fix, your time and efforts are appreciated!


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: vilgem on April 06, 2014, 08:43:59 AM
I looked at the diff file you proposed very thoroughly. And I must conclude that your fix is nothing more but a bullshit. The only thing your fix does - it protects PastRateActualSeconds varibale in a way that it is always >= 1 (second). Old code assumed it was always >= 0. You probably cared about PastRateAdjustmentRatio variable which is equal to 1 if PastRateActualSeconds happens to be 0. But the point is that it never happens. KGW takes at least PastBlocksMin and at most PastBlocksMax blocks into the calculation. You will never have PastRateActualSeconds == 0 except for the case if your blockchain has only one block.

You have misunderstood the fix. There are 2 fixes and the one you are referring fixes another attack vector.

The fix to usual TW attack (which BCX was planning was to use) was to use LatestBlockTime instead of BlockLastSolved->GetBlockTime() to count the timespan. Without this one can timetravel back without diff rise, with this the benefit attacker gets by travellin past is lost.

The another fix (preventing PastRateActualSeconds to go to 0) takes care of another attack vector. Here is a short explanation of the attack:
1. generate a block 2 weeks to the future. You cannot publish it, it is not on current time window.
2. Start generating blocks with the same timestamp (ie the moment 2 weeks in the future)

See what would happen: after there is PastBlocksMax blocks in the private chain, *the diff would not change* at all!

That would mean you have 2 weeks to generate blocks with 0 difficulty. With decent hashrate, you easily get 1 block in a second. In 2 weeks you get 1209600 blocks.

When that 2 weeks has passed, what would happen to the blockchain, if you suddenly publish 1209600 perfectly valid blocks? The whole network would be doing nothing but checking those 1209600 blocks... and finding nothing wrong with them. That would be the end of the coin.

Quote
You will never have PastRateActualSeconds == 0 except for the case if your blockchain has only one block.
Thats not true. You can generate blocks with the same timestamp. Or is there something that would prevent it (I have not read all the code, it might be prevented somewhere) ? If there is, then this attack vector was already closed and this part was not necessary.

EDIT: Actually, it *is* prevented somewhere else. One can generate only 5 blocks with the same timestamp. So this #2 fix is not necessary to prevent that attack vector, it is already closed elsewhere. However that means the whole if clauses are never true, ie they are itself worthless. But leaving them as they were would keep there an unecessary dependancy between the code blocks, so it is nevertheless better to change it. Also, the main fix is #1, which has been confirmed to work.
Code:
    // Check timestamp against prev
    if (GetBlockTime() <= pindexPrev->GetMedianTimePast())
        return error("AcceptBlock() : block's timestamp is too early");
Ok, it turned out that you can't publish a block with a timestamp less or equal to the median time of several prior blocks. So, fix #2 is not necessary. Even if you could the attack you mentioned would be very unlikely. One would have to start working on a brach chain of PastBlocksMax blocks of the same timestamp. With every new block found the actual difficulty would RAISE (timespan would diminish with every new block found). It would be an exponential difficulty growth for several thousands iterations (the base difficulty would be equal to the network difficulty at the fork time). So, one would have to possess really good hashing power. I think that mathematically this attack is even less possible than wellknown 51% attack. More precisely this attack would have possibility 100% but the computation time would be HUGE.

Now... fix #1. I'm sorry but is not a fix. Logically both flows (without fix and with it) are absolutelly THE SAME. Just check it line by line very carefuly. Both flows protect PastRateActualSeconds variable in a way that it is >= 0. That is it. Just CHECK.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Nite69 on April 06, 2014, 07:35:31 PM

Now... fix #1. I'm sorry but is not a fix. Logically both flows (without fix and with it) are absolutelly THE SAME. Just check it line by line very carefuly. Both flows protect PastRateActualSeconds variable in a way that it is >= 0. That is it. Just CHECK.

The fix actually changes the way algorithm deals with blocks that are timestamped before the latest block's timestamp (ie timewarped blocks). It processes them just like if they were timestamped as the latest block. So if there is any benefit an attacker gets by timestamping the blocks in the past, the benefit will be gone. The attacker could as well timestamp them with latest blocks time. No more any extra gain from Time Warp, whatever it has been.

This change actually lowers the difficulty what the time warped block would get. However, the attacker would get the same lower diff by timestamping that block at the latest block time, ie not using timewarp, so the fix does not give any advantage which had not already been there.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: memecoin on April 07, 2014, 06:07:11 PM
It would be an exponential difficulty growth for several thousands iterations (the base difficulty would be equal to the network difficulty at the fork time). So, one would have to possess really good hashing power. I think that mathematically this attack is even less possible than wellknown 51% attack. More precisely this attack would have possibility 100% but the computation time would be HUGE.



You should sand box it before making those statements. This is exactly the vector that was opened up.


~BCX~

It appears some draino/coin hybrid has been hit with a difficulty of 55 million and just so happens to use KGW. Would you happen to know anything about this? Please tell me I didn't look away and miss something! ;D


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: ghur on April 07, 2014, 06:17:00 PM
It would be an exponential difficulty growth for several thousands iterations (the base difficulty would be equal to the network difficulty at the fork time). So, one would have to possess really good hashing power. I think that mathematically this attack is even less possible than wellknown 51% attack. More precisely this attack would have possibility 100% but the computation time would be HUGE.



You should sand box it before making those statements. This is exactly the vector that was opened up.


~BCX~

It appears some draino/coin hybrid has been hit with a difficulty of 55 million and just so happens to use KGW. Would you happen to know anything about this? Please tell me I didn't look away and miss something! ;D

Link?


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: memecoin on April 07, 2014, 06:31:13 PM
It would be an exponential difficulty growth for several thousands iterations (the base difficulty would be equal to the network difficulty at the fork time). So, one would have to possess really good hashing power. I think that mathematically this attack is even less possible than wellknown 51% attack. More precisely this attack would have possibility 100% but the computation time would be HUGE.



You should sand box it before making those statements. This is exactly the vector that was opened up.


~BCX~

It appears some draino/coin hybrid has been hit with a difficulty of 55 million and just so happens to use KGW. Would you happen to know anything about this? Please tell me I didn't look away and miss something! ;D

Link?

The announcement section is a jungle:
https://bitcointalk.org/index.php?topic=419873.msg6113496#msg6113496


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: ghur on April 07, 2014, 06:38:43 PM
It would be an exponential difficulty growth for several thousands iterations (the base difficulty would be equal to the network difficulty at the fork time). So, one would have to possess really good hashing power. I think that mathematically this attack is even less possible than wellknown 51% attack. More precisely this attack would have possibility 100% but the computation time would be HUGE.



You should sand box it before making those statements. This is exactly the vector that was opened up.


~BCX~

It appears some draino/coin hybrid has been hit with a difficulty of 55 million and just so happens to use KGW. Would you happen to know anything about this? Please tell me I didn't look away and miss something! ;D

Link?

The announcement section is a jungle:
https://bitcointalk.org/index.php?topic=419873.msg6113496#msg6113496

Thank you. It is a jungle indeed.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: simondlr on April 13, 2014, 03:05:08 PM
So here's my understanding of the TW exploit & the fix.

The problem with the well is that any blocks in the past (or blocks with the same timestamp), get regarded as "PastRateActualSeconds = 0"

      if (PastRateActualSeconds < 0) { PastRateActualSeconds = 0; }

What happens now, is that IF PastRateActualSeconds are 0, it does not adjust the diff.

     if (PastRateActualSeconds != 0 && PastRateTargetSeconds != 0)

So, the attacker does the following: they work on their own chain. They put the timestamp as far as possible into the future to get max downward adjustment, and continues until the diff is lowest possible diff for the chain. At that point, the attacker generates blocks with the same timestamp, until it hits the "block-time too early" (getmedianpast) check in AcceptBlock. Basically, the attacker is pumping loads of low-diff blocks "at the same time" until they can't anymore. Putting blocks in the past don't help as they get regarded as "0" anyway in terms of diff adjustment. But putting blocks in the past, allows the attacker to get back in line with the main chain.

So, now they do it again. Until getmedianpast check doesn't fail, and do it again. It's a trade-off between being too far ahead and having enough work. But if the chains match based on the time, it's entirely possible that the attacker has the same work, with more blocks and the chains re-organise.

So if I understand it correctly (correct me if I'm wrong), the attacker still needs 51%. But now that they HAVE that 51% they can do the same amount of work, but generate more blocks.

While the fix protects against this attack, by making it unfeasible, it actually causes other problems [sky high diff adjustments as was seen with Aiden & Coin-o].

What's SUPPOSED to happen is that the attacker is not supposed to generate blocks with the same timestamp & keep the same diff. In most scenarios, this would mean there is A LOT of hashing power and the diff should adjust accordingly.

That's what this fix does here:

if (PastRateActualSeconds < 1) { PastRateActualSeconds = 1; }

If it's a block in the past, or the same timestamp, it's regarded as having taken 1 second. The problem with this is, is that if there are legitimate blocks in the past [due to network lag, or other reasons] it is regarded as an extremely fast block, rather than a legitimate block [within range]. This shoots up the difficulty (as we've seen with some coins). This happens more easily with coins with low block-times.

These diff adjustments didn't happen with the original KGW because they weren't taken into account for the diff adjustment.

With diff adjustments happening per block, it's a difficult problem to solve. Any 1-block algo is vulnerable, as blocks in the past [which is a legitimate anomaly] is an "odd" happenstance in 1-block diff algos.

So the trade-off is:

1) When an attacker gains 51%, they have the capability to generate more blocks with the same work. While this is not ideal, the reason why this is bad, is that incentives 51% attacks (as it is more monetary profitable).
2) Remove the incentives with this fix, but screw up legitimate blocks from the past [which causes absurd diff adjustments].

Personally, I think there needs to be a small "free" period where blocks from the past is okay, which of course makes the KGW not a 1 block algo...

This is of course, all assuming I'm correct... BCX? Nite69? Others? Care to comment?

Thoughts?


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: ghostlander on April 13, 2014, 09:06:40 PM
if (PastRateActualSeconds < 1) { PastRateActualSeconds = 1; }

If it's a block in the past, or the same timestamp, it's regarded as having taken 1 second. The problem with this is, is that if there are legitimate blocks in the past [due to network lag, or other reasons] it is regarded as an extremely fast block, rather than a legitimate block [within range]. This shoots up the difficulty (as we've seen with some coins). This happens more easily with coins with low block-times.

1 second isn't much better than 0. There should be either a higher value as a fraction of block target or these blocks may be skipped from difficulty calculation or their time stamps recalculated as average of neighborous blocks. Another way is to limit every difficulty adjustment like many non-KGW algorithms do.

Quote
With diff adjustments happening per block, it's a difficult problem to solve. Any 1-block algo is vulnerable, as blocks in the past [which is a legitimate anomaly] is an "odd" happenstance in 1-block diff algos.

Not every. Those operating with large traditional averaging windows are fine, though their time warp vulnerability level is higher than usual. PPC even allows negative actual time span, so many faster forks got burned by this "feature". It samples only 2 time stamps per retarget (the last block and the previous one), applies extreme damping and gets the job done. Very slow as the damping suggests, though very easy to allow difficulty manipulations through time warps. Those PPC forks brave enough to run without the ACP enabled can be torn apart by 51% attacks quite easily.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Crestington on April 13, 2014, 10:00:06 PM
Altcoins check underneath their bed at night for BCX


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: simondlr on April 14, 2014, 02:45:14 PM

1 second isn't much better than 0. There should be either a higher value as a fraction of block target or these blocks may be skipped from difficulty calculation or their time stamps recalculated as average of neighborous blocks. Another way is to limit every difficulty adjustment like many non-KGW algorithms do.


Right. Agree on both counts. I was specifically referring to the fix. The fix treats blocks from that past as very, very fast blocks which shoots up the diff [which is not what you want].

Quote

Not every. Those operating with large traditional averaging windows are fine, though their time warp vulnerability level is higher than usual. PPC even allows negative actual time span, so many faster forks got burned by this "feature". It samples only 2 time stamps per retarget (the last block and the previous one), applies extreme damping and gets the job done. Very slow as the damping suggests, though very easy to allow difficulty manipulations through time warps. Those PPC forks brave enough to run without the ACP enabled can be torn apart by 51% attacks quite easily.


Didn't know about that. Interesting!

So what do you suggest? Other retargeting algos that seem promising, but haven't taken a look at is digishield and dark gravity wave2. How do they perform?

And do you agree with the trade-off? Implementing the fix pushes in erroneous diff adjustments that could be detrimental to the coin. Or make it so that a 51%-er can mint more blocks with the same work? Currently, I think it's not ideal to implement the current tw fix that everyone is implementing, since if someone is maliciously doing a 51% attack, you are screwed anyway...

Thoughts?


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Cryddit on April 14, 2014, 05:34:58 PM

The issue is a bug in branch difficulty evaluation, IMO.

BCX, can you check the logic here?  Isn't the real vulnerability to time warp due to it being possible to create a branch using less than 51% hashing power that the current code believes has more hashing work in it, than a branch created using more than 51% hashing power?  And doesn't that depend on the existence of a bug in the code that estimates how much hashing has gone into a branch?

Time warp exploits really oughtn't be possible if you can accurately pick the highest-work branch. 

If you pick a 'threshold' difficulty just high enough to ensure that any block meeting that threshold could appear in either branch regardless of when it was mined, and then you count the blocks meeting *that* difficulty, you get a very good comparison of the real hashing power used.  The one with the most such blocks is the one with the most hashing work.  Award no partial credit for blocks mined at lower difficulty as the current code (IMO erroneously) does, and I think you wind up with no time warp vulnerability. 



Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: ghostlander on April 16, 2014, 11:43:44 PM
Not every. Those operating with large traditional averaging windows are fine, though their time warp vulnerability level is higher than usual. PPC even allows negative actual time span, so many faster forks got burned by this "feature". It samples only 2 time stamps per retarget (the last block and the previous one), applies extreme damping and gets the job done. Very slow as the damping suggests, though very easy to allow difficulty manipulations through time warps. Those PPC forks brave enough to run without the ACP enabled can be torn apart by 51% attacks quite easily.


Didn't know about that. Interesting!

So what do you suggest? Other retargeting algos that seem promising, but haven't taken a look at is digishield and dark gravity wave2. How do they perform?

And do you agree with the trade-off? Implementing the fix pushes in erroneous diff adjustments that could be detrimental to the coin. Or make it so that a 51%-er can mint more blocks with the same work? Currently, I think it's not ideal to implement the current tw fix that everyone is implementing, since if someone is maliciously doing a 51% attack, you are screwed anyway...

Thoughts?

I've seen Orbitcoin time warped today with their difficulty falling to near zero in minutes literally. The coin is a fork of NVC with some bells and whistles using 1 hour PPC style retarget window and very fast blocks. Such a small window combined with their low network hash rate and no limits in the code made it possible. Their previous retarget fix sibstituted negative time span with 0, but it didn't help much. 1 wouldn't help either. The attacker instamined a couple thousand blocks in a few hours and got away.

The conclusion is, the more weird/complicated algorithm you employ, the more likely you to run into a trouble with it some day.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: simondlr on April 18, 2014, 10:13:55 AM

The DigiShield algorithm is just asking to be exploited.  The DGW2 algorithm is vulnerable to a timewarp as well.  Almost every single one block difficulty adjustment algorithm contains a flaw with regard to timestamps, and if miners are not mining to secure the network, the coin will be forked.

Absolutely, it seems as if finally somebody understands this.

~BCX~

It seems so. Cheers for the discussion.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Cryddit on April 18, 2014, 03:27:09 PM

 Almost every single one block difficulty adjustment algorithm contains a flaw with regard to timestamps, and if miners are not mining to secure the network, the coin will be forked.

Absolutely, it seems as if finally somebody understands this.


Anything where someone has 51% or more of the hashing power will go down to a 51% attack, of course.

But with timewarp, specifically, doesn't the attacker depend on being able to fool the code that estimates the hashing power in a chain?

If that code were producing an accurate estimate, then it shouldn't matter where you can get the difficulty via timewarp or anything else.



Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Nite69 on April 22, 2014, 08:43:49 PM
One problem with difficulty readjustment is that is is designed to adjust the difficulty based on real block calculation times. It's symmetry causes difficulty to rise exponentially if time difference between blocks approach to zero.

Maybe this kind of symmetry gives better protection against time manipulation? Or is it even worse? (this area is full of mines..).

Code:
unsigned int static QuickRetarget(const CBlockIndex* pindexLast, const CBlock *pblock, uint64 TargetBlocksSpacingSeconds) {
const CBlockIndex  *BlockLastSolved = pindexLast;
const CBlockIndex  *BlockReading = pindexLast->pprev;
if (BlockLastSolved == NULL || (BlockLastSolved->nHeight == 0)) { return bnProofOfWorkLimit.GetCompact(); }

int64 LatestBlockTime = BlockReading->GetBlockTime();
int64 targetTime = LatestBlockTime + TargetBlocksSpacingSeconds;
int64 timeDiff = BlockLastSolved->GetBlockTime() - targetTime;
if (timeDiff == 0) { // no need to change difficulty
return  pindexLast->nBits;
}
CBigNum bnNew;
bnNew.SetCompact(pindexLast->nBits);
if (timeDiff > 0) { // slower, speed up by reducing difficulty -> increase nBits
int64 adjustment = timediff / 4;
// limit max adjustment to half the difficulty
if (adjustment > TargetBlocksSpacingSeconds) adjustment = TargetBlocksSpacingSeconds;
bnNew *= (TargetBlocksSpacingSeconds + adjustment);
bnNew /= (TargetBlocksSpacingSeconds);
} else /* timeDiff < 0 */ { // faster, increase difficulty -> reduce nBits
int64 adjustment = -timediff / 4;
// No need to limit this one
bnNew *= (TargetBlocksSpacingSeconds);
bnNew /= (TargetBlocksSpacingSeconds + adjustment);
}
return bnNew.GetCompact();
}



Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Nite69 on April 22, 2014, 10:11:11 PM

Honestly you guys should quit trying to fix this and switch algo.


~BCX~

:-D Frankly, do you see this as a new desperate attempt to fix something which is not fixable or do you see this as a new algorihtm maybe avoiding some of the flaws previous ones have?

This is basicly dogecoin's digishield with 2 main differences;
1) in dogecoin the reference point is difference between 2 latest block's time. In this algorithm the reference point is difference from the targeted time.
2) this does not limit the maximum adjustment (I think doge limits too much) that much.

Let's assume 10 minute target time and a block generated 1 min after previous, Fundamentally, Digishield (and all other retargets) considers it has been calculated with 10x hashing power and it should basicly increase the difference to 10 times higher (10/1). This algorithm considers it is 9 minutes too early and adjusts the difficulty just the same amount compared to a block which is 9 minutes too late. The adjustment would only be 1+(9/10) = 1.9. 

I must admit that for adjusting the hashing power, digishield is actually more accurate. But is it substantially better? Is this better against random time variance and intentional time manipulation? Does this open some new attack vectors? Maybe?

Downwards the adjustemtn would be the same, 10 times longer calculation times means 1/10 of the difficulty.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Cryddit on April 23, 2014, 12:42:38 AM
You can adjust difficulty every block, but you should take more than one block of history into account when you do.  Here's a simple algorithm for rapid emergency adjustment; you could use this in addition to a periodic fine-tuning adjustment, if you want. 

For a rapid emergency adjustment, look at the five, nine, and seventeen block average times.  If they are *all* too short (say, 3/4 of your desired interval or less) then adjust difficulty 20% upward.  If they are *all* too long (say, 4/3 of your desired interval or more) then adjust difficulty 20% downward.   You can make an adjustment every block, and the miners can lie about block completion times as much as they do now, but it won't be possible for them to drive the difficulty down while getting blocks faster than the interval time. 

Five, Nine, and Seventeen - because none of them divides any other, guaranteeing that no short repeating pattern of timestamp lies exposes a harmonic that will repeatedly allow them all to be mistaken in the same direction at the same time. You could use a different set, or more than three intervals, but whatever.  I'd advise against using something smaller than 5 as your smallest interval, if you're keeping the median-of-last-11-blocks rule.  Also, because although the shortest interval is your reaction time in *stopping* adjustments once the right difficulty level is reached, shortening it also increases the frequency with which natural time variation will stop a needed adjustment from being applied and how often someone lying about blocktimes can deliberately *prevent* a needed adjustment from being applied. 

20% adjustments up  or down because the 6:5 or 4:5 ratios of speed are closer to 1 than the 4:3 or 3:4 ratios that trigger the adjustment - so adjustment is guaranteed to 'damp' automatically rather than entering hysteresis (alternately overshooting in both directions).

When burst miners jump on with massive hashing power, there's a slight delay before the reaction starts as enough too-short intervals build up to 'tip the scales' of the averages.   But then block adjustments start happening *OFTEN,* and there is no pattern of timestamp lies that can do more than slow it down a little bit.  When difficulty reaches the "right" level, the adjustments quickly stop when the shortest interval saturates with appropriate-length blocks, and there is no pattern of timestamp lies that can keep it on average more than one adjustment off of where it's supposed to be.

Likewise when they jump back off again, there's a delay as enough too-long intervals build up to tip the scales of the running averages, but then difficulty adjustments start happening *OFTEN*, and once again there's no pattern of timestamp lies that can do more than slow it down slightly.  Again, when difficulty reaches the "right" level, the adjustments quickly stop because the shortest interval quickly saturates, and there's no pattern of timestamp lies that can hold it more than one adjustment off of where it's supposed to be.

If with any set of timestamp lies you can generate more blocks than the rest of the network with this adjustment algorithm in less time, you're within a few percent of being able to mount a "real" 51% attack anyway. 



Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: astor on April 23, 2014, 11:44:13 AM
You should start with some control theory when adjusting difficulty.

I suggest looking at a Kalman filter first.  It is provably the optimum when the noise is random.  It is just a few multiplications and is easy to implement in a few lines of C.

But at a high level, don't try to write this in a small C function.  You have trillions of clock cycles between blocks, fork out some $$$ and write a decent high level implementation.

Why not add something like liboctave or R to the source code?  Then you could use ready-made implementations of these things.

In order to create a kalman filter, you need to create a model of how the dynamics of the system should behave.  If the goal of the control system is to keep the block output at a fixed rate, then the distance from that rate is the error you want to correct.

In addition to this error, you have a noise generator which represents your inability to control correctly.  The kalman filter will over time adjust and learn the standard deviation for the noise and thus apply the optimum error correction (adjustment to difficulty).

What you generally need to estimate is the correlation matrix between the variables in your model.

You want your underlying model to be as simple as possible, but also as correct as possible.  Some variables in a model could for example be:  the % increase in issued coins by a block, the difficulty, the difficulty error (difference from ideal inter-block time), the estimated hashing power of the network (which requires a separate model to estimate), the relative exchange value wrt bitcoin, etc.

You also need to estimate the correlation matrix between these variables, but this is mostly to make the filter more efficient.  You can set the correlations to 0 if you want.


A last point I want to make is that hard forks are not bad.  It has been shown again and again that bitcoin does not solve distributed consensus.  Both because the amount of computing power is unknown, and more politically because hashing power is already too concentrated.  Changing the algorithm on a deployed coin is something the users/developers of the coins control, not the miners, unlike what people tend to believe.  It doesn't matter how much hashing power an attacker has if he refuses to run the same algorithm as the users of a coin requires.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: x_static on April 25, 2014, 08:24:08 PM
I invite you all to smack around Dobbscoin a.k.a. BOB, some.  It also uses KGW, has the fix in the OP applied, but it's running some settings we like to call BOB's Wormh0le, with a much smaller event horizon window.  Not intended to be the be all end all answer...  It's still KGW.  But putting something a little different out there, that we might be able to learn from.  Yeah, there is practically no hash on the coin, so it won't take much to hammer it, so try not to hit it too hard and just shatter it.  Though, at the end of the day, we're not trippin.  Checkpoint, increment versions, rebuild, release...  It'd be nicer if you didn't try to completely ruin the fun for everyone.  I'm thinking we're most susceptible to a difficulty walkup.  Haven't really tested it.  Figure some of you all might be better equipped to accomplish the task of exposing flaws with excellence.  BTCBob will probably get mad at me for posting this.  But hey...  Anyone down to hammer the h0le?  Heh heh...  Them other Bobbies will probably freak out if they see some huge diff spikes... LOL

Dobbscoin Homepage (http://dobbscoin.info)

Latest Dobbscoin Release (https://github.com/dobbscoin/dobbscoin-source/releases)

Dobbscoin Source (https://github.com/dobbscoin/dobbscoin-source)

Dobbscoin Block Explorer (http://explorer.dobbscoin.info/chain/Dobbscoin?count=100&hi=13801) (might be interesting to compare to Auroracoin (http://blockexplorer.auroracoin.eu/chains) block explorer)

Dobbscoin Home Pool (http://pool.dobbscoin.info)

Dobbscoin SMF (http://dobbscoin.info/smf)

#dobbscoin on FreeNode

P.S.  Though BOB has Coingen roots, Testnet does work.  So that's always an option.  Though the seed node can be wonky at times.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: ghostlander on April 27, 2014, 09:51:41 AM
Been looking for a decent replacement to the PPC every block retarget algorithm. KGW, DGW, DigiShield, whatever else does no good. Have got the job done myself finally.

https://github.com/ghostlander/Orbitcoin/blob/1e417b40a65dc316037855b1d3db3b32165c80db/src/main.cpp#L1157

Re-targets every block with separate fixed targets for PoW and PoS. Two averaging windows (short of 5 blocks and long of 20 blocks), both are limited against time warping. Interwindow averaging and 0.25 damping with the final +1% / -2% difficulty limiting. Runs fine so far.


Quote
P.S.  Though BOB has Coingen roots, Testnet does work.  So that's always an option.  Though the seed node can be wonky at times.

OMFG, this Bobcoin spam is now here at Bitcointalk. This annoying Coingen nonsense will get killed some day. The sooner is the better.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: x_static on April 28, 2014, 06:51:09 PM
Been looking for a decent replacement to the PPC every block retarget algorithm. KGW, DGW, DigiShield, whatever else does no good. Have got the job done myself finally.

https://github.com/ghostlander/Orbitcoin/blob/1e417b40a65dc316037855b1d3db3b32165c80db/src/main.cpp#L1157

Re-targets every block with separate fixed targets for PoW and PoS. Two averaging windows (short of 5 blocks and long of 20 blocks), both are limited against time warping. Interwindow averaging and 0.25 damping with the final +1% / -2% difficulty limiting. Runs fine so far.


Quote
P.S.  Though BOB has Coingen roots, Testnet does work.  So that's always an option.  Though the seed node can be wonky at times.

OMFG, this Bobcoin spam is now here at Bitcointalk. This annoying Coingen nonsense will get killed some day. The sooner is the better.


LOL, this from the guy who can't even compile a release quality wallet (http://phoenixcoin.org/downloads/orbitcoin-win-1.4.1.0.zip).  DLL's included in the Zip for your pleasure, right?  LOL

Over at Dobbscoin, we release a full compliment of Wallets with each update.  Built to Bitcoin standards.  Not this frankenstein build system built, windows wallet only garbage that you and Shakezula seem to have pioneered.  You and your cult of crapcoin are the ones who will be dying off soon.

After a quick look at your Orbitcoin block explorer, it would appear your coin generation is all over the place.  Nowhere in the realm of where they should be for what you claim the targets are.  For PoS or PoW.

P.S. To BCX and other "testers"...  Orbitcoin is most definitely worthy of annihilation...  Feel free to hit Dobbscoin just as hard...


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: ghostlander on April 29, 2014, 12:25:42 PM
LOL, this from the guy who can't even compile a release quality wallet (http://phoenixcoin.org/downloads/orbitcoin-win-1.4.1.0.zip).  DLL's included in the Zip for your pleasure, right?  LOL

libstdc++ and libgcc_s_dw2 are regular 32-bit MinGW runtimes, no real need to compile them in. In fact, this executable has even these two compiled in after a project file update. All other non-system dependencies are also built in. A cheap insult, piss off.

Quote
Over at Dobbscoin, we release a full compliment of Wallets with each update.  Built to Bitcoin standards.  Not this frankenstein build system built, windows wallet only garbage that you and Shakezula seem to have pioneered.  You and your cult of crapcoin are the ones who will be dying off soon.

Blah-blah-blah. If no one in the community needs Mac or Linux or Plan 9 or whatever binaries, why am I supposed to deliver these? Come back to the real world where over 90% are Windows users and most Linux users can build Qt clients & daemons themselves. Feel proud of being a Mac user? Most of the others don't give a shit.

Quote
After a quick look at your Orbitcoin block explorer, it would appear your coin generation is all over the place.  Nowhere in the realm of where they should be for what you claim the targets are.  For PoS or PoW.

Really? Feel free to tell me more about coin generation, make my day.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: x_static on April 29, 2014, 05:00:18 PM
libstdc++ and libgcc_s_dw2 are regular 32-bit MinGW runtimes, no real need to compile them in. In fact, this executable has even these two compiled in after a project file update. All other non-system dependencies are also built in. A cheap insult, piss off.

Actually, those are the MinGW Versions of standard GNU C & C++ runtime libraries.  32-bit, 64 bit, I don't know...  Your wallet ran on a neither my Windows XP or 64-bit Windows 7 VM's.  Fail!  Rather than adapting the project file to conform to your non-compliant build system(breaking the build for others in the process), you should be editing your command lines used to invoke qmake & make, to accomplish the task of statically compiling binaries.  Valid criticism is not a cheap insult.  It would seem you started the insults, so maybe you should piss off.

Quote
Blah-blah-blah. If no one in the community needs Mac or Linux or Plan 9 or whatever binaries, why am I supposed to deliver these? Come back to the real world where over 90% are Windows users and most Linux users can build Qt clients & daemons themselves. Feel proud of being a Mac user? Most of the others don't give a shit.

You need to come back to the real world, where people like options.  Stop making excuses for why you can't build to Bitcoin standards.

Quote
Really? Feel free to tell me more about coin generation, make my day.

Failed comeback.  Vague response.  You sound like a little child.  Game over.  This was actually a quite informative, leading edge thread on the subject of difficulty retargeting algorithms until you popped in and sullied it with your stench.  If you want to continue taking it on the head, we hash this out over on CCT.  No more cluttering this thread with your BS.   


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: YarkoL on April 29, 2014, 05:07:01 PM
This was actually a quite informative, leading edge thread on the subject of difficulty retargeting algorithms until you popped in and sullied it with your stench. 

Yes, and ghostlander has a number of quality contribution to the thread.

How about you doing the same?


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: x_static on April 29, 2014, 07:44:01 PM
This was actually a quite informative, leading edge thread on the subject of difficulty retargeting algorithms until you popped in and sullied it with your stench.

Yes, and ghostlander has a number of quality contribution to the thread.

How about you doing the same?

My first post doesn't count?  Default KGW is a coin fountain.  You don't even need to exploit it.  Just throw hash at the coin, and it starts spitting blocks out.  Grab about 40 - 50 blocks in a couple minutes, then take your hash elsewhere.  Simple as that.  BOB's Wormhole addresses that issue.  Does it create more problems than it addresses?  That's why I posted here for review.  Did I choose KGW for Dobbscoin?  No.  Another member of the Dobbscoin crew approached Shakezula on the subject of difficulty retarget algorithms, and he put together this commit (https://github.com/dobbscoin/dobbscoin-source/commit/093ddca7f93e02988254150808ba739630487c9f), which with settings like "PastSecondsMin = TimeDaySeconds * 2.5;" was sure to turn Dobbscoin into a coin fountain.  Not to mention that he failed to address the fact that Dobbscoin has a working testnet.  BOB's Wormhole is KGW tuned to a 10 minute block target, with a much smaller event horizon window.  Settings like no one else is running.  Put forth in this thread to be scrutinized.  I personally think KGW sucks.  The Wormhole IMO being the best implementation out.  I'll take clamping over coin fountain, any day.  Especially with a 10 minute block target, on a coin that isn't meant for speculators.  Maybe look at my commit history for Dobbscoin, and learn how to make a Coingen coin better than most of whats out right now.

I invite you all to smack around Dobbscoin a.k.a. BOB, some.  It also uses KGW, has the fix in the OP applied, but it's running some settings we like to call BOB's Wormh0le, with a much smaller event horizon window.  Not intended to be the be all end all answer...  It's still KGW.  But putting something a little different out there, that we might be able to learn from.  Yeah, there is practically no hash on the coin, so it won't take much to hammer it, so try not to hit it too hard and just it.  Though, at the end of the day, we're not trippin.  Checkpoint, increment versions, rebuild, release...  It'd be nicer if you didn't try to completely ruin the fun for everyone.  I'm thinking we're most susceptible to a difficulty walkup.  Haven't really tested it.  Figure some of you all might be better equipped to accomplish the task of exposing flaws with excellence.  BTCBob will probably get mad at me for posting this.  But hey...  Anyone down to hammer the h0le?  Heh heh...  Them other Bobbies will probably freak out if they see some huge diff spikes... LOL

Dobbscoin Homepage (http://dobbscoin.info)

Latest Dobbscoin Release (https://github.com/dobbscoin/dobbscoin-source/releases)

Dobbscoin Source (https://github.com/dobbscoin/dobbscoin-source)

Dobbscoin Block Explorer (http://explorer.dobbscoin.info/chain/Dobbscoin?count=100&hi=13801) (might be interesting to compare to Auroracoin (http://blockexplorer.auroracoin.eu/chains) block explorer)

Dobbscoin Home Pool (http://pool.dobbscoin.info)

Dobbscoin SMF (http://dobbscoin.info/smf)

#dobbscoin on FreeNode

P.S.  Though BOB has Coingen roots, Testnet does work.  So that's always an option.  Though the seed node can be wonky at times.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: x_static on April 30, 2014, 01:58:35 AM
So, lets have a gander at Auroracoin Block Explorer to prove a point I made in my post right above this, about how default KGW sucks and is a coin fountain.

Lets look at the two most recent groups, of 100 blocks.  With a 5 minute block target, we should average 12 blocks per hour, taking about 8 hours & 20 minutes to generate 100 blocks.

14532   2014-04-29 08:34:53   10   diff 122.244
to
14631   2014-04-29 19:26:02   4   diff 109.553

Just shy of 11 hours to generate the above 100 blocks.  Over a 100 block period, I'd really hope that I'd be reasonably close to being on target time wise.  2.5 hours off is significant.  But lets look at the last 100.

14632   2014-04-29 19:36:12   7   diff 109.722
to
14731   2014-04-29 23:38:07   7   diff 134.433

100 blocks in 4 hours.  That is a huge swing, and what I like to call "clumping".  Which what default KGW is prone to, because its looking at a huge window, and not reacting fast enough to whats going on "right now". But look at the block 14731, right before the diff hit 134.433.

14730   2014-04-29 23:29:39   2   diff 118.773

So, 99 blocks to go from a difficulty of 109 to 118, then bam.  Finally it decides enough is enough.  But wait...  I just notice this...

14590   2014-04-29 15:34:26   22   diff 117.466
14591   2014-04-29 15:40:09   5   diff 114.095
14592   2014-04-29 18:18:58   33   diff 114.132
14593   2014-04-29 18:19:41   1   diff 71.654

With difficulty dropping, 14592 was a 2 hour and 40 minute block.  14593, difficulty dropped to 71!  Here is where the coin fountain kicked in. In a matter of 5 hours and 20 minutes, 139 blocks were generated.  Remarkably close to the 144 block minimum window standard KGW looks at. 

14592   2014-04-29 18:18:58   33   diff 114.132
14617   2014-04-29 18:23:37   1   diff 107.076

The first 25 block of this fast period were stripped off in 5 minutes!!!  25 blocks in the period that only 1 was supposed to be generated.  Crazy stuff...  KGW sucks...  Was this an attack, or just bad luck that prompted this crazy swing?  I think you can just chock it up to KGW sucking badly in stock form with that 144 block minimum window.  Yes, if you add up all the blocks over time since KGW has kicked in, you might be near your block generation target.  But no matter how bad of luck you run into, 25 blocks in 5 minutes is unacceptable.   Bad luck is bad luck, no one should be rewarded like that for it.  Those blocks should just be lost is it was that bad.  This scares me more than time warp, because it will happen under just normal operating conditions.

Those running KGW might want to take a look and my commit for BOB's Wormhole, and possibly adapt it to their own coin, if they still plan to keep it KGW.  That is if no one finds its flaws are worse than stock.
BOB's Wormh0le - Kimoto Gravity Well Customization (https://github.com/dobbscoin/dobbscoin-source/commit/aadc2a596eb59add12ca933bbecf1f3ad52db043)


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: YarkoL on April 30, 2014, 07:56:56 AM
So, lets have a gander at Auroracoin Block Explorer to prove a point I made in my post right above this, about how default KGW sucks and is a coin fountain.


That was refreshingly hands-on approach, thank you.
Indeed, making charts like these serves as a great introduction to this sometimes abtruse subject.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: ghostlander on April 30, 2014, 10:10:28 AM
Those running KGW might want to take a look and my commit for BOB's Wormhole, and possibly adapt it to their own coin, if they still plan to keep it KGW.  That is if no one finds its flaws are worse than stock.
BOB's Wormh0le - Kimoto Gravity Well Customization (https://github.com/dobbscoin/dobbscoin-source/commit/aadc2a596eb59add12ca933bbecf1f3ad52db043)

This glorious patch has changed 2 lines of the actual code to make it fit your very slow coin and 1 more line to narrow event horizons. Now, it's surely the greatest thing since tinned beer. Or not? It's still KGW and it's still broken, time warping not fixed, but you don't get it anyway because you haven't cared to read this thread from the start before posting your advertising spam.  ::)


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: x_static on April 30, 2014, 09:20:35 PM
Those running KGW might want to take a look and my commit for BOB's Wormhole, and possibly adapt it to their own coin, if they still plan to keep it KGW.  That is if no one finds its flaws are worse than stock.
BOB's Wormh0le - Kimoto Gravity Well Customization (https://github.com/dobbscoin/dobbscoin-source/commit/aadc2a596eb59add12ca933bbecf1f3ad52db043)

This glorious patch has changed 2 lines of the actual code to make it fit your very slow coin and 1 more line to narrow event horizons. Now, it's surely the greatest thing since tinned beer. Or not? It's still KGW and it's still broken, time warping not fixed, but you don't get it anyway because you haven't cared to read this thread from the start before posting your advertising spam.  ::)


Nice, you confirm some of my previous statements, but you obviously are guilty of what you assume I've done.  Which is not read this thread.  It's time to stop talking and backup your claims.  TimeWarp BOB.  I DARE YEW!!!   :o


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: thaReal on May 12, 2014, 04:10:04 PM
hey so I just stumbled on this thread - I've been researching an alternative form of a "KGW" type of difficulty readjustment (for simplicity). So I'm glad to start finally seeing comments like those from Cryddit and astor - I think we really need to do more research and work on developing a much better designed difficulty adjustment algo rather than simply trying to 'tune' an already flawed one. I'm not too sure about "bob's wormhole", but I'll definitely look into it as this is the first I've heard of it. That being said though, I think that in general there seems to be a huge fundamental misunderstanding on what this algorithm does and how it functions so before trying to create something new, I think a little better analysis needs to be done.

I think this excerpt from astor's post is probably the most accurate thing I've seen written on moving forward to date:

"In order to create a kalman filter, you need to create a model of how the dynamics of the system should behave.  If the goal of the control system is to keep the block output at a fixed rate, then the distance from that rate is the error you want to correct."

Also, I wanted to post on this thread because of the quality of these comments, but I do agree that this shouldn't really have anything to do with auroracoin specifically - so are there any legitimate threads that attempt to delve into this from a mathematical perspective elsewhere on this forum or should one be created?


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: btcdrak on May 12, 2014, 04:15:59 PM
hey so I just stumbled on this thread - I've been researching an alternative form of a "KGW" type of difficulty readjustment (for simplicity). So I'm glad to start finally seeing comments like those from Cryddit and astor - I think we really need to do more research and work on developing a much better designed difficulty adjustment algo rather than simply trying to 'tune' an already flawed one. I'm not too sure about "bob's wormhole", but I'll definitely look into it as this is the first I've heard of it. That being said though, I think that in general there seems to be a huge fundamental misunderstanding on what this algorithm does and how it functions so before trying to create something new, I think a little better analysis needs to be done.

I think this excerpt from astor's post is probably the most accurate thing I've seen written on moving forward to date:

"In order to create a kalman filter, you need to create a model of how the dynamics of the system should behave.  If the goal of the control system is to keep the block output at a fixed rate, then the distance from that rate is the error you want to correct."

Also, I wanted to post on this thread because of the quality of these comments, but I do agree that this shouldn't really have anything to do with auroracoin specifically - so are there any legitimate threads that attempt to delve into this from a mathematical perspective elsewhere on this forum or should one be created?

Look at Dark Gravity Wave which came as a result of KGW's timewarp exploit and post what you think about it. You can find it in the DarkCoin source.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Nite69 on May 12, 2014, 04:28:09 PM
Also, I wanted to post on this thread because of the quality of these comments, but I do agree that this shouldn't really have anything to do with auroracoin specifically - so are there any legitimate threads that attempt to delve into this from a mathematical perspective elsewhere on this forum or should one be created?

https://bitcointalk.org/index.php?topic=505243.0


Edit: Actually I think that digishield is better for diff retarget than my suggestion here.. but I think one should bring ideas to common knowledge, even if they are not as good as the pervious ones.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Cryddit on May 13, 2014, 02:52:03 AM
Here.  

No timewarp.  Rapid adjustments when a burst miner jumps on or off.  And an experimental feature, adjusts the block interval to keep the blockchain height consistent (in the long run, and approximately...) with the wall clock.

Adjusts difficulty potentially every block, based on average block intervals observed within the last 17 blocks.  

Have fun with it.

Code:

// Bitcoin used 10-minute blocks; this uses six minute blocks.
static const int64_t nTargetSpacing = 6 * 60;  // seconds per block, nominal.
static const int64_t nFastInterval = nTargetSpacing * 0.95; // seconds per block desired when behind schedule
static const int64_t nSlowInterval = nTargetSpacing * 1.05; // seconds per block desired when ahead of schedule
static const int64_t nTimeZero = 1400000000; // nominal date at which this blockchain starts, since unix epoch


void avgRecentTimestamps(const CBlockIndex* pindexLast, int64_t *avgOf5, int64_t *avgOf7, int64_t *avgOf9, int64_t *avgOf17)
{
  int blockoffset = 0;
  int64_t oldblocktime;
  int64_t blocktime;

  *avgOf5 = *avgOf7 = *avgOf9 = *avgOf17 = 0;
  if (pindexLast)
    blocktime = pindexLast->GetBlockTime();
  else blocktime = 0;

  for (blockoffset = 0; blockoffset < 18; blockoffset++)
  {
    oldblocktime = blocktime;
    if (pindexLast)
    {
      pindexLast = pindexLast->pprev;
      blocktime = pindexLast->GetBlockTime();
    }
    else
    { // genesis block or previous
      blocktime -= nTargetSpacing;
    }
    // for each block, add interval.
    if (blockoffset <= 5) *avgOf5 += (oldblocktime - blocktime);
    if (blockoffset <= 7) *avgOf7 += (oldblocktime - blocktime);
    if (blockoffset <= 9) *avgOf9 += (oldblocktime - blocktime);
    *avgOf17 += (oldblocktime - blocktime);    
  }
  // now we have the sums of the block intervals. Division gets us the averages.
  *avgOf5 /= 5;
  *avgOf7 /= 7;
  *avgOf9 /= 9;
  *avgOf17 /= 17;
}



// This is a novel getnextwork algorithm.  It responds quickly to huge changes in hashing power, is immune to time warp
// attacks, and regulates the block rate to keep the block height close to the block height expected given the nominal
// block interval and the elapsed time.  How close the correspondence between block height and wall clock time is
// depends on how stable the hashing power has been.

unsigned int GetNextWorkRequired(const CBlockIndex* pindexLast, const CBlockHeader *pblock)
{
    int64_t avgOf5;
    int64_t avgOf9;
    int64_t avgOf7;
    int64_t avgOf17;
    int64_t toofast;
    int64_t tooslow;
    int64_t difficultyfactor = 10000;
    int64_t now;
    int64_t BlockHeightTime;
    int64_t nIntervalDesired;

    unsigned int nProofOfWorkLimit = Params().ProofOfWorkLimit().GetCompact();

    if (pindexLast == NULL)
        // Genesis Block
        return nProofOfWorkLimit;

    
    if (TestNet())
    {
        // Special difficulty rule for testnet: If the new block's timestamp is more than 2* 10 minutes then allow
        // mining of a min-difficulty block.
        if (pblock->nTime > pindexLast->nTime + nTargetSpacing*2)
           return nProofOfWorkLimit;
        else
        {
            // Return the last non-special-min-difficulty-rules-block
           const CBlockIndex* pindex = pindexLast;
           while (pindex->pprev && pindex->nHeight % nInterval != 0 && pindex->nBits == nProofOfWorkLimit)
               pindex = pindex->pprev;
           return pindex->nBits;
        }
    }

    // Regulate block times so as to remain synchronized in the long run with the actual time.  The first step is to
    // calculate what interval we want to use as our regulatory goal.  It depends on how far ahead of (or behind)
    // schedule we are.  If we're more than a day ahead or behind, we use the maximum (nSlowInterval) or minimum
    // (nFastInterval) values; otherwise we calculate a weighted average somewhere in between them.  The closer we are
    // to being exactly on schedule the closer our selected interval will be to our nominal interval (nTargetSpacing).

    now = pindexLast->GetBlockTime();
    BlockHeightTime = nTimeZero + pindexLast->nHeight * nTargetSpacing;
    
    if (now < BlockHeightTime + 86400 && now > BlockHeightTime )  // ahead of schedule by less than a day.
      nIntervalDesired = ((86400 - (now - BlockHeightTime)) * nTargetSpacing +  
(now - BlockHeightTime) * nFastInterval) / 86400;
    else if (now + 86400 > BlockHeightTime && now < BlockHeightTime)  // behind schedule by less than a day.
      nIntervalDesired = ((86400 - (BlockHeightTime - now)) * nTargetSpacing +
(BlockHeightTime - now) * nSlowInterval) / 86400;
    else if (now < BlockHeightTime) nIntervalDesired = nSlowInterval; // ahead by more than a day.
    else  nIntervalDesired = nFastInterval; // behind by more than a day.
    
    // find out what average intervals over last 5, 7, 9, and 17 blocks have been.
    avgRecentTimestamps(pindexLast, &avgOf5, &avgOf7, &avgOf9, &avgOf17);    



    // check for emergency adjustments. These are to bring the diff up or down FAST when a burst miner or multipool
    // jumps on or off.  Once they kick in they can adjust difficulty by a factor of nine or ten every ten blocks, and
    // they can kick in very rapidly after massive hash power jumps on or off.  The emergency speed-up adjustment uses
    // shorter intervals for quicker reaction times measured in blocks - which when it's needed will be longer in
    // minutes.

    toofast = (nIntervalDesired * 3) / 4;
    tooslow = (nIntervalDesired * 4) / 3;    

    if (avgOf7 < toofast && avgOf9 < toofast && avgOf17 < toofast)
    {  //emergency adjustment, slow down
      difficultyfactor *= 5;
      difficultyfactor /= 4;
    }
    else if (avgOf5 > tooslow && avgOf7 > tooslow && avgOf9 > tooslow)
    {  //emergency adjustment, speed up
      difficultyfactor *= 4;
      difficultyfactor /= 5;
    }

    // If no emergency adjustment, check for normal adjustment.
    else if ((avgOf7 > nIntervalDesired && avgOf9 > nIntervalDesired && avgOf17 > nIntervalDesired) ||
    (avgOf7 < nIntervalDesired && avgOf9 < nIntervalDesired && avgOf17 < nIntervalDesired))
    { // 3 averages too high or 3 too low.  Doesn't matter which. This will be executed occasionally on the basis of
      // random variation, even if the settings are perfect. It regulates one-fifth of the way to the calculated point.
      difficultyfactor *= (5 * nIntervalDesired);
      difficultyfactor /= (avgOf17 + (4 * nIntervalDesired));
    }

    // limit to doubling or halving.... though I'm pretty sure there are no realistic conditions where this will make a
    // difference.
    if (difficultyfactor > 20000) difficultyfactor = 20000;
    if (difficultyfactor < 5000) difficultyfactor = 5000;

    uint256 bnNew;
    uint256 bnOld;

    bnOld.SetCompact(pindexLast->nBits);

    if (difficultyfactor == 10000) // no adjustment
      return(bnOld.GetCompact());

    bnNew = bnOld * 10000;
    bnNew /= difficultyfactor;

    if (bnNew > Params().ProofOfWorkLimit())
      bnNew = Params().ProofOfWorkLimit();

    LogPrintf("GetNextWorkRequired RETARGET\n");
    LogPrintf("Actual time %d, Scheduled time for this block height = %d\n", now, BlockHeightTime );
    LogPrintf("Nominal block interval = %d, regulating on interval %d to get back to schedule.\n",
     nTargetSpacing, nIntervalDesired );
    LogPrintf("Avg intervals of last 5/9/17 blocks = %d / %d / %d.\n", nTargetSpacing, avgOf5, avgOf9, avgOf17);
    LogPrintf("Difficulty Before Adjustment: %08x  %s\n", pindexLast->nBits, bnOld.ToString());
    LogPrintf("Difficulty After Adjustment:  %08x  %s\n", bnNew.GetCompact(), bnNew.ToString());

    return bnNew.GetCompact();
}


This tends to overshoot a little when making emergency adjustments, but it self-corrects within a dozen blocks or so when it does.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: thaReal on May 13, 2014, 05:06:32 PM
Here.  

No timewarp.  Rapid adjustments when a burst miner jumps on or off.  And an experimental feature, adjusts the block interval to keep the blockchain height consistent (in the long run, and approximately...) with the wall clock.

Adjusts difficulty potentially every block, based on average block intervals observed within the last 17 blocks.  

Have fun with it.

Code:

// Bitcoin used 10-minute blocks; this uses six minute blocks.
static const int64_t nTargetSpacing = 6 * 60;  // seconds per block, nominal.
static const int64_t nFastInterval = nTargetSpacing * 0.95; // seconds per block desired when behind schedule
static const int64_t nSlowInterval = nTargetSpacing * 1.05; // seconds per block desired when ahead of schedule
static const int64_t nTimeZero = 1400000000; // nominal date at which this blockchain starts, since unix epoch


void avgRecentTimestamps(const CBlockIndex* pindexLast, int64_t *avgOf5, int64_t *avgOf7, int64_t *avgOf9, int64_t *avgOf17)
{
  int blockoffset = 0;
  int64_t oldblocktime;
  int64_t blocktime;

  *avgOf5 = *avgOf7 = *avgOf9 = *avgOf17 = 0;
  if (pindexLast)
    blocktime = pindexLast->GetBlockTime();
  else blocktime = 0;

  for (blockoffset = 0; blockoffset < 18; blockoffset++)
  {
    oldblocktime = blocktime;
    if (pindexLast)
    {
      pindexLast = pindexLast->pprev;
      blocktime = pindexLast->GetBlockTime();
    }
    else
    { // genesis block or previous
      blocktime -= nTargetSpacing;
    }
    // for each block, add interval.
    if (blockoffset <= 5) *avgOf5 += (oldblocktime - blocktime);
    if (blockoffset <= 7) *avgOf7 += (oldblocktime - blocktime);
    if (blockoffset <= 9) *avgOf9 += (oldblocktime - blocktime);
    *avgOf17 += (oldblocktime - blocktime);    
  }
  // now we have the sums of the block intervals. Division gets us the averages.
  *avgOf5 /= 5;
  *avgOf7 /= 7;
  *avgOf9 /= 9;
  *avgOf17 /= 17;
}



// This is a novel getnextwork algorithm.  It responds quickly to huge changes in hashing power, is immune to time warp
// attacks, and regulates the block rate to keep the block height close to the block height expected given the nominal
// block interval and the elapsed time.  How close the correspondence between block height and wall clock time is
// depends on how stable the hashing power has been.

unsigned int GetNextWorkRequired(const CBlockIndex* pindexLast, const CBlockHeader *pblock)
{
    int64_t avgOf5;
    int64_t avgOf9;
    int64_t avgOf7;
    int64_t avgOf17;
    int64_t toofast;
    int64_t tooslow;
    int64_t difficultyfactor = 10000;
    int64_t now;
    int64_t BlockHeightTime;
    int64_t nIntervalDesired;

    unsigned int nProofOfWorkLimit = Params().ProofOfWorkLimit().GetCompact();

    if (pindexLast == NULL)
        // Genesis Block
        return nProofOfWorkLimit;

    
    if (TestNet())
    {
        // Special difficulty rule for testnet: If the new block's timestamp is more than 2* 10 minutes then allow
        // mining of a min-difficulty block.
        if (pblock->nTime > pindexLast->nTime + nTargetSpacing*2)
           return nProofOfWorkLimit;
        else
        {
            // Return the last non-special-min-difficulty-rules-block
           const CBlockIndex* pindex = pindexLast;
           while (pindex->pprev && pindex->nHeight % nInterval != 0 && pindex->nBits == nProofOfWorkLimit)
               pindex = pindex->pprev;
           return pindex->nBits;
        }
    }

    // Regulate block times so as to remain synchronized in the long run with the actual time.  The first step is to
    // calculate what interval we want to use as our regulatory goal.  It depends on how far ahead of (or behind)
    // schedule we are.  If we're more than a day ahead or behind, we use the maximum (nSlowInterval) or minimum
    // (nFastInterval) values; otherwise we calculate a weighted average somewhere in between them.  The closer we are
    // to being exactly on schedule the closer our selected interval will be to our nominal interval (nTargetSpacing).

    now = pindexLast->GetBlockTime();
    BlockHeightTime = nTimeZero + pindexLast->nHeight * nTargetSpacing;
    
    if (now < BlockHeightTime + 86400 && now > BlockHeightTime )  // ahead of schedule by less than a day.
      nIntervalDesired = ((86400 - (now - BlockHeightTime)) * nTargetSpacing +  
(now - BlockHeightTime) * nFastInterval) / 86400;
    else if (now + 86400 > BlockHeightTime && now < BlockHeightTime)  // behind schedule by less than a day.
      nIntervalDesired = ((86400 - (BlockHeightTime - now)) * nTargetSpacing +
(BlockHeightTime - now) * nSlowInterval) / 86400;
    else if (now < BlockHeightTime) nIntervalDesired = nSlowInterval; // ahead by more than a day.
    else  nIntervalDesired = nFastInterval; // behind by more than a day.
    
    // find out what average intervals over last 5, 7, 9, and 17 blocks have been.
    avgRecentTimestamps(pindexLast, &avgOf5, &avgOf7, &avgOf9, &avgOf17);    



    // check for emergency adjustments. These are to bring the diff up or down FAST when a burst miner or multipool
    // jumps on or off.  Once they kick in they can adjust difficulty by a factor of nine or ten every ten blocks, and
    // they can kick in very rapidly after massive hash power jumps on or off.  The emergency speed-up adjustment uses
    // shorter intervals for quicker reaction times measured in blocks - which when it's needed will be longer in
    // minutes.

    toofast = (nIntervalDesired * 3) / 4;
    tooslow = (nIntervalDesired * 4) / 3;    

    if (avgOf7 < toofast && avgOf9 < toofast && avgOf17 < toofast)
    {  //emergency adjustment, slow down
      difficultyfactor *= 5;
      difficultyfactor /= 4;
    }
    else if (avgOf5 > tooslow && avgOf7 > tooslow && avgOf9 > tooslow)
    {  //emergency adjustment, speed up
      difficultyfactor *= 4;
      difficultyfactor /= 5;
    }

    // If no emergency adjustment, check for normal adjustment.
    else if ((avgOf7 > nIntervalDesired && avgOf9 > nIntervalDesired && avgOf17 > nIntervalDesired) ||
    (avgOf7 < nIntervalDesired && avgOf9 < nIntervalDesired && avgOf17 < nIntervalDesired))
    { // 3 averages too high or 3 too low.  Doesn't matter which. This will be executed occasionally on the basis of
      // random variation, even if the settings are perfect. It regulates one-fifth of the way to the calculated point.
      difficultyfactor *= (5 * nIntervalDesired);
      difficultyfactor /= (avgOf17 + (4 * nIntervalDesired));
    }

    // limit to doubling or halving.... though I'm pretty sure there are no realistic conditions where this will make a
    // difference.
    if (difficultyfactor > 20000) difficultyfactor = 20000;
    if (difficultyfactor < 5000) difficultyfactor = 5000;

    uint256 bnNew;
    uint256 bnOld;

    bnOld.SetCompact(pindexLast->nBits);

    if (difficultyfactor == 10000) // no adjustment
      return(bnOld.GetCompact());

    bnNew = bnOld * 10000;
    bnNew /= difficultyfactor;

    if (bnNew > Params().ProofOfWorkLimit())
      bnNew = Params().ProofOfWorkLimit();

    LogPrintf("GetNextWorkRequired RETARGET\n");
    LogPrintf("Actual time %d, Scheduled time for this block height = %d\n", now, BlockHeightTime );
    LogPrintf("Nominal block interval = %d, regulating on interval %d to get back to schedule.\n",
     nTargetSpacing, nIntervalDesired );
    LogPrintf("Avg intervals of last 5/9/17 blocks = %d / %d / %d.\n", nTargetSpacing, avgOf5, avgOf9, avgOf17);
    LogPrintf("Difficulty Before Adjustment: %08x  %s\n", pindexLast->nBits, bnOld.ToString());
    LogPrintf("Difficulty After Adjustment:  %08x  %s\n", bnNew.GetCompact(), bnNew.ToString());

    return bnNew.GetCompact();
}


This tends to overshoot a little when making emergency adjustments, but it self-corrects within a dozen blocks or so when it does.


Cryydit - you sir, are my hero. ;D This was exactly what I was looking for, just never imagined that I'd get such a straightforward response in one day in three replies lol - that's a bit unheard around here. 

But in all seriousness, it seems like you've actually put some thought into the solution rather than just adjusted a few constants in KGW. I just read through the code and comments and I need to actually do a bit of simulation on the numbers you gave, but it definitely seems in line with what i was working on. Also, the few back of the envelope calculations I did on mathematically how to implement a more efficient system required an underdamped response in order to be effective at large 2nd order changes (i.e. multipool hashrate increases) and thus would tend to overshoot also, so the fact that you mentioned that specifically as well already gives me some indication that you had a similar perspective as me when designing it.

Thank you again for your help - I want to spend some time working on this, but if I make any significant progress / improvements, I'll most definitely let you know. Glad to finally hear from someone that seems to have made some of the same observations as I have about the current attempts at diff re-targetting.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Nite69 on May 13, 2014, 06:04:34 PM
Code:
  for (blockoffset = 0; blockoffset < 18; blockoffset++)
  {
    oldblocktime = blocktime;
    if (pindexLast)
    {
      pindexLast = pindexLast->pprev;
      blocktime = pindexLast->GetBlockTime();
    }
    else
    { // genesis block or previous
      blocktime -= nTargetSpacing;
    }
    // for each block, add interval.
    if (blockoffset <= 5) *avgOf5 += (oldblocktime - blocktime);
    if (blockoffset <= 7) *avgOf7 += (oldblocktime - blocktime);
    if (blockoffset <= 9) *avgOf9 += (oldblocktime - blocktime);
    *avgOf17 += (oldblocktime - blocktime);    
  }


You are actually counting 6,8,10 and 18 averages (imagine <=1; you would count with 0 and 1, guess it's a typo), but otherwise very interesting algo.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Nite69 on May 13, 2014, 06:38:05 PM
And an experimental feature, adjusts the block interval to keep the blockchain height consistent (in the long run, and approximately...) with the wall clock.


About this; I think it might open a vulnerability, but not sure, please confirm or bust. Scenario:

Attacker can generate a block chain in isolated environment which is constantly 'in the future', so targettime will be shorter than official. When that is the situation, attacker can generate more blocks/timespan with the same hahsing power than the official blockchain.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Cryddit on May 13, 2014, 06:53:07 PM
Hey, you're welcome.  But it isn't really a miraculous direct and immediate response to you; you just happened to arrive in the thread a few moments before I would have posted it anyway.  

If you read back in the thread you'll see that this is essentially what I said at the top of the last page, except I restated it in C++ because people were ignoring it when I said in English.  

Also, if you keep reading back, you'll see BCX's observation a few posts earlier than that, when he observed that we needed to implement something with a fundamentally different idea rather than trying to fix the fatal flaw in KGW.  He was absolutely right, so I did.

Honestly, KGW (and DGW) are slightly broken.  Aside from the Time Warp exploit, they work okay, and they have the virtue of reacting to rapid hash rate changes rapidly, but they can't tell the difference between a genuine increase in hash rate and the natural randomness of a Poisson process.  Mining is a Poisson process; when hash rate is constant, every second has an equal chance of somebody finding a block.  Just plain randomness gives you a huge variation in individual block intervals.  

And KGW & DGW react in a nonlinear way to that inescapable randomness.  One or two too-short or too-long block times is enough to make them "panic" and make a nonlinear adjustment that leaves everybody looking at WTF difficulty factors.  So, we already knew we needed a replacement, and I'd already done the design work.  

This will react slower than KGW/DGW.  That's unavoidable, I think.   So yes, multipools can cheat it a little bit by "burst mining" to some extent.  They get five rapid blocks or so before emergency difficulty adjustments kick in and maybe several more before difficulty reaches correct levels, depending on how much hash power they're jumping on with.  

In fact, thinking about how a systematic burst miner with large hash power could affect its ability to track the wall clock, I probably need nSlowInterval to be larger, and adjust the IntervalDesired based on how much of a week out of date it is instead of how much of a day out of date.  

On the plus side, at least it doesn't allow them to maximize the cheat by moving in right after a difficulty adjustment boundary when the next adjustment is still far away and then grab cheap blocks right up to that boundary, nor leave the other miners sucking air until another faraway difficulty adjustment boundary arrives after they leave.  And time warps can't trigger adjustments opposite the long-term trend by "loading" a short five-block interval with a fiddled timestamp, because when moving against the direction of the longer-term trend they can't simultaneously load the intervals of different lengths.  

Hmm.  It needs a name.

Multi Interval Difficulty Adjustment System (MIDAS)?  

"Using MIDAS for difficulty adjustment..."  

Sure, that works.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Cryddit on May 13, 2014, 06:55:57 PM
Code:
  for (blockoffset = 0; blockoffset < 18; blockoffset++)
  {
    oldblocktime = blocktime;
    if (pindexLast)
    {
      pindexLast = pindexLast->pprev;
      blocktime = pindexLast->GetBlockTime();
    }
    else
    { // genesis block or previous
      blocktime -= nTargetSpacing;
    }
    // for each block, add interval.
    if (blockoffset <= 5) *avgOf5 += (oldblocktime - blocktime);
    if (blockoffset <= 7) *avgOf7 += (oldblocktime - blocktime);
    if (blockoffset <= 9) *avgOf9 += (oldblocktime - blocktime);
    *avgOf17 += (oldblocktime - blocktime);    
  }


You are actually counting 6,8,10 and 18 averages (imagine <=1; you would count with 0 and 1, guess it's a typo), but otherwise very interesting algo.


It looks at the last 18 timestamps to get the last 17 intervals.  At the last 10 timestamps to get the last 9 intervals.  Etc. 

6,8,10,18 would actually not be as good, because 6 evenly divides 18, making it possible to find a repeating cycle that might trigger in both intervals.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: btcdrak on May 13, 2014, 06:58:57 PM
Look at Dark Gravity Wave which came as a result of KGW's timewarp exploit and post what you think about it. You can find it in the DarkCoin source.

It is still vulnerable to a time warp attack in much the same manner the Kimoto Gravity Well is vulnerable. As is the Digishield and most other one block re-targeting algorithms.

DWG is not vulnerable to Time Warp, and KGW has been patched so is no longer vulnerable either. If you have some technical proof that this is not the case, please explain.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Cryddit on May 13, 2014, 07:34:01 PM
And an experimental feature, adjusts the block interval to keep the blockchain height consistent (in the long run, and approximately...) with the wall clock.


About this; I think it might open a vulnerability, but not sure, please confirm or bust. Scenario:

Attacker can generate a block chain in isolated environment which is constantly 'in the future', so targettime will be shorter than official. When that is the situation, attacker can generate more blocks/timespan with the same hahsing power than the official blockchain.

On the one hand, that's a good point and I haven't yet given it the amount of thought it deserves.  Good thinking!

On the other, that's a special case of the fact that generating a chain in an isolated environment using long block times is going to give you very low difficulty anyway.  You can generate more blocks than the regular blockchain, while going *much* further into the future per block.  

But in order for that to become an attack on the main chain, you have to bring your attack  chain's last timestamp into line with the main chain's last timestamp, and I don't think that you can.  

If you do nothing, then by the time the main chain catches up to the last timestamp of the attack chain, the main chain has more blocks (AND higher difficulty through those blocks).  

If you try to add blocks while not adding time to your attack chain, you need some form of the Time Warp exploit (which allows you to add short-time blocks without triggering difficulty adjustments, or allows you to trigger opposite-direction difficulty adjustments to compensate for them), or the difficulty will rapidly go so high that you cannot continue.  

And I had thought that I had designed this against the time warp exploit, but now I'm thinking of the implications of burst mining and the fact that you can get five rapid blocks without triggering emergency adjustments...  and repeat at intervals of 25 blocks ... and I believe the regular difficulty adjustments compensate, but I haven't proven it rigorously.  If the regular difficulty adjustments don't compensate, you could build a chain about 17% (1/6) longer in the same timestamped time, while keeping the same difficulty setting.   Meaning you'd need about 42% of hash power to build a chain equally long.  

So the question is now whether there's enough wiggle room to play the emergency adjustments against the regular adjustments.  Aww, crap, now I'm going to have to do real math.



Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Nite69 on May 13, 2014, 07:46:29 PM

It looks at the last 18 timestamps to get the last 17 intervals.  At the last 10 timestamps to get the last 9 intervals.  Etc. 

6,8,10,18 would actually not be as good, because 6 evenly divides 18, making it possible to find a repeating cycle that might trigger in both intervals.

But you count the first interval with blockoffset=0, so you really are counting one too much. If you end the loop with " <1", you get one interval, so with <18, you will get 18.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Cryddit on May 13, 2014, 08:00:04 PM

It looks at the last 18 timestamps to get the last 17 intervals.  At the last 10 timestamps to get the last 9 intervals.  Etc. 

6,8,10,18 would actually not be as good, because 6 evenly divides 18, making it possible to find a repeating cycle that might trigger in both intervals.

But you count the first interval with blockoffset=0, so you really are counting one too much. If you end the loop with " <1", you get one interval, so with <18, you will get 18.


Oh, my god.  You're right.  That was boneheaded.  Thanks for pointing that one out.

Well, this is why we have code review.  Code that seems to work "well enough" may still not be doing exactly what we suppose it's doing, in a way that will become obvious only if we examine its behavior on a statistical basis. 

A correction then: Here's how that first function should have gone... 

Code:
void avgRecentTimestamps(const CBlockIndex* pindexLast, int64_t *avgOf5, int64_t *avgOf7, int64_t *avgOf9, int64_t *avgOf17)
{
  int blockoffset = 0;
  int64_t oldblocktime;
  int64_t blocktime;

  *avgOf5 = *avgOf7 = *avgOf9 = *avgOf17 = 0;
  if (pindexLast)
    blocktime = pindexLast->GetBlockTime();
  else blocktime = 0;

   //fixed boundaries in for loop
  for (blockoffset = 0; blockoffset < 17; blockoffset++)
  {
    oldblocktime = blocktime;
    if (pindexLast)
    {
      pindexLast = pindexLast->pprev;
      blocktime = pindexLast->GetBlockTime();
    }
    else
    { // genesis block or previous
      blocktime -= nTargetSpacing;
    }
    // for each block, add interval.
     //compare using < rather than <=
    if (blockoffset < 5) *avgOf5 += (oldblocktime - blocktime);
    if (blockoffset < 7) *avgOf7 += (oldblocktime - blocktime);
    if (blockoffset < 9) *avgOf9 += (oldblocktime - blocktime);
    *avgOf17 += (oldblocktime - blocktime);   
  }
  // now we have the sums of the block intervals. Division gets us the averages.
  *avgOf5 /= 5;
  *avgOf7 /= 7;
  *avgOf9 /= 9;
  *avgOf17 /= 17;
}
[code]
[/code]


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Nite69 on May 13, 2014, 08:03:58 PM
Actually, after all this hassle, I'v ended up thinking 1 block retarget is faulty by design. It is meant to retarget fast, but retargetting fast *is* the vulnerability.

I think that KGW fix might have fixed something, but likely it has not fixed everything, and it might even have opened new ones.

The same vulnerability is, in theory, also on usual bitcoin protocol. But as the retarget time is 2 weeks, it is practically impossible to use.

Whatever is the algorithm, if it is fast, the attacker can quickly get a low difficulty to generate a lot of blocks. Getting back to realtime might be a small problem, but not really.

But we must remember, since block height is based on work done, it means the attacker still needs that 51% of the hashing power, so coins with much hashing power (or PoS) should be safe.

I think the simplest is the best, ie digishield. It is actually the bitcoin retarget, shortened from 2 weeks to 1 block. However, some attenuation makes it 'not so maniac'.

Automatic decentarilzed checkpointing would be good. I had some suggestion somewhere here, but got not much discussion. The princible is that if the latest block is generated with more than 50% of the 'to-be-checkpointed' block in the past (for example height-32), it can be safely checkpointed. And it should be, since the protocol practically means mined coins are fully agreed to exist, so they must not be abandoned in any circumstances. Not even if some hidden higher blockchain appears from nowhere.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: btcdrak on May 13, 2014, 08:20:42 PM
Here is the latest Dark Gravity Wave v3 https://github.com/darkcoinproject/darkcoin/blob/master/src/main.cpp#L1562

Including this change to util.cpp https://github.com/darkcoinproject/darkcoin/commit/857e34d28d84a6c7d0910eb800397b5382e520f4#diff-b7702a084eb00fb47f9800fd68271951R1338
I cant see a way to timewarp this effectively.


Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Cryddit on May 13, 2014, 10:09:03 PM

The point about trying to track the expected block height for the timestamp is to try to control the coin supply. 

We've seen the exploits; we know that burst mining tactics can often result in blockchains running consistently faster than they are supposed to, and supplies of coins that were supposed to become available over the course of years being instamined in a few weeks instead - with difficulty ratcheting up and down wildly as burst miners jump on and off.

These coins then get dumped on the markets and the whole thing collapses (I know, that usually happens anyway, but sometimes the coin developer didn't mean for it to happen and might not even be the one doing it....)

From the POV of someone who is mining, or holding coins, it would be nice to know that there isn't an easy exploit that can make the blockchain run consistently fast, bringing more coins into existence faster than intended.  Having the blockchain detect when it's created more blocks than it's supposed to have, and slow down, or conversely detect that it hasn't been creating enough blocks, and speed up, is a way of committing to the 'nominal' coin creation rate that often gets left by the wayside in the interaction between adjustment algorithms and exploiters (or, indeed, between adjustment algorithms and random chance).





Title: Re: Regarding Auroracoin TW exploit (Fix included)
Post by: Nite69 on May 14, 2014, 06:28:12 AM

I think what everyone should take away from this thread is that the only way to actively secure a PoW blockchain in a decentralized manner is to support the chain with hashes.

True. If you want to continue this subject, please open a new thread or use some older and copy your comments to it . Sorry for inconvenience