⚒[CGA] Cryptographic Anomaly - The Elusive Coin⚒

[s4w3d0ff]

FYI: If have been digging into CGA code a bit more, and if my tests are successful today, I plan to release code that will allow predicting and forcing anomalies on CGA.

It will look like this:
- An odd # block is found.  The script can immediately tell you if the next block is an anomaly or not.
- An even # block is found.  The script can immediately tell you what nTime values to use to GUARANTEE the next block is an anomaly.

Even if you were able to do so, you couldn't predict if you generate the anomaly or if someone else does. That is mining crypto currency... Everyone is competing for the same block at any given time. As soon as you put more hash power into CGA the longer you have to wait unitl you can find that "right moment" to jump into the network. I can see you raising your probability, but actually generating an anomaly EVERY TIME you jump into the network will not happen even if you have +50% of the network hashing power, that would make your odds 1/2 (a coin toss). So while you may of figured out a way to save your mining rigs from mining the 0 blocks, It doesn't mean that you will get an anomaly every time... And if everyone had the script you speak of then your script would go haywire as soon as everyone "jumps" at the same time.

[1714325316]

1714325316

[1714325316]

1714325316

[1714325316]

1714325316

[1714325316]

1714325316

[oudekaas]

FYI: If have been digging into CGA code a bit more, and if my tests are successful today, I plan to release code that will allow predicting and forcing anomalies on CGA.

It will look like this:
- An odd # block is found.  The script can immediately tell you if the next block is an anomaly or not.
- An even # block is found.  The script can immediately tell you what nTime values to use to GUARANTEE the next block is an anomaly.

Even if you were able to do so, you couldn't predict if you generate the anomaly or if someone else does. That is mining crypto currency... Everyone is competing for the same block at any given time. As soon as you put more hash power into CGA the longer you have to wait unitl you can find that "right moment" to jump into the network. I can see you raising your probability, but actually generating an anomaly EVERY TIME you jump into the network will not happen even if you have +50% of the network hashing power, that would make your odds 1/2 (a coin toss). So while you may of figured out a way to save your mining rigs from mining the 0 blocks, It doesn't mean that you will get an anomaly every time... And if everyone had the script you speak of then your script would go haywire as soon as everyone "jumps" at the same time.

so what you are saying is that if everyone simply uses that scrypt this coin will work as predicted?
why not implement that scrypt in the pools then?

[s4w3d0ff]

FYI: If have been digging into CGA code a bit more, and if my tests are successful today, I plan to release code that will allow predicting and forcing anomalies on CGA.

It will look like this:
- An odd # block is found.  The script can immediately tell you if the next block is an anomaly or not.
- An even # block is found.  The script can immediately tell you what nTime values to use to GUARANTEE the next block is an anomaly.

Even if you were able to do so, you couldn't predict if you generate the anomaly or if someone else does. That is mining crypto currency... Everyone is competing for the same block at any given time. As soon as you put more hash power into CGA the longer you have to wait unitl you can find that "right moment" to jump into the network. I can see you raising your probability, but actually generating an anomaly EVERY TIME you jump into the network will not happen even if you have +50% of the network hashing power, that would make your odds 1/2 (a coin toss). So while you may of figured out a way to save your mining rigs from mining the 0 blocks, It doesn't mean that you will get an anomaly every time... And if everyone had the script you speak of then your script would go haywire as soon as everyone "jumps" at the same time.

so what you are saying is that if everyone simply uses that scrypt this coin will work as predicted?
why not implement that scrypt in the pools then?

What would happen is that the difficulty would go crazy. Every time the net hash rate would drop to almost 0 and then sky rocket every 3rd block. I have no idea how KGW would react to such a thing.

[MrE78]

FYI: If have been digging into CGA code a bit more, and if my tests are successful today, I plan to release code that will allow predicting and forcing anomalies on CGA.

It will look like this:
- An odd # block is found.  The script can immediately tell you if the next block is an anomaly or not.
- An even # block is found.  The script can immediately tell you what nTime values to use to GUARANTEE the next block is an anomaly.

Even if you were able to do so, you couldn't predict if you generate the anomaly or if someone else does. That is mining crypto currency... Everyone is competing for the same block at any given time. As soon as you put more hash power into CGA the longer you have to wait unitl you can find that "right moment" to jump into the network. I can see you raising your probability, but actually generating an anomaly EVERY TIME you jump into the network will not happen even if you have +50% of the network hashing power, that would make your odds 1/2 (a coin toss). So while you may of figured out a way to save your mining rigs from mining the 0 blocks, It doesn't mean that you will get an anomaly every time... And if everyone had the script you speak of then your script would go haywire as soon as everyone "jumps" at the same time.

so what you are saying is that if everyone simply uses that scrypt this coin will work as predicted?
why not implement that scrypt in the pools then?

What would happen is that the difficulty would go crazy. Every time the net hash rate would drop to almost 0 and then sky rocket every 3rd block. I have no idea how KGW would react to such a thing.

Whats the worse? We get some insane diff? It would make the coin even more elusive then. Like master ninja elusive.

[oudekaas]

FYI: If have been digging into CGA code a bit more, and if my tests are successful today, I plan to release code that will allow predicting and forcing anomalies on CGA.

It will look like this:
- An odd # block is found.  The script can immediately tell you if the next block is an anomaly or not.
- An even # block is found.  The script can immediately tell you what nTime values to use to GUARANTEE the next block is an anomaly.

Even if you were able to do so, you couldn't predict if you generate the anomaly or if someone else does. That is mining crypto currency... Everyone is competing for the same block at any given time. As soon as you put more hash power into CGA the longer you have to wait unitl you can find that "right moment" to jump into the network. I can see you raising your probability, but actually generating an anomaly EVERY TIME you jump into the network will not happen even if you have +50% of the network hashing power, that would make your odds 1/2 (a coin toss). So while you may of figured out a way to save your mining rigs from mining the 0 blocks, It doesn't mean that you will get an anomaly every time... And if everyone had the script you speak of then your script would go haywire as soon as everyone "jumps" at the same time.

so what you are saying is that if everyone simply uses that scrypt this coin will work as predicted?
why not implement that scrypt in the pools then?

What would happen is that the difficulty would go crazy. Every time the net hash rate would drop to almost 0 and then sky rocket every 3rd block. I have no idea how KGW would react to such a thing.

Whats the worse? We get some insane diff? It would make the coin even more elusive then. Like master ninja elusive.

also how long does it take to find a block? like is there not a way to force miners to at least mine so many hours days before they get their return, to stop this from happening?

[s4w3d0ff]

FYI: If have been digging into CGA code a bit more, and if my tests are successful today, I plan to release code that will allow predicting and forcing anomalies on CGA.

It will look like this:
- An odd # block is found.  The script can immediately tell you if the next block is an anomaly or not.
- An even # block is found.  The script can immediately tell you what nTime values to use to GUARANTEE the next block is an anomaly.

Even if you were able to do so, you couldn't predict if you generate the anomaly or if someone else does. That is mining crypto currency... Everyone is competing for the same block at any given time. As soon as you put more hash power into CGA the longer you have to wait unitl you can find that "right moment" to jump into the network. I can see you raising your probability, but actually generating an anomaly EVERY TIME you jump into the network will not happen even if you have +50% of the network hashing power, that would make your odds 1/2 (a coin toss). So while you may of figured out a way to save your mining rigs from mining the 0 blocks, It doesn't mean that you will get an anomaly every time... And if everyone had the script you speak of then your script would go haywire as soon as everyone "jumps" at the same time.

so what you are saying is that if everyone simply uses that scrypt this coin will work as predicted?
why not implement that scrypt in the pools then?

What would happen is that the difficulty would go crazy. Every time the net hash rate would drop to almost 0 and then sky rocket every 3rd block. I have no idea how KGW would react to such a thing.

Whats the worse? We get some insane diff? It would make the coin even more elusive then. Like master ninja elusive.

also how long does it take to find a block? like is there not a way to force miners to at least mine so many hours days before they get their return, to stop this from happening?

That is what difficulty is for. You set the "ideal" time you want the blocks to be solved (CGA is 40 sec) then if a block is solved faster (say 20sec) then the difficulty will go up. If it takes longer to solve a block then 40 sec (say 120 sec) then the difficulty goes down. KGW "smooths" out the fluctuations by averaging the time it took for multiple blocks.

[oudekaas]

FYI: If have been digging into CGA code a bit more, and if my tests are successful today, I plan to release code that will allow predicting and forcing anomalies on CGA.

It will look like this:
- An odd # block is found.  The script can immediately tell you if the next block is an anomaly or not.
- An even # block is found.  The script can immediately tell you what nTime values to use to GUARANTEE the next block is an anomaly.

Even if you were able to do so, you couldn't predict if you generate the anomaly or if someone else does. That is mining crypto currency... Everyone is competing for the same block at any given time. As soon as you put more hash power into CGA the longer you have to wait unitl you can find that "right moment" to jump into the network. I can see you raising your probability, but actually generating an anomaly EVERY TIME you jump into the network will not happen even if you have +50% of the network hashing power, that would make your odds 1/2 (a coin toss). So while you may of figured out a way to save your mining rigs from mining the 0 blocks, It doesn't mean that you will get an anomaly every time... And if everyone had the script you speak of then your script would go haywire as soon as everyone "jumps" at the same time.

so what you are saying is that if everyone simply uses that scrypt this coin will work as predicted?
why not implement that scrypt in the pools then?

What would happen is that the difficulty would go crazy. Every time the net hash rate would drop to almost 0 and then sky rocket every 3rd block. I have no idea how KGW would react to such a thing.

Whats the worse? We get some insane diff? It would make the coin even more elusive then. Like master ninja elusive.

also how long does it take to find a block? like is there not a way to force miners to at least mine so many hours days before they get their return, to stop this from happening?

That is what difficulty is for. You set the "ideal" time you want the blocks to be solved (CGA is 40 sec) then if a block is solved faster (say 20sec) then the difficulty will go up. If it takes longer to solve a block then 40 sec (say 120 sec) then the difficulty goes down. KGW "smooths" out the fluctuations by averaging the time it took for multiple blocks.

so can you not restrict connections to pools that don't allow for that? Is there no a way to restrict multipools for connecting? Or at least force them to mine for a certain period before a payout.
I am sure I read somewhere that some pools you only get your full expected return after 2 weeks of mining there?
Just trying to help for obvious reasons

[phzi]

Okay... so the code I threw together seems to suggest s4w3d0ff led me a bit astray... (and he seems to be leading everyone astray by talking about 50% mining power still leaving you with a coin-flip probability of finding a block...)

Unless I missed something (quite sure I did not), every block appears to be predictable - anomalies occur based on the CURRENT difficulty and the CURRENT block height... not the upcoming difficulty.  So there is no prediction or calculation of nTime required to determine the value of future blocks.  My testing indicates that you can reliably predict if the next block is an anomaly or not, every time, just by calling GetBlockValue from a newly created API function, using block height as a param.  No fancy code is required, and KGW doesn't even come into play here.  Anybody should be able to add a "isNextAnomaly" function to the daemon quite easily.

This means 2 things:

If someone had enough hashing power to build off their own chain (aka, 51% of the network; or using selfish-mining principles, as little as 30% of the network), they could predict the nTime required on the next block that would result in the following block being an anomaly.  Using this system, and by only building on your own chain, you could cause EVERY block to be an anomaly.  A would-be attacker (say, multi-pool), could mine the network, orphaning everyone else's blocks, and get a payout on every block at the same time.

Furthermore, there is absolutely no reason to mine worthless blocks (non-anomaly) - if you wanted to mine CGA, it makes the most sense to mine litecoin (for example) until the next block is an anomaly, and then switch to CGA, switching back as soon as a block is found by the network and the next block is not an anomaly.  The diff is low enough that solo-mining would likely find this fairly effective and profitable.

If pools, or someone solo-mining felt like it, they could also pick nTimes selectively and cause the following block to always be an anomaly (wouldn't necessarily benefit them, but would significantly increase the number of anomalies that occur).

so can you not restrict connections to pools that don't allow for that? Is there no a way to restrict multipools for connecting? Or at least force them to mine for a certain period before a payout.
I am sure I read somewhere that some pools you only get your full expected return after 2 weeks of mining there?
Just trying to help for obvious reasons

Simply put - no.  If I have the longest chain, it must be accepted by the network.  Adding restrictions around this essentially destroys the openness of the protocol, and would require some form of centralization (defeating the purpose of crypto-currencies and proof of work design).

[s4w3d0ff]

If someone had enough hashing power to build off their own chain (aka, 51% of the network; or using selfish-mining principles, as little as 30% of the network), they could predict the nTime required on the next block that would result in the following block being an anomaly.  Using this system, and by only building on your own chain, you could cause EVERY block to be an anomaly.  A would-be attacker (say, multi-pool), could mine the network, orphaning everyone else's blocks, and get a payout on every block at the same time.

Furthermore, there is absolutely no reason to mine worthless blocks (non-anomaly) - if you wanted to mine CGA, it makes the most sense to mine litecoin (for example) until the next block is an anomaly, and then switch to CGA, switching back as soon as a block is found by the network and the next block is not an anomaly.  The diff is low enough that solo-mining would likely find this fairly effective and profitable.

If pools, or someone solo-mining felt like it, they could also pick nTimes selectively and cause the following block to always be an anomaly (wouldn't necessarily benefit them, but would significantly increase the number of anomalies that occur).

If you have this code I would like to see it. What you explained still requires someone to solve the 0 blocks... The probability of a block EVER generating an anomaly is at the most 1/3. So someone has to solve those 2 other blocks before you can even think about generating an anomaly. Once the difficulty is over 3 then the probability is 1/diff so you would still need to solve the 0 blocks. You can't just have everyone skip over them and make "more" anomalies... that is impossible.

[omwtothemoon]

Unless I missed something (quite sure I did not), every block appears to be predictable - anomalies occur based on the CURRENT difficulty and the CURRENT block height... not the upcoming difficulty.  So there is no prediction or calculation of nTime required to determine the value of future blocks.  My testing indicates that you can reliably predict if the next block is an anomaly or not, every time, just by calling GetBlockValue from a newly created API function, using block height as a param.  No fancy code is required, and KGW doesn't even come into play here.  Anybody should be able to add a "isNextAnomaly" function to the daemon quite easily.

What I don't understand is how would you determine the next difficulty so that you know whether or not you create an anomaly, and more important how could you influence the difficulty? It's still completely random when someone will solve a block, so therefore it would be completely random what the next difficulty would be. You can calculate an estimate of this but  theoretically it could take forever. Could you help me, what don't I understand?

[phzi]

If someone had enough hashing power to build off their own chain (aka, 51% of the network; or using selfish-mining principles, as little as 30% of the network), they could predict the nTime required on the next block that would result in the following block being an anomaly.  Using this system, and by only building on your own chain, you could cause EVERY block to be an anomaly.  A would-be attacker (say, multi-pool), could mine the network, orphaning everyone else's blocks, and get a payout on every block at the same time.

Furthermore, there is absolutely no reason to mine worthless blocks (non-anomaly) - if you wanted to mine CGA, it makes the most sense to mine litecoin (for example) until the next block is an anomaly, and then switch to CGA, switching back as soon as a block is found by the network and the next block is not an anomaly.  The diff is low enough that solo-mining would likely find this fairly effective and profitable.

If pools, or someone solo-mining felt like it, they could also pick nTimes selectively and cause the following block to always be an anomaly (wouldn't necessarily benefit them, but would significantly increase the number of anomalies that occur).

If you have this code I would like to see it. What you explained still requires someone to solve the 0 blocks... The probability of a block EVER generating an anomaly is at the most 1/3. So someone has to solve those 2 other blocks before you can even think about generating an anomaly. Once the difficulty is over 3 then the probability is 1/diff so you would still need to solve the 0 blocks. You can't just have everyone skip over them and make "more" anomalies... that is impossible.

True, at diff < 3, only every third block can be an anomaly.  This in and of itself is pretty amusingly exploitable by miners - again, why would you mine the obviously worthless blocks?  Let someone else (a fool it seems) waste their hashing power on the 0 reward blocks.  A smart pool operator would know this too - and would be redirecting their hashing power to another coin (with or without telling their miners).  If you can't find a valuable block anyway, then why bother - you can simply _say_ you found a worthless block once and a while, meanwhile keeping the litecoin or dogecoin or whatever you are also mining for yourself.

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.

Anyway, I would honestly prefer this coin succeed.  I have made it pretty clear how to selectively mine this coin at this point, and I decided I would prefer not to release the few lines of code required to predict the next block.  CGA seems like a neat idea - what brought me here is that I was considering mining it, but as I usually do, I dug thru the source code first.  Which brought me to this conversation now.

I do hope this coin could succeed, but unless a huge change is made to the protocol, at some point, someone definitely will exploit this huge flaw.

[phzi]

What I don't understand is how would you determine the next difficulty so that you know whether or not you create an anomaly. And more important how could you influence the difficulty? It's still completely random when someone will solve a block, so therefore it would be completely random what the next difficulty would be. You can calculate an estimate of this but  theoretically it could take forever. Could you help me, what don't I understand?

You don't need to determine the next difficulty, Anomalies are based on the _current_ difficulty, which becomes evident when you read the source code (and it seems, the OP in this thread even says that pretty clearly).  Basically, (anomaly? yes/no) is determined from height_of_block and difficulty_of_finding_THAT_block.  Not difficulty of finding the following block.

You can influence difficulty by abusing KGW.  If you look into how KGW works, it's entirely based on nTime - block discovery time as a unix timestamp.  Thing is, nTime is very flexible - you can specify at least + or - 100 seconds and it will be accepted by the network.  There is nothing random about nTime - it's chosen by the miner... and nTime is "when" someone solved the block

[omwtothemoon]

What I don't understand is how would you determine the next difficulty so that you know whether or not you create an anomaly. And more important how could you influence the difficulty? It's still completely random when someone will solve a block, so therefore it would be completely random what the next difficulty would be. You can calculate an estimate of this but  theoretically it could take forever. Could you help me, what don't I understand?

You don't need to determine the next difficulty, Anomalies are based on the _current_ difficulty, which is evident when you read the source code.

You can influence difficulty by abusing KGW.  If you look into how KGW works, it's entirely based on nTime - block discovery time as a unix timestamp.  Thing is, nTime is very flexible - you can specify at least + or - 100 seconds and it will be accepted by the network.  There is nothing random about nTime - it's chosen by the miner... and nTime is "when" someone solved the block

Yeah but you can't choose when to complete a block can you? In my understanding, (I'm only looking into these things since today so forgive me if i'm being stupid) you could indeed vary nTime but therefore you would have to have solved the hash already, then send it in when the difficulty would change so that the next block would create an anomaly. To do so you would need immense hash power to beat not only everyone who tries to solve the block, but also beat the exact time you need for the next block to be an anomaly too.

[tf2honeybadger]

phzi- would you join us in IRC to discuss this further? #cganomaly on freenode.

[s4w3d0ff]

If someone had enough hashing power to build off their own chain (aka, 51% of the network; or using selfish-mining principles, as little as 30% of the network), they could predict the nTime required on the next block that would result in the following block being an anomaly.  Using this system, and by only building on your own chain, you could cause EVERY block to be an anomaly.  A would-be attacker (say, multi-pool), could mine the network, orphaning everyone else's blocks, and get a payout on every block at the same time.

Furthermore, there is absolutely no reason to mine worthless blocks (non-anomaly) - if you wanted to mine CGA, it makes the most sense to mine litecoin (for example) until the next block is an anomaly, and then switch to CGA, switching back as soon as a block is found by the network and the next block is not an anomaly.  The diff is low enough that solo-mining would likely find this fairly effective and profitable.

If pools, or someone solo-mining felt like it, they could also pick nTimes selectively and cause the following block to always be an anomaly (wouldn't necessarily benefit them, but would significantly increase the number of anomalies that occur).

If you have this code I would like to see it. What you explained still requires someone to solve the 0 blocks... The probability of a block EVER generating an anomaly is at the most 1/3. So someone has to solve those 2 other blocks before you can even think about generating an anomaly. Once the difficulty is over 3 then the probability is 1/diff so you would still need to solve the 0 blocks. You can't just have everyone skip over them and make "more" anomalies... that is impossible.

True, at diff < 3, only every third block can be an anomaly.  This in and of itself is pretty amusingly exploitable by miners - again, why would you mine the obviously worthless blocks?  Let someone else (a fool it seems) waste their hashing power on the 0 reward blocks.  A smart pool operator would know this too - and would be redirecting their hashing power to another coin (with or without telling their miners).  If you can't find a valuable block anyway, then why bother - you can simply _say_ you found a worthless block once and a while, meanwhile keeping the litecoin or dogecoin or whatever you are also mining for yourself.

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.

Anyway, I would honestly prefer this coin succeed.  I have made it pretty clear how to selectively mine this coin at this point, and I decided I would prefer not to release the few lines of code required to predict the next block.  CGA seems like a neat idea - what brought me here is that I was considering mining it, but as I usually do, I dug thru the source code first.  Which brought me to this conversation now.

I do hope this coin could succeed, but unless a huge change is made to the protocol, at some point, someone definitely will exploit this huge flaw.

Please PM me this code so I can determine if I need to make a fix.

[phzi]

Yeah but you can't choose when to complete a block can you? In my understanding, (I'm only looking into these things since today so forgive me if i'm being stupid) you could indeed vary nTime but therefore you would have to have solved the hash already, then send it in when the difficulty would change so that the next block would create an anomaly. To do so you would need immense hash power to beat not only everyone who tries to solve the block, but also beat the exact time you need for the next block to be an anomaly too.

nTime IS when you completed the block.  So yes, you definitely can choose.  and nTime is part of calculating the hash.  No need to actually submit a block at a specific time, just vary nTime as needed.

Please PM me this code so I can determine if I need to make a fix.

The code is in your own client - just call getBlockValue ?

[Molitor]

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?

[MrE78]

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.

[phzi]

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]

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.