Bitcoin Forum
March 29, 2024, 08:32:52 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
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 ... 158 »
  Print  
Author Topic: ⚒[CGA] Cryptographic Anomaly - The Elusive Coin⚒  (Read 226214 times)
brother3
Hero Member
*****
Offline Offline

Activity: 980
Merit: 500



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

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

Posts: 1711701172

View Profile Personal Message (Offline)

Ignore
1711701172
Reply with quote  #2

1711701172
Report to moderator
1711701172
Hero Member
*
Offline Offline

Posts: 1711701172

View Profile Personal Message (Offline)

Ignore
1711701172
Reply with quote  #2

1711701172
Report to moderator
1711701172
Hero Member
*
Offline Offline

Posts: 1711701172

View Profile Personal Message (Offline)

Ignore
1711701172
Reply with quote  #2

1711701172
Report to moderator
If you see garbage posts (off-topic, trolling, spam, no point, etc.), use the "report to moderator" links. All reports are investigated, though you will rarely be contacted about your reports.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711701172
Hero Member
*
Offline Offline

Posts: 1711701172

View Profile Personal Message (Offline)

Ignore
1711701172
Reply with quote  #2

1711701172
Report to moderator
tf2honeybadger
Full Member
***
Offline Offline

Activity: 189
Merit: 100


View Profile
February 24, 2014, 03:57:48 AM
Last edit: February 24, 2014, 06:41:35 AM by tf2honeybadger
 #1662

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: 204
Merit: 100


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

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
Merit: 100


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

[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: 204
Merit: 100


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

[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 Offline

Activity: 48
Merit: 0


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

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

Activity: 98
Merit: 10


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

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

Activity: 322
Merit: 250


Spray and Pray


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

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

Activity: 36
Merit: 0


View Profile WWW
February 24, 2014, 05:09:01 AM
Last edit: February 24, 2014, 05:22:22 AM by sublok
 #1669

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 Offline

Activity: 322
Merit: 250


Spray and Pray


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

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

Activity: 36
Merit: 0


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

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 Offline

Activity: 98
Merit: 10


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

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 (OP)
Sr. Member
****
Offline Offline

Activity: 322
Merit: 250


Spray and Pray


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

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

Activity: 36
Merit: 0


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

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

Activity: 700
Merit: 500


View Profile
February 24, 2014, 06:22:39 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
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 Offline

Activity: 36
Merit: 0


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

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

Activity: 28
Merit: 0


View Profile
February 24, 2014, 07:12:53 AM
 #1677

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

Activity: 238
Merit: 100


View Profile
February 24, 2014, 07:27:03 AM
 #1678

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
Code:
1/3 = 0.333333333
Block Reward: 0.333333333

Diff = 10
Code:
1/10 = 0.1
Block Reward: 0.100000000

Diff = 200
Code:
1/200 = 0.005
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 Offline

Activity: 36
Merit: 0


View Profile WWW
February 24, 2014, 07:32:16 AM
 #1679

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.

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

Thats in essence what i was getting at with the prevHash
tertius993
Hero Member
*****
Online Online

Activity: 1015
Merit: 708


View Profile
February 24, 2014, 07:38:18 AM
 #1680

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 ... Wink
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 ... 158 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!