Update will be coming later this week, expect CUDA miner support and a few bug fixes.

Hi guys,

Updates should be coming later this week.  There's a lot to rewrite in the draft paper, and I need to run it by some people first.

Notably, iddo mentioned an alternative PoS system and, reading it now, I came up independently with a similar solution over the past month.  If it works it may allow four minute confirmation and solve the 51% vulnerability, which I'm sure would be desirable for a lot of people.  But it needs to be figured out further and a lot of people will need to go over it to ensure it's secure.

I want to rewrite the hashing algorithm so that the hash itself uses all the different algorithms.  I've also been going through research papers to try to find the algorithms that use AES code fragments (modern CPU friendly), runs slowly on FPGA implementations (almost all SHA3 candidates like this were eliminated for this reason), and then to implement the hash algorithm and ensure that the following parameters are met:
1) That approximately half of the cycles in the scrypt loop are spent computing hashes of various types, while the other half are spent in memory access steps.
2) That using scrypt with parameters of N that are not 2^n is okay -- hashes compute fine if you remove the error checking in the implementations in C that I have, but I can't be sure that this does not lead to any problems until I step through the code.
3) Goal throughput of 5 KH/s or more average on a CPU to make sure verifying that verifying the blockchain is not impossible for the end user client.  N range will be adjusted accordingly.

As far as GitHub is concerned, there won't be a fork started until the theory behind the chain is solid.

Eventually a kickstarter may be formed and I'll aim for $50,000 or so to pay potential developers.  There's no way I can do this on my own, I'm paid right now for unrelated contracted research so I won't have a ton of free time over the next 12 months to dedicate to this.

I'll go through this thread later this week and try to respond to everyone's comments and suggestions.  Thanks for the interest!

For the love of God, do not buy 7970 DC II or 7970 DC II Top cards...  I just got a couple through the forum here and I managed to kill one in two days.  It now crashes upon mining or upon booting Windows with it plugged into the display.

Apparently it's a known problem:
http://www.overclock.net/t/1220328/behardware-asus-hd-7950-directcu-ii-fault-report

I just checked out the VRM temps on the remaining card I have that still mines okay and they were sitting at 100C+, while the card itself was undervolted to 1038 mV.  Just awful!

If you have one of these cards do not run it at more than 950 mV mining or you'll wreck it pretty quick!!

1st page

It can easily be implemented sooner -- for instance, the vote bits in the block header could be used to adjust the rate at which supply distribution decreases.  This could be implemented as soon as the currency begins -- but it was my guess that during the initial few years miners would act as selfishly as possible to try to decrease the reward, so I wasn't sure if it was a good idea or not.

  Update coming this week, wrote my last exam, hopefully everything went okay.  I want to talk to one of my friends at Microsoft who works on data storage and structures about the scalability problem, too.

It was used for benching.  For the amount of traffic they get they might get that much from ads.

http://www.techpowerup.com/183026/AMD-Radeon-HD-7990-Clock-Speeds-and-Core-Config-Confirmed-Tested.html

Your card might actually be crashing.  Try turning up the voltage or turning down the clocks.

Do you feel you are at release candidate level yet?  I want to add this to guiminer-scrypt when it hits maturity.

If you sell me one I'll gladly do so!  I can also give you investment money too, but I need some specs before doing so (cost to produce, scaling, efficiency, etc).

Did you try rescanning the wallet with ppcoind?

There are already FPGA implementations of both SKEIN-256 and BlueMidnightWish-512, they both run fairly fast.  A GPU implementation would be trivial.

I'm working on a more FPGA/ASIC proof hash algorithm for MC2, you can use that when I'm done with it if you want.

Yes, that's the obvious answer.  It remains to be seen if the Litecoin network will encounter orphan problems as time goes on with 1 MB blocks.  Bitcoin is already having problems with 10 min blocks, which is kind of scary.  Litecoin should probably have adjusted the block size to 256 KB.

Maybe increase the block size to 10 MB and try 5s too, it'll be a contest for who can achieve the highest rate of orphans    A double-spend filled adventure!

30 watts?  Jesus, that's 6 times the power draw that BFL said the jalapeno was supposed to have

That means that the 50-60GH/s miner from BFL will consume 300w+, which really isn't much different from the Avalon (and well beyond their specified range)

It's weird that he would say

The implementation of scrypt for Litecoin requires you to do the equivalent number of SHA256 hashes to the number of execution of the salsa for loop.  If the Litecoin implementation of scrypt includes SHA256 (the algo bitcoin uses) and memory intensive salsa stream cipher rounds, why would it be easier than just implementing SHA256?

http://www.evanjones.ca/unicode-in-c.html

But you can also just pass it as binary by converting it to hex reading from a UTF-8 file containing the string...

Yes, I will be back to write about this soon, just really busy until after Monday