cool, well on a side note, when i try to send a transaction it says its too large? Is there a fix?

Good to see you brother, try deleting your peers.dat file (along with the blockchain) and set the addnodes to "connect=" in your config. Download the entire chain from those 2 nodes then change the connect= back to addnode= it should do the trick.

nope - top says need to update still 31 weeks behind

And no connections?

You put in the addnodes?

addnode=192.99.37.224
addnode=107.170.166.51

I tried both and I am running Mavericks (OS X 10.9) so I started with the one for 10.9 but had no luck. The one for 10.7 isn't working as well.

I don't have one I am afraid, indeed I don't think there is an answer.  The part of the bitcoin protocol which requires that the reward of every block be known at the time you start mining the block means that the original concept of the coin simply cannot be achieved.

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.
 

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

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.

This can't work - what would prevent a miner from simply SAYING they got a random number number that causes a remainer resulting in an anomaly?  You can't have a truely random function in the getBlockValue function, or else there is no way to determine if the reward listed in a given block is actually valid.

This is why the "random" coins like Doge all use a pseudo-random function with a known seed value - the result is reproducible (side effect: predictable).

The only way around this that I have envisioned is a massive protocol change where block rewards are granted in the NEXT block to the miner of the previous block.  But again, this is a massive protocol change and unlikely to get implemented in any already existent coin.

--

Changing the algorithm is a decent solution that prevents large pools and multi-pools from abusing predictable block rewards, and allows KGW to be dropped (KGW, while useful for small coins in smoothing out difficulty, actually enables other attack vectors like time-warp "51%" re-org attacks that require significantly less then 51% of the network hashrate).

This seems interesting... please expand because I don't quite follow. I see you randomizing the difficulty, network hash rate and nTime (which may be a bit over kill) to get a new remainder.