⚒[CGA] Cryptographic Anomaly - The Elusive Coin⚒

[phzi]

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

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.

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?

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

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.

[awesomeperson451]

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

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.

[phzi]

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.

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

[sublok]

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.

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

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?

[phzi]

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?

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

[ralph12]

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?

[awesomeperson451]

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.

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

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.

[sublok]

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.
 

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

Code:

int static generateMTRandom(unsigned int s, int range)
{
random::mt19937 gen(s);
random::uniform_int_distribution<> dist(1, range);
return dist(gen);
}
 
 
int64 static GetBlockValue(int nHeight, int64 nFees, uint256 prevHash)
{
int64 nSubsidy = 88 * COIN;
 
if(nHeight < 50000)
{
const char* cseed = prevHash.ToString().substr(8,7).c_str();
long seed = hex2long(cseed);
 
int rand = generateMTRandom(seed, 100000);
 
if(rand > 30000 && rand < 35001)
nSubsidy = 188 * COIN;
else if(rand > 70000 && rand < 71001)
nSubsidy = 588 * COIN;
else if(rand > 50000 && rand < 50011)
nSubsidy = 5888 * COIN;
}
else
{
// Subsidy is cut in half every 1,036,800 blocks, which will occur approximately every 2 years
nSubsidy >>= (nHeight / 1036800); // Luckycoin: 1036.8K blocks in ~2 years
 
const char* cseed = prevHash.ToString().substr(8,7).c_str();
long seed = hex2long(cseed);
 
int rand = generateMTRandom(seed, 100000);
 
if(rand > 30000 && rand < 35001)
nSubsidy *= 2;
else if(rand > 70000 && rand < 71001)
nSubsidy *= 5;
else if(rand > 50000 && rand < 50011)
nSubsidy *= 58;
}
 
return nSubsidy + nFees;
}

[oudekaas]

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]

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

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.

[mxq]

Current net hashrate is random

[tertius993]

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.

[arielbit]

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!

[arielbit]

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

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.

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

[brokedummy]

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?

[wzttide]

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?

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.

[oudekaas]

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?

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 concur!

unique coin, a coin that adapts to it's popularity, great devs and as I can see it is a good investment opportunity whilst only few people are aware of this coin and once the devs find a way around the issues and combined with the scarcity of the coin it will most likely increase the price substantially! Like any investment there is a risk involved, but if you didn't like risk you probably wouldn't consider investing in altcoins anyway.
On all the alts available there is a majority of coins that is offering nothing new apart from being an addition to the pile of crap that is already out there and people will still invest. So I don't worry about a coin with this potential and an honoust team.

Next to that the reason why I got to CGA is that I have been scanning through all the altcoins available and this was the only one I thought that is new and has a uniqueness to it and therefor potential.
I am assuming others will soon follow!

[tertius993]

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?

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.

Likewise, I must confess when the discussions started yesterday I pulled all my buy orders, but didn't sell any.  However, having thought about it and followed the discussions with interest I have now re-instated them and picked up a few coins this morning.

As said there is a risk here, but hey, let us live while we are alive!

[R9Generation]

Whats the matter right now?

I don't understand why people want to change the code again? Its pretty "normal", that this coin is rare, this is a GOOD thing.
It produces fear, when the chain is forked again, especially when people could loose coins wtf. I don't want to loose any coins, and I don't see a necessarity in a code change, could someone explain to me please?

[miner_andy]

Whats the matter right now?

I don't understand why people want to change the code again? Its pretty "normal", that this coin is rare, this is a GOOD thing.
It produces fear, when the chain is forked again, especially when people could loose coins wtf. I don't want to loose any coins, and I don't see a necessarity in a code change, could someone explain to me please?

I agree, you are taking a gamble here. Not many people check forums like this every day to see if they are running everything properly.  The coin is already on markets, and it simply needs to get stable.   If this is another major code change, it needs to be the last.