brother3
|
|
February 23, 2014, 10:33:43 PM |
|
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!
|
|
|
|
tf2honeybadger
|
|
February 24, 2014, 03:57:48 AM Last edit: February 24, 2014, 06:41:35 AM by tf2honeybadger |
|
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.
|
|
|
|
chickenliver503
|
|
February 24, 2014, 04:08:26 AM |
|
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
|
|
|
|
tf2honeybadger
|
|
February 24, 2014, 04:14:20 AM |
|
[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.
|
|
|
|
chickenliver503
|
|
February 24, 2014, 04:19:18 AM |
|
[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
|
|
|
|
mxq
Newbie
Offline
Activity: 48
Merit: 0
|
|
February 24, 2014, 04:31:50 AM |
|
Don't replace the current difficulty for the calculation of current Net Hashrate?
|
|
|
|
chowmeow
Member
Offline
Activity: 98
Merit: 10
|
|
February 24, 2014, 04:44:39 AM |
|
Sounds good. Any kind of time frame in mind for the switch?
|
|
|
|
s4w3d0ff (OP)
Sr. Member
Offline
Activity: 322
Merit: 250
Spray and Pray
|
|
February 24, 2014, 04:50:58 AM |
|
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.
|
|
|
|
sublok
Newbie
Offline
Activity: 36
Merit: 0
|
|
February 24, 2014, 05:09:01 AM Last edit: February 24, 2014, 05:22:22 AM by sublok |
|
double remain = fmod(block, diff) + rnd(networkhashps)
??
edit : srand(nTime(block)); double remain = fmod(block, (rand(networkhashps) % (diff - rand(diff)) + 1)
|
|
|
|
s4w3d0ff (OP)
Sr. Member
Offline
Activity: 322
Merit: 250
Spray and Pray
|
|
February 24, 2014, 05:36:58 AM |
|
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).
|
|
|
|
sublok
Newbie
Offline
Activity: 36
Merit: 0
|
|
February 24, 2014, 05:41:00 AM |
|
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
|
|
|
|
chowmeow
Member
Offline
Activity: 98
Merit: 10
|
|
February 24, 2014, 05:49:13 AM |
|
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.
|
|
|
|
s4w3d0ff (OP)
Sr. Member
Offline
Activity: 322
Merit: 250
Spray and Pray
|
|
February 24, 2014, 05:55:29 AM |
|
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.
|
|
|
|
sublok
Newbie
Offline
Activity: 36
Merit: 0
|
|
February 24, 2014, 05:59:36 AM |
|
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.
|
|
|
|
phzi
|
|
February 24, 2014, 06:22:39 AM |
|
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).
|
|
|
|
sublok
Newbie
Offline
Activity: 36
Merit: 0
|
|
February 24, 2014, 07:05:26 AM |
|
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 ?? 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..
|
|
|
|
awesomeperson451
Newbie
Offline
Activity: 28
Merit: 0
|
|
February 24, 2014, 07:12:53 AM |
|
The problem, if I'm understanding this correctly, is that there isn't any known good way to figure out which blocks are anomalies or not without making the process predictable or easily exploited. I've got an idea for a new block reward equation that I think avoids being either one of those: Just take the original equation, Height % Difficulty, and replace height with the newly found hash of the block you are determining the reward of. This way, no one knows which blocks will be anomalies until after someone mines a block and it gets accepted by the network, and every client on the network will agree with each other since the network difficulty and the block hash in question are already agreed upon in the first place. And because the scrypt hashing algorithm has been proven to be completely unpredictable, there's no way to ensure that the next block you mine will pay out, and there's no way to exploit the system that is more efficient or profitable than just mining legitimately.
|
|
|
|
wzttide
|
|
February 24, 2014, 07:27:03 AM |
|
I'd like to suggest a different block reward system: Instead of reward every x block, reward every block, but devide the reward (1) by the diff. If the diff is less than 3, 3 is taken. Examples:Diff = 1 Block Reward: 0.333333333 Diff = 10 Block Reward: 0.100000000 Diff = 200 Block Reward: 0.005 This would have some advantages: - The rewards wouldn't change at all over time.
- Every block pays (rewarding long-time-miners).
- If a multi pool hits the coin, the diff raises within 2 blocks, the multi pool wouldn't be able to mine much coins.
Moving to another hash alorithm is not advisable in my opinion because: - Scrypt is pretty ASCI resistent, even if there are scrypt ASICs now, they are not comparable to GPUs because of their very low resell value. Scrypt ASICs are not faster than GPUs.
- Changing the hash algorithm would require a hard fork or a relaunch of a coin. Relaunch would kill every confidence in the creators, changing the algorithm will result in people jumping off because mining would be more difficult (e. g. scrypt-n-factor).
|
|
|
|
sublok
Newbie
Offline
Activity: 36
Merit: 0
|
|
February 24, 2014, 07:32:16 AM |
|
The problem, if I'm understanding this correctly, is that there isn't any known good way to figure out which blocks are anomalies or not without making the process predictable or easily exploited. I've got an idea for a new block reward equation that I think avoids being either one of those: Just take the original equation, Height % Difficulty, and replace height with the newly found hash of the block you are determining the reward of. This way, no one knows which blocks will be anomalies until after someone mines a block and it gets accepted by the network, and every client on the network will agree with each other since the network difficulty and the block hash in question are already agreed upon in the first place. And because the scrypt hashing algorithm has been proven to be completely unpredictable, there's no way to ensure that the next block you mine will pay out, and there's no way to exploit the system that is more efficient or profitable than just mining legitimately.
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
Thats in essence what i was getting at with the prevHash
|
|
|
|
tertius993
|
|
February 24, 2014, 07:38:18 AM |
|
Apologies in advance if this is a stupid question. However, there is something about this I don't really understand. As I understand it the part of the problem is that it is possible to predict when you get to it if a given block will reward with an anomaly (1 coin). And if a block is not going to give an anomaly then don't bother to mine it? However, surely every block has to be mined? You can't just say "oh, block 21,234 has no reward, I'll skip that one and mine block 21,235 instead" Don't you have to wait for block 21,234 to be mined, before you can move onto the next one? Moreover, the zero reward blocks may also reward with mining/transaction fees *and* they will include transactions that have to be added to the blockchain. So all the blocks have to be mined in order anyway? So is it *really* a problem? I expect I have missed something crucial somewhere, so happy to be corrected ...
|
|
|
|
|