Nope, haven't played with nv yet, and certainly not with teslas.
But looking at the spec and architecture...
14 CUs with 64kB L1/LDS per CU and 768kB global cache (128k per 64-bit memory controller). 32 ALUs/CU, clocked at 1.15GHz
6970 = 24 CUs with 64kB L1/LDS per CU and 512kB global cache. 64 ALUs/CU, clocked at 880MHz
nv L1 can do 2 reads/clock, so... wild-ass guess... might end up at 30kH/s or so.
Of course the lack of a native rotate won't exactly help, scrypt is sha256 (we know that one...) and salsa20, in which *every 2nd op* is a rotate.
so... probably more like 20kH/s.

Probably because these "issues" aren't issues unless you have a ancient P4 or something.
My PhenomII is happily hashing along at 20kHps while increasing system power usage at the wall by 108W.
2^32 * 0.0926 / 20000 / 3600 ... about 5.5h/block
so ~108tbx/day for 2.6kWh/day
*checks btc-e* 108tbx = about 0.83 btc less fees, let's say 0.8
at 4.82/btc ... $3.85/day less power... about $3.20
Yeah, can't see why people are throwing as many CPUs as they can find at it...

CFLAGS="-whatever -somethingelse" ./configure
make clean; make

or just edit the CFLAGS= line in makefile after configuring

I like to always make clean so there's no objs from previous compilations with different flags hanging around

Just pushed some more scrypt manglery, 3.62kH/s/core with -march=amdfam10 -O3

That's a problem inherited from cpuminer, some distros *cough*redhat*cough* don't package libcurl.m4 in curl-dev which causes exactly this :/
You can easily get around it by commenting these lines out though, since pretty much everyone with linux is running curl already
[/quote]


model name   : AMD Phenom(tm) II X6 1100T Processor
cpu MHz      : 3600.000

gcc -v
gcc version 4.6.1 (Debian 4.6.1-13)

uname -a
Linux buildhost 3.0.0-1-amd64 #1 SMP Tue Sep 20 07:03:13 UTC 2011 x86_64 GNU/Linux

If you're on amd64 linux, might wanna try my mangled scrypt cpuminer: https://github.com/ArtForz/cpuminer
compiled with CFLAGS=-O3
3.28 kh/s/core on a 3.6GHz PhenomII
2.73 kh/s/core on a 3GHz AthlonII
2.40 kh/s/core on a 2.7GHz Sempron 140

Another tiny problem, all nonparallelizable puzzle schemes proposed so far require the puzzle creator to keep a secret from the puzzle solver. How exactly do you do that in a decentralized system?

Dunno, it's still plenty profitable around here, and that's at $0.30/kWh...
Unless you have a P4 or pay like $1/kWh ... how on earth do you end up with a loss?

So.. it went from "pretty much nothing" to "3 times pretty much nothing"?
There's only 300k in existence so the "bullshit index" of total coinage (brixage?) times current trading price went from 50 to 150 btc...

That also shouldnt become a major issue, merely the current implementation scaling badly there.
To increment the extraNonce in the coinbase transaction, we rehash every transaction in the block and rebuild the whole merkle tree, so the whole thing ends up scaling with (blocksize * requestrate). Adding the obvious optimization of storing the opposite side for the merkle branch and only rehashing coinbase and its merkle branch, we need an additional (log2(#tx in block) * 32) bytes of memory but scale roughly with (log2(#tx in block) * requestrate) for getwork.
At something like a current average block (~10kB in ~20 transactions), that comes out to ~240 vs. 8 sha 256 operations for 4Ghps worth of work.
Scaling to visa-level 10 kTX/sec (that'd be 3GB blocks containing ~6M transactions ...), it's ... about 50 sha256 operations for 4Ghps worth of work.
So for a pool roughly the size of the current network that'd be... for current tx volume 24k sha256/sec vs 150k sha256/sec for 10k tx/s.
And using something like "miners increment block time themselves", this can be cut down by another factor of 60.
Scaling this for increasing hashrates due to Moore's law... well... that applies to both sides.
So for the getwork+PoW side, I just don't see any hard issues coming up.
I expect to see way bigger problems on the transaction handling side of things scaling to such massive levels, assuming every tx has 2 inputs + outputs on average, you'd be verifying about 20k ECDSA sigs/second and on every block you're marking ~12M outputs as spent and storing ~12M new outputs in some kind of transactional fashion, probably just the list of current unspent outputs would be on the order of 10s of GB ... ugh.

Currently 76 bytes? Not using the getwork protocol. A getwork response without http headers is already close to 600 bytes... to transfer 76 bytes of data.

But yes, optimally it'd be 76 bytes (+ a simple header).

There'd be ways to cut that down even more, version is constant, nBits only changes every 2016 blocks, hashPrevBlock only changes on a new block, why send those every time?
Another option, allow miners to update nTime themselves.
work submits could be cut down in pretty much the same way, requiring only hMerkleRoot, nTime and nNonce. If there's too many increasing share difficulty would be trivial.
So, a simple more efficent protocol would have per 4Ghps:
hMerkleroot + nTime every 60 seconds or whatever the tx update interval is, hPrevblock every 10 minutes avg.
hMerkleroot + nTime + nNonce every second

at 100% efficiency, diff 1 shares and with some overhead that comes out to around 1 byte/second avg send and 45 byte/second or so avg receive for a poolserver for 4Ghps of miners.
Or about 24kbit/s send and 1Mbit/s receive for a pool the size of the whole current bitcoin network. Yeah.
If hashrates increase in the future, increase share difficulty by a few powers of 2 and you cut down the incoming rate accordingly...
So for the pool-miner interface, you can scale it up quite a few orders of magnitude before bandwidth becomes an issue.

For the network side, scaling to transaction volumes that are allowed by the current max network rule of 1MB/block, we need to receive and send the tx in that block and the block itself, that comes out to... 53kbit/s average.
The 1MB block size limit should be enough to fit about 4 tx/second average.
So... your average home DSL will become a problem when scaling up more than an order or magnitude above the current limits, we'd *need* some kind of hub-leaf setup beyond that, and assuming the hubs are decent servers you could easily get another 2-3 orders of magnitude. ... which would be roughly on par with visas peak tx capacity levels...
So doesn't look like bandwidth would become a major issue.

Back of the envelope based on last 100 blocks ... network is about 1900kH/s
That's ~100 or so high end CPUs or somewhere around 2000 old/slow ones...
= Still way too small to be more than a small speedbump for an attacker willing to shell out some $ for EC2 instances or with access to even a "tiny" botnet.

The problem with a "typical" CPU ... no such thing.
8-core Opteron or modern high-end Xeon > 20kHps, your average old P4 space heater ~ 1kHps... while using about the same amount of power.
CPUs tend to follow Koomey's law (which roughly says power efficiency doubles every ~15 months).

This is getting OT, but judging by the currently seen client versions on the network you'd probably need a prewarning/transitional period measured in years to have a good chance at all old clients upgrading in time...

Back on the original topic, ran some sims, doesn't look like there's a hard point where a faster difficulty adjustment using the original integrator becomes unstable (short of going to extremes so it slams into the limits from normal fluctuations in hashrate), "merely" makes difficulty adjustment more noisy. Near identical results with a sliding window and scaled factors (looks smoother, but pretty much the same deviation from optimal (as expected)).
For a interesting practical experiment in "just how short can you make the window and how extreme the adjustment", look at GeistGeld chain (retarget every 16 blocks, adjustment limit roughly * / 1.8. that comes out to a adjustment limit of */ somewhere around 1e30 over 2016 blocks). Somewhat surprisingly it more-or-less works so far...

Thats the weird thing, currently it'd be way more profitable to cpu-mine tbx than btc, yet no decent botnet in sight.
At current btc/tbx difficulty ratio, a botnet cpu-mining tbx instead of cpu-mining btc "loses" somewhere about 0.00005 btc/tbx
Eyeballed scale factor... cpus are about 1000 times faster at btc hashing than tbx hashing...
tbxdiff / btcdiff * roughhashscalefactor * blockrewardfactor
0.042 / 1.69M * 1000 * 2 ... around 0.00005
*checks* btc-e ... best bid: 0.00158btc/tbx.
so only like 30 times more profitable to cpu-mine tbx currently...

Wrong, it's a forward-and-backward-incompatible change, as at the first retarget 2015 and 2016 have a good chance on disagreeing what the next target should be.

Namebrix?

Yup, 128KiB, which goes for the "small enough to easily fit in L2, big enough to not be able to fit more than a few instances in a GPUs on-chip memory/caches" point.
If I could change the parameters again I'd probably add more margin and go for scrypt(4096,2,1) = 1MB of randomly-accessed-array per instance.
Still small enough to mostly hit L2 on a CPU, but even on future GPUs with several MB of fast on-chip cache/store you could only fit a few instances.
Should do about 300 hash/s on a high end cpu core, at least 50 or so on a crappy one, so it'd be barely fast enough to not hinder block verification *too* much (you'd have to add some protection to avoid having your node spammed with bullshit blocks, but nothing too fancy).
It'd also pretty much eliminate Cell as a contender (SPEs local memory is 256KiB...) and completely eliminate low end FPGAs (LX150 only has ~ 512KiB total block ram, and external memory is *way* too slow to make sense).
Going for L3 or external memory is imo a bad idea in this case as that's a shared resource = running a miner on even one core pretty much kills memory subsystem performance.

Didn't think of that, if the avg hashrate fits it'd be a "duh" case. Also "decently cheap" to pull off. *and* it would explain why he scaled down after block 2016 and completely stopped after 4032.

Contemplating this some more... the "pure fork" part had ~4.2s/block, average nonce was ~235k, unless I'm missing something and assuming cpuminers algo for nonce generation, average hashrate/box should be simply avg nonce / avg time ... that'd come out to about 55kH/s/box...  need to do a test to see if this assumptions holds, if yes it looks closer to 4-5 high end quad-cpu boxes. At least that'd be a lot less "weird" than a single cpuminer instance running on like 80 cores.

edit: nope, stock cpuminer, tbx-miner and my cpuminer fork keep one workitem *per worker thread*, so those nonce values would mean someone was running 4-5 *threads* at about 55kH/s each... very odd.
Hmmm, or using a patch that does the "split single workitem into chunks of nonces to hand off to miner threads" thing, pretty sure there's already a fork of stock cpuminer doing just that and merging that with tbx-miner should be trivial.
So with that scenario... our attacker has access to at least few beefy servers, some understanding of bitcoin, can apply patches and recompile. (iirc there's like a 3-line patch to bitcoin to implement a stupid "fork existing chain after block X" floating about on the forum somewhere...). Sounds like your run of the mill BOFH. *ducks*

Well, relying on block timestamps seems somewhat pointless, there's no reason the attacker couldn't fake the timestamps in his forkblocks to be "close enough" to the real chain to leave no obvious gaps.
So... how do you figure out which chain was "first"... if your node is live at the time it's pretty easy, but what if it was off for a while and when it gets back there's now 2 similar-length chains? Solving the 51% problem in the general case without creating single points of failure or new vectors to mislead nodes is ... hard.