looks like the network is back up to 1.3 gh/s after all the ddos noise

They will likely just be resold as spartan6 chips, you need all new boards with gddr5 in order to efficiently mine with scrypt

Bfl needs to figure out how to make a sha256 asic before it can do that.  An asic for ltc will probably cost a lot more to develop with a much smaller roi than for a sha256 asic (theyll probably only 2-3x more efficient and about as fast as video cards). Couple this with the fact that the ltc asic can only be used to mine ltc and you're looking at very little incentive to develop an ltc asic in the next year or two.

umad

Nah, the K20 will still be pretty slow.  It's designed mostly for DP FP ops and not integer ops.  It's actually still slower than a 7970 there, too.

bump

can you get pramipexole or ropinirole?

another gem from inaba

lol

i have a python script like that in the mining thread in my sig

N enhances memory consumption with computational enhancement while r simply enhances memory consumption.  You further slow your algorithm down with N as compared to R.  It's really a matter of preference when you get to very large memory consumption (>1 MB), because at that point you're using RAM and you're going to see a severe slowdown.  Additionally, chacha20 should generally be used in place of salsa20 because it's faster and considered exactly as secure.

N becomes a much bigger deal (as far as I can tell) if you use multiple block cipher hash functions because you will be doing many more of these block cipher hashes.  if you are using a lot of block cipher hash algorithms (see below) increasing r would be ideal because you may then actually face significant slowdown.  see theorem 1 for ROMixH computational time from the scrypt paper.

skein is secure, the reason it wasn't considered for SHA3 was because it's really computationally intensive.  the same goes for blake.  sha3 (keccak) has extremely high throughput as compared to either of those algorithms (or SHA256, which is similarly slow), hence its selection as sha3.

if you want something that is a total pain in the ass to crack on a parallel machine (asic, gpu) a high N or r value (resulting in 16-256 MB of memory use) and skein/blake for the block cipher will suffice.  the more block ciphers you add in tandem (eg SHA256(BLAKE512(SKEIN(data, key))) the worse it gets for asic hashing without strongly affecting runtime performance because need an additional 20,000-50,000 circuits per hash algorithm.  but as most of your slowdown is in memory with high N or r values, you can really add as many secondary block ciphers as you like without it making the algorithm a lot slower.

basically all the SHA3 final candidates are reasonably good algorithms, just keccak was the only one that had a ridiculously fast throughput as compared to SHA256.  but in this case speed isn't all that important because the size of the data is so small.

the major advantage to using daisy chained block ciphers in scrypt is also that in the event one block cipher is determined insecure, you still have the others as a failsafe.  the minor advantage is increased asic difficulty.

if you're interested on working on an implementation like this let me know, i would like to make a block chain based on an algorithm such as this along with some other protocol tweaks for economics.

n=1024, r=8192, and p=1 should be a second or too in C, probably a little longer in js (200-300%).

c implementations are here: https://github.com/floodyberry/scrypt-jane

i posted a lot of results in this thread: https://bitcointalk.org/index.php?topic=122256.0

if you're aiming for high security for the key, you should uses a high r value (4096, 8192) for salsa20/chacha20 and skein for the block cipher as they're both really slow and expensive.  there's only a tiny amount of data to be decrypted here, and even a 5 character password that is random should be a nightmare to solve.

you can select each card individually in cgminer with "-d #" where number is the # of the device if you wanna test them card by card

ozcoin down too ;________________;

eh, it's not a huge deal.  most of us have enough mh/s to solo mine so a 51% attack is still outrageously hard.

coinotron, litecoinpool, and notroll are all down.

burnside's pool is still up, though.

you will only be able to hit aggression 13 in cgminer because the thread_concurrency is so low.  for really high aggressions you need to be using reaper.  in theory the card should do 600-650kh/s at ~1 GHz core / ~1500 MHz RAM but folks are having trouble achieving this.  i'm not totally sure what the problem is, the other GCN cards scale linearly with GCN cores when you get the speed settings correct (7770, 7870).  you may want to use reaper with a thread_concurrency of 21000 and plot a curve of the change in change rate with the change in speed of core and memory as I did.  i'm still waiting for someone to plot this out for a 7970 since i don't own one at the moment.

you can try adjusting gpu_threads to 4 or 5 too and see if that helps

what cards?

$12.50 usd/btc * 0.0066 btc/coin * 50 coins/block * 256308 blocks = $1,057,271 USD

PoS as implemented is by block number, not time, hence time attacks do not affect it.  It looks like you can just mine a PoS transaction at 1 diff after a certain number of blocks have passed

What I don't understand so much is how they're signed for securely