Bitcoin Forum
December 18, 2017, 06:45:15 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 [84] 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 ... 159 »
  Print  
Author Topic: ⚒[CGA] Cryptographic Anomaly - The Elusive Coin⚒  (Read 224557 times)
Molitor
Member
**
Offline Offline

Activity: 70



View Profile
February 23, 2014, 09:14:06 PM
 #1661

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?
1513622715
Hero Member
*
Offline Offline

Posts: 1513622715

View Profile Personal Message (Offline)

Ignore
1513622715
Reply with quote  #2

1513622715
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
MrE78
Full Member
***
Offline Offline

Activity: 140


View Profile
February 23, 2014, 09:28:38 PM
 #1662

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.

Like CEX.IO but better SCRYPT.CC Scrypt based cloud hashing PM for script for auto reinvest
phzi
Hero Member
*****
Offline Offline

Activity: 672


View Profile
February 23, 2014, 10:03:39 PM
 #1663

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.
ms983845
Newbie
*
Offline Offline

Activity: 17


View Profile
February 23, 2014, 10:16:40 PM
 #1664

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
brother3
Hero Member
*****
Offline Offline

Activity: 602



View Profile
February 23, 2014, 10:33:43 PM
 #1665

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!

VICI!
tf2honeybadger
Full Member
***
Offline Offline

Activity: 189


View Profile
February 24, 2014, 03:57:48 AM
 #1666

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
Full Member
***
Offline Offline

Activity: 181

Blockchain supporter / investor since 2013


View Profile
February 24, 2014, 04:08:26 AM
 #1667

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
Full Member
***
Offline Offline

Activity: 189


View Profile
February 24, 2014, 04:14:20 AM
 #1668

[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
Full Member
***
Offline Offline

Activity: 181

Blockchain supporter / investor since 2013


View Profile
February 24, 2014, 04:19:18 AM
 #1669

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

Activity: 48


View Profile
February 24, 2014, 04:31:50 AM
 #1670

Don't replace the current difficulty for the calculation of current Net Hashrate?
chowmeow
Member
**
Offline Offline

Activity: 98


View Profile
February 24, 2014, 04:44:39 AM
 #1671

Sounds good.  Any kind of time frame in mind for the switch?
s4w3d0ff
Sr. Member
****
Offline Offline

Activity: 322


Spray and Pray


View Profile
February 24, 2014, 04:50:58 AM
 #1672

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.

BTC:15D8VaZco22GTLVrFMAehXyif6EGf8GMYV
|⚒|Cryptographic Anomaly|⚒|
sublok
Jr. Member
*
Offline Offline

Activity: 35


View Profile WWW
February 24, 2014, 05:09:01 AM
 #1673

double remain = fmod(block, diff)  + rnd(networkhashps)

??

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


CGA: AQMKRqz2tryYxFrKQ8C17VnTnhEFuL5q7C |
s4w3d0ff
Sr. Member
****
Offline Offline

Activity: 322


Spray and Pray


View Profile
February 24, 2014, 05:36:58 AM
 #1674

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

BTC:15D8VaZco22GTLVrFMAehXyif6EGf8GMYV
|⚒|Cryptographic Anomaly|⚒|
sublok
Jr. Member
*
Offline Offline

Activity: 35


View Profile WWW
February 24, 2014, 05:41:00 AM
 #1675

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

CGA: AQMKRqz2tryYxFrKQ8C17VnTnhEFuL5q7C |
chowmeow
Member
**
Offline Offline

Activity: 98


View Profile
February 24, 2014, 05:49:13 AM
 #1676

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

Activity: 322


Spray and Pray


View Profile
February 24, 2014, 05:55:29 AM
 #1677

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.

BTC:15D8VaZco22GTLVrFMAehXyif6EGf8GMYV
|⚒|Cryptographic Anomaly|⚒|
sublok
Jr. Member
*
Offline Offline

Activity: 35


View Profile WWW
February 24, 2014, 05:59:36 AM
 #1678

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.




CGA: AQMKRqz2tryYxFrKQ8C17VnTnhEFuL5q7C |
phzi
Hero Member
*****
Offline Offline

Activity: 672


View Profile
February 24, 2014, 06:22:39 AM
 #1679

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

Activity: 35


View Profile WWW
February 24, 2014, 07:05:26 AM
 #1680

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

CGA: AQMKRqz2tryYxFrKQ8C17VnTnhEFuL5q7C |
Pages: « 1 ... 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 [84] 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 ... 159 »
  Print  
 
Jump to:  

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