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

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.

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

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

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

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.

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

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.

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?

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.

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

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

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

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.

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?

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

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.

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?

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 can u not somehow restrict the mining in such way that miners are forced to connect longer before they get a reward?
Like basically if they want to mine this force them to at least connect for a week? so that hopping onto blocks is not an option?

like somepools it takes a long time before you get your actual expected return, can we not built that in.

Why? This is well known stuff... if a dev doesn't know this about their own code, then there is certainly an issue.

Anyone can find this out by reading the source code and running a few simple tests.

wzttide is looking into it right now. I'm talking to him on IRC.

EDIT: It's working again, sounds like the stratum server got stuck temporarily.

What happened on http://mpos.cga.anomalypool.com/?
This site does not seem to work.