Quote from: sublok on February 24, 2014, 07:05:26 AM

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.

Quote from: tertius993 on February 24, 2014, 07:38:18 AM

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.

Quote from: wzttide on February 24, 2014, 07:27:03 AM

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.