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

I agree with you. The issue CGA is facing has a lot of "if"s and "when", won't panic sell either. Sawedoff and the other devs will find a solution, I'm very confident.

I don't know what you guys are talking about but I'm not selling my CGA. If anybody else needs to panic sell their CGA and they don't see the depth in the book, PM me. This is ridiculous. Still only 15000 something CGA. I don't think there was any need to panic. Now how are you going to buy back in cheaper if nobody else is panicking like a noob?

how about time added to the equation?time is always changing..

i'll wait till s4w3d0ff wakes up  

good work on CGA geeks out there..

if CGA would achive this = rarity + elusiveness/randomness/anomalous + resistances to commercial farms, ASICs and multipools.....the best coin ever!

I too have no issue with changing the algorithm - I really don't think it will create a loss of confidence, quite the reverse it will demonstrate commitment to a long-lived interesting coin.

Regarding KGW, sounds like we should drop it, but I really don't know enough to say - happy either way.

Current net hashrate is random

No it doesn't ... GenerateMTRandom isn't random... it's a pseudo-random function that when fed the same seed will always produce the same result.

First of all I think it is outstanding how you guys have been discussing the issues with regards to the found problem. A real example of how it should be done in the crypto society. No BS just get on with it!

There was a fourth option and you didn't even contemplate choosing for that and that was to just let this coin die and not tell anyone. So a lot of respect to you guys and thx again phzi for joining us on irc and helping to brainstorm possible solutions. I believe we got a solid dev team that will go the extra mile to get CGA back on the road!

I am not sure whether I would prefer KGW or not, not enough technical insight. I leave the decision to you guys.

Also I don't mind changing over to the N algorythm as it has advantages and makes us a lot more future proof against the bigger farms/ multipools.

@phzi it appears that it does use a random assigned int to discern the payout..

That's a major problem then... If the block reward must be known before the block is solved, then any attempt to obfuscate said reward is inherently flawed. Again, I don't know nearly enough about how this works to know if this is possible without coming up with a completely new system, but is it in any way possible to rewrite the code to eliminate that restriction? Because, barring some sort of insanely clever idea, that's the only way we're gonna get rid of this exploit.

I'll admit I've only skimmed the source code, but I still don't get why this is such a bad thing. Wouldn't lots of coins have this same problem?

Easy to implement? No...

Delaying the block reward is a lot more complicated then it sounds, and requires some serious modifications to the core code and protocol.  Something like that is more likely to be developed for a new coin, if it ever is. (I have been considering doing this myself for a while... but as tf2 said, I have a day job that keeps me quite occupied).

Perhaps we could just delay the payout for two blocks? and use a computed random but verifiable value from from previous blocks?

phzi aside from what cant be done do you have any suggestions that would be easy to implement that would work?

Because of how bitcoin (and all altcoins based on it so far) are designed, you MUST know the block reward BEFORE the block is hashed.  Every variable reward coin so far is predictable (you know the reward before the block is found).

Aww... I was so excited that I had an idea, I forgot to read everyone else's suggestions. Also, I'm not good at reading C++ and I don't know enough about the existing CGA code to know exactly what the hell you're talking about, so can you tell me if your code is determining the reward before or after the block is hashed? Sorry if that's a stupid question, but that's the only possible problem I can see right now-- if the reward outcome of block 2 is based on the hash of block 1, it's just as easy to predict whether block 2 will pay out as it was before.

Does luckycoin actually do this?  I don't see how you can possibly use a rand function in GetBlockValue... it would essentially make block rewards unverifiable at up to the miner to choose (and the miner would obviously always choose to pay himself the largest possible value).  My glance at the luckycoin source doesn't show any randomness as part of the GetBlockValue function.  Simply put, GetBlockValue MUST return a verifiable and repeatable value, or else you are breaking the entire system.

Yes... this is exactly what smart multi-pools like MC or WP do - mine only the valuable blocks.  And is what they would likely do to this coin if it got big enough.  For most variable rate coins this doesn't matter too much - Doge, Lotto, Leaf, Karma, Kitteh, etc etc - because the "non-valuable" blocks still offer a reward and are worth mining.

Moving to another algorithm has nothing to do with ASIC resistance.  It has to do with multi-pools and other large scrypt pools and their ability to attack the coin.  Switching to a less used algorithm negates the risk that multi-pools pose should the coin grow much larger.  Essentially, because of this coin's current design, a "51%" re-org attack (which would only require about 30% of the network hashrate due to the use of KGW) at diff>3 would allow an attacker to make EVERY block an anomaly.  Or, even worse, would allow someone to say mine 2 blocks (one of which would always be an anomaly), cause the next block to not be an anomaly, and then resume the attack when the next block will be an anomaly (basically the blockchain would look fairly normal, but only the attack would get paid and everyone else would get nothing but 0s).

And as an aside, you're crazy if you don't think scrypt ASICs are going to have a huge impact on GPU mining this year...  if Alpha-T manages to deliver, you can expect scrypt network hashrates to basically double.  And that's only one company.

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

Thats in essence what i was getting at with the prevHash

I'd like to suggest a different block reward system: Instead of reward every x block, reward every block, but devide the reward (1) by the diff. If the diff is less than 3, 3 is taken.

Examples:
Diff = 1
Block Reward: 0.333333333

Diff = 10
Block Reward: 0.100000000

Diff = 200
Block Reward: 0.005

This would have some advantages:

• The rewards wouldn't change at all over time.
• Every block pays (rewarding long-time-miners).
• If a multi pool hits the coin, the diff raises within 2 blocks, the multi pool wouldn't be able to mine much coins.

Moving to another hash alorithm is not advisable in my opinion because:

• Scrypt is pretty ASCI resistent, even if there are scrypt ASICs now, they are not comparable to GPUs because of their very low resell value. Scrypt ASICs are not faster than GPUs.
• Changing the hash algorithm would require a hard fork or a relaunch of a coin. Relaunch would kill every confidence in the creators, changing the algorithm will result in people jumping off because mining would be more difficult (e. g. scrypt-n-factor).

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.