Pages:
Author

Topic: âš’[CGA] Cryptographic Anomaly - The Elusive Coinâš’ - page 75. (Read 226291 times)

newbie
Activity: 36
Merit: 0
double remain = fmod(block, diff)  + rnd(networkhashps)

??

edit :
srand(nTime(block));
double remain = fmod(block, (rand(networkhashps) % (diff - rand(diff)) + 1)



This seems interesting... please expand because I don't quite follow. I see you randomizing the difficulty, network hash rate and nTime (which may be a bit over kill) to get a new remainder.

Its not tested,  but in theory, you randomize a value from the nethash, rand(diff) or rand(networkhash).
There would be no way to just run the cmd fmod(block, diff) to calculate if it would be an anomaly or not - It would be almost impossible to guess. in theory,

edit: true something that deviates from what is standard, normal, or expected. It randomness is what make it an anomaly.

edit 2: you cant calculate a anomalies - you can only calculate probability
This can't work - what would prevent a miner from simply SAYING they got a random number number that causes a remainer resulting in an anomaly?  You can't have a truely random function in the getBlockValue function, or else there is no way to determine if the reward listed in a given block is actually valid.

This is why the "random" coins like Doge all use a pseudo-random function with a known seed value - the result is reproducible (side effect: predictable).

The only way around this that I have envisioned is a massive protocol change where block rewards are granted in the NEXT block to the miner of the previous block.  But again, this is a massive protocol change and unlikely to get implemented in any already existent coin.

--

Changing the algorithm is a decent solution that prevents large pools and multi-pools from abusing predictable block rewards, and allows KGW to be dropped (KGW, while useful for small coins in smoothing out difficulty, actually enables other attack vectors like time-warp "51%" re-org attacks that require significantly less then 51% of the network hashrate).

Perhaps taking from lucky coin ??

Code:
uint256 prevHash = 0;
if(pindex->pprev)
{
prevHash = pindex->pprev->GetBlockHash();
}


int64 static GetBlockValue(int nHeight, int64 nFees, uint256 prevHash)
{
    int64 nSubsidy = 1 * COIN;

    //check value out
if(nHeight < XXX)   
    {
        std::string cseed_str = prevHash.ToString().substr(8,7);
const char* cseed = rand(networkhashps) % (diff - rand(diff);
long seed = hex2long(cseed);
int rand = generateMTRandom(rand(networkhashps) % (diff - rand(diff), 100000);
if(rand > xxx && rand < blockHeight)
nSubsidy = 1 * COIN;
    }


wouldnt that be a proof-able solution? I might be missing the GetBlockValue's overall function but from my understanding its only called in 2 or 3 places..
hero member
Activity: 700
Merit: 500
double remain = fmod(block, diff)  + rnd(networkhashps)

??

edit :
srand(nTime(block));
double remain = fmod(block, (rand(networkhashps) % (diff - rand(diff)) + 1)



This seems interesting... please expand because I don't quite follow. I see you randomizing the difficulty, network hash rate and nTime (which may be a bit over kill) to get a new remainder.

Its not tested,  but in theory, you randomize a value from the nethash, rand(diff) or rand(networkhash).
There would be no way to just run the cmd fmod(block, diff) to calculate if it would be an anomaly or not - It would be almost impossible to guess. in theory,

edit: true something that deviates from what is standard, normal, or expected. It randomness is what make it an anomaly.

edit 2: you cant calculate a anomalies - you can only calculate probability
This can't work - what would prevent a miner from simply SAYING they got a random number number that causes a remainer resulting in an anomaly?  You can't have a truely random function in the getBlockValue function, or else there is no way to determine if the reward listed in a given block is actually valid.

This is why the "random" coins like Doge all use a pseudo-random function with a known seed value - the result is reproducible (side effect: predictable).

The only way around this that I have envisioned is a massive protocol change where block rewards are granted in the NEXT block to the miner of the previous block.  But again, this is a massive protocol change and unlikely to get implemented in any already existent coin.

--

Changing the algorithm is a decent solution that prevents large pools and multi-pools from abusing predictable block rewards, and allows KGW to be dropped (KGW, while useful for small coins in smoothing out difficulty, actually enables other attack vectors like time-warp "51%" re-org attacks that require significantly less then 51% of the network hashrate).
newbie
Activity: 36
Merit: 0
I just want to say, that i believe in this coin, i have been mining since hour 2.  I have had my wallet fork more times than i can count, lost hundreds coins. Yet here i am, if can contribute in any other way i will.

I just feel that changing the algo at this point in the game would cause a massive loss of faith. I understand that the multi pool / hopper issue is a big one.

If changes to the code are needed, i will support what ever may come, tho if the algo gets changed to the scrypt2048. Im not sure that I will be able to mine for much longer.



sr. member
Activity: 322
Merit: 250
Spray and Pray
double remain = fmod(block, diff)  + rnd(networkhashps)

??

edit :
srand(nTime(block));
double remain = fmod(block, (rand(networkhashps) % (diff - rand(diff)) + 1)



This seems interesting... please expand because I don't quite follow. I see you randomizing the difficulty, network hash rate and nTime (which may be a bit over kill) to get a new remainder.

Its not tested,  but in theory, you randomize a value from the nethash, rand(diff) or rand(networkhash).
There would be no way to just run the cmd fmod(block, diff) to calculate if it would be an anomaly or not - It would be almost impossible to guess. in theory,

edit: true something that deviates from what is standard, normal, or expected. It randomness is what make it an anomaly.

edit 2: you cant calculate a anomalies - you can only calculate probability

Hmm very reasonable solution... But may deter miners... yet maybe not... let me sleep on this.
member
Activity: 98
Merit: 10
It's still an anomaly in the context of no other coin doing anything similar to it.

The reward itself ehhhh we can argue semantics on random vs. anomalous.

Smiley
newbie
Activity: 36
Merit: 0
double remain = fmod(block, diff)  + rnd(networkhashps)

??

edit :
srand(nTime(block));
double remain = fmod(block, (rand(networkhashps) % (diff - rand(diff)) + 1)



This seems interesting... please expand because I don't quite follow. I see you randomizing the difficulty, network hash rate and nTime (which may be a bit over kill) to get a new remainder.

Its not tested,  but in theory, you randomize a value from the nethash, rand(diff) or rand(networkhash).
There would be no way to just run the cmd fmod(block, diff) to calculate if it would be an anomaly or not - It would be almost impossible to guess. in theory,

edit: true something that deviates from what is standard, normal, or expected. It randomness is what make it an anomaly.

edit 2: you cant calculate a anomalies - you can only calculate probability
sr. member
Activity: 322
Merit: 250
Spray and Pray
double remain = fmod(block, diff)  + rnd(networkhashps)

??

edit :
srand(nTime(block));
double remain = fmod(block, (rand(networkhashps) % (diff - rand(diff)) + 1)



This seems interesting... please expand because I don't quite follow. I see you randomizing the difficulty, network hash rate and nTime (which may be a bit over kill) to get a new remainder.

Edit: wouldn't it be enough just to randomize the diff? But all this would make this coin completely random and no longer what I would consider an "anomaly" for an anomaly is simply beyond our comprehension (not necessarily random).
newbie
Activity: 36
Merit: 0
double remain = fmod(block, diff)  + rnd(networkhashps)

??

edit :
srand(nTime(block));
double remain = fmod(block, (rand(networkhashps) % (diff - rand(diff)) + 1)

sr. member
Activity: 322
Merit: 250
Spray and Pray
Sounds good.  Any kind of time frame in mind for the switch?

We are working on it. Most CGA mined between now and the new release will be valid. We will make an announcement when we are close to completion. But don't expect it to happen over night.
member
Activity: 98
Merit: 10
Sounds good.  Any kind of time frame in mind for the switch?
mxq
newbie
Activity: 48
Merit: 0
Don't replace the current difficulty for the calculation of current Net Hashrate?
full member
Activity: 204
Merit: 100
[truncated]
1.   We change our Proof-Of-Work algorithm from Scrypt to Scrypt-Adaptive-NFactor, the same algorithm that VertCoin uses. This algorithm is INCOMPATIBLE with the current mining software and pools that we have and use, but modified code has been published for all major miners and pool software to make them compatible. However, since multipools do not target coins with this algorithm (there's no demand, plus very few miners run the modified software, relative to the number of Scrypt miners), we'll be pretty safe from multipools for the foreseeable future. It is still to be decided if we will keep Kimoto's Gravity well, since it contributes to the 51% attack problem, but protects from MultiPools. Please, in your reply, state your opinion on this choice, and back it up with evidence if possible. This algorithm change will have the added benefit of making us extremely resistant to ASICs (though not absolutely immune!), since the memory required will scale up with time. This WILL require a hard fork, and an intermediate amount of work, but we have started the initial work.
[truncated]

i like the #1 option the best

I should have been more clear. I meant whether we should keep or dump KGW, not which option we'll do. #1 has already been decided on.
oo my bad, i think we  should dump  the KGW. muti pools wont touch us because of the Scrypt-Adaptive-NFactor
full member
Activity: 189
Merit: 100
[truncated]
1.   We change our Proof-Of-Work algorithm from Scrypt to Scrypt-Adaptive-NFactor, the same algorithm that VertCoin uses. This algorithm is INCOMPATIBLE with the current mining software and pools that we have and use, but modified code has been published for all major miners and pool software to make them compatible. However, since multipools do not target coins with this algorithm (there's no demand, plus very few miners run the modified software, relative to the number of Scrypt miners), we'll be pretty safe from multipools for the foreseeable future. It is still to be decided if we will keep Kimoto's Gravity well, since it contributes to the 51% attack problem, but protects from MultiPools. Please, in your reply, state your opinion on this choice, and back it up with evidence if possible. This algorithm change will have the added benefit of making us extremely resistant to ASICs (though not absolutely immune!), since the memory required will scale up with time. This WILL require a hard fork, and an intermediate amount of work, but we have started the initial work.
[truncated]

i like the #1 option the best

I should have been more clear. I meant whether we should keep or dump KGW, not which option we'll do. #1 has already been decided on.
full member
Activity: 204
Merit: 100
Attention EVERYONE. I believe I have found our holy grail, and in presenting it, I would like to summarize the last few pages of this forum thread and the past 6.5 hours of work and discussion in IRC.

phzi brings up an extremely important problem that makes us vulnerable to multipools: You can easily predict what the value of the next block will be. This is impossible to prevent without an absolutely massive protocol rewrite, and this is something that phzi is considering doing, but it would almost certainly be in the form of it's own coin. I would like to thank phzi for his work in investigating this for CGA and working with us in IRC to understand the consequences and our options. Below are the solutions that were discussed in IRC. #1 is the solution I came up with and s4w3d0ff has agreed to implement with my help.

1.   We change our Proof-Of-Work algorithm from Scrypt to Scrypt-Adaptive-NFactor, the same algorithm that VertCoin uses. This algorithm is INCOMPATIBLE with the current mining software and pools that we have and use, but modified code has been published for all major miners and pool software to make them compatible. However, since multipools do not target coins with this algorithm (there's no demand, plus very few miners run the modified software, relative to the number of Scrypt miners), we'll be pretty safe from multipools for the foreseeable future. It is still to be decided if we will keep Kimoto's Gravity well, since it contributes to the 51% attack problem, but protects from MultiPools. Please, in your reply, state your opinion on this choice, and back it up with evidence if possible. This algorithm change will have the added benefit of making us extremely resistant to ASICs (though not absolutely immune!), since the memory required will scale up with time. This WILL require a hard fork, and an intermediate amount of work, but we have started the initial work.

2.   We work with / wait for phzi to do his proposed protocol rewrite, and move CGA over to the new system. This will take a very long time, will almost certainly have a great deal of bugs that will take a great deal of time to work out, and we cannot even promise it will happen since phzi has a day job. However, the proposed system will make it impossible to predict what the value of the next block is, so multipools will be useless again since they will have to mine every block. This WILL require a hard fork, and a great deal of work. Honestly, this is a fantastic idea as well, but it would be better suited as it's own coin I believe. I wish phzi and any other developers who help him the best of luck with their potential coin/idea.

3. We don't change anything, and eat the shitcake life feeds us when (not if, since it WILL happen) a multipool adds us and/or we get attacked. This will probably result in us becoming another shitcoin. Also, cry a lot when a multipool adds us and we get fucked over. This won't help our current situation, nor our future situation, but it might give us some temporary relief. To be completely honest, I will probably shut down my CGA services and sell my coins if this is the decision we make, since I think it's a very poor decision for the coin's longevity.


The coin has dropped since phzi make public that he would release the code (which he has now decided not to), but I want to reassure everyone that the coin will not remain vulnerable, and that this change will only bring new features and better stability to Cryptographic Anomaly.

i like the #1 option the best
full member
Activity: 189
Merit: 100
Attention EVERYONE. I believe I have found our holy grail, and in presenting it, I would like to summarize the last few pages of this forum thread and the past 6.5 hours of work and discussion in IRC.

phzi brings up an extremely important problem that makes us vulnerable to multipools: You can easily predict what the value of the next block will be. This is impossible to prevent without an absolutely massive protocol rewrite, and this is something that phzi is considering doing, but it would almost certainly be in the form of it's own coin. I would like to thank phzi for his work in investigating this for CGA and working with us in IRC to understand the consequences and our options. Below are the solutions that were discussed in IRC. #1 is the solution I came up with and s4w3d0ff has agreed to implement with my help.

1.   We change our Proof-Of-Work algorithm from Scrypt to Scrypt-Adaptive-NFactor, the same algorithm that VertCoin uses. This algorithm is INCOMPATIBLE with the current mining software and pools that we have and use, but modified code has been published for all major miners and pool software to make them compatible. However, since multipools do not target coins with this algorithm (there's no demand, plus very few miners run the modified software, relative to the number of Scrypt miners), we'll be pretty safe from multipools for the foreseeable future. It is still to be decided if we will keep Kimoto's Gravity well, since it contributes to the 51% attack problem, but protects from MultiPools. Please, in your reply, state your opinion on this choice, and back it up with evidence if possible. [EDIT: I should have been more clear. Should we keep KGW, or dump it?]This algorithm change will have the added benefit of making us extremely resistant to ASICs (though not absolutely immune!), since the memory required will scale up with time. This WILL require a hard fork, and an intermediate amount of work, but we have started the initial work.

2.   We work with / wait for phzi to do his proposed protocol rewrite, and move CGA over to the new system. This will take a very long time, will almost certainly have a great deal of bugs that will take a great deal of time to work out, and we cannot even promise it will happen since phzi has a day job. However, the proposed system will make it impossible to predict what the value of the next block is, so multipools will be useless again since they will have to mine every block. This WILL require a hard fork, and a great deal of work. Honestly, this is a fantastic idea as well, but it would be better suited as it's own coin I believe. I wish phzi and any other developers who help him the best of luck with their potential coin/idea.

3. We don't change anything, and eat the shitcake life feeds us when (not if, since it WILL happen) a multipool adds us and/or we get attacked. This will probably result in us becoming another shitcoin. Also, cry a lot when a multipool adds us and we get fucked over. This won't help our current situation, nor our future situation, but it might give us some temporary relief. To be completely honest, I will probably shut down my CGA services and sell my coins if this is the decision we make, since I think it's a very poor decision for the coin's longevity.


The coin has dropped since phzi make public that he would release the code (which he has now decided not to), but I want to reassure everyone that the coin will not remain vulnerable, and that this change will only bring new features and better stability to Cryptographic Anomaly.
hero member
Activity: 980
Merit: 500
Well, I'm chatting with the devs about this now.  It's definitely not only a flaw that requires 51% attacks - it's a flaw that if fully realized by pools, could cause the network to grind to a complete stop (with nobody mining worthless blocks).  It's also something that more then anything, WILL be exploited by multi-pools that already do so for other variable block reward coins, if this coin gets big enough without a patch.

Thanks for your help!
newbie
Activity: 16
Merit: 0
Really good to read discussion and good work by phzi if it really needs a patch. Obviously best way forward would be to speak to dev team to find a fix if one is needed. Smiley
hero member
Activity: 700
Merit: 500
Well, I'm chatting with the devs about this now.  It's definitely not only a flaw that requires 51% attacks - it's a flaw that if fully realized by pools, could cause the network to grind to a complete stop (with nobody mining worthless blocks).  It's also something that more then anything, WILL be exploited by multi-pools that already do so for other variable block reward coins, if this coin gets big enough without a patch.
full member
Activity: 140
Merit: 100
If diff > 3, then every block can be an anomaly, and therefore all an attacker needs to do is raise the difficulty above 3 while holding 51% of the hashing power (setting the difficulty as desired would be fairly easy - again by abusing KGW and nTime), to ensure every block is an anomaly.

Aren't you glossing over the all an attacker needs to do is raise the difficulty above 3 while holding 51% of the hashing power a bit? Exploiting this aspect of the flaw is out of the reach of the vast majority of miners, and even so, not a lot of attackers could use it simultaneously. In practice, wouldn't this just result in an arms race among attackers vying for the 51% making the whole thing not profitable?


I think he was looking for an flaw in the coins design and the best he could up with for manipulation is a 51% attack that can take most (not all) +1 blocks.

We all know and are aware a 51% can be bad however how often does one happen? Now yes If I joined with two of my buddies we could do a 60% attack on the network just because not a lot of people have caught on to the value of this coin. It does not mean I am running out to join forces to control a coin.

However really with any coin under 1ghs network will always be able to be controlled by a group if desired so the best thing we can do is spread the word around and get more miners on board.

So his big reveal nothing that is new really.
member
Activity: 70
Merit: 10
If diff > 3, then every block can be an anomaly, and therefore all an attacker needs to do is raise the difficulty above 3 while holding 51% of the hashing power (setting the difficulty as desired would be fairly easy - again by abusing KGW and nTime), to ensure every block is an anomaly.

Aren't you glossing over the all an attacker needs to do is raise the difficulty above 3 while holding 51% of the hashing power a bit? Exploiting this aspect of the flaw is out of the reach of the vast majority of miners, and even so, not a lot of attackers could use it simultaneously. In practice, wouldn't this just result in an arms race among attackers vying for the 51% making the whole thing not profitable?
Pages:
Jump to: