What happens to a buyer who pays in bitcoin and never receives his product?  A vendor that has one or two bad transactions might get away with this, but on a large scale, they will not.  How is this any different from other assumptions of fair play with this or any currency?  If large scale theft goes completely unchecked, then the currency loses value.  Taken to the limit, it has no value.  The "1 to 2 hops" I originally mentioned certainly aren't "gazillions" of transactions.  I've read your responses to "comeonalready" in other threads, don't waste you're time trying to troll me, just stick to reality. 

While an amusing scenario to envision, there's no resemblance to the situation here.  In this specific case, we are talking about people that have the actual logs of coins mined, transferred, and coin addresses involved, so there's really no anonymity at all.  We are talking only about the specific case where the theft is directly traceable, as confirmed by the combination of protocol traffic and the resulting blockchain records.  You can't get "arrested" in any case, but nobody has to honor your payment.  If an exchange's terms of service state that it will not exchange currency that can be traced to an address involved with theft traceable to logs and the blockchain there's not much you could complain about.  They can always simply send your BTC back to you and refuse to exchange it.  The currency has no value unless it can be used to purchase goods or services, or to be exchanged for other currency.  There's no need to "arrest" anyone.  This is not particularly different from spam filtering or blocking DDOS atacks when they are detected.  It isn't worth the trouble to deal with small scale theft, but on the scale of spoofing an entire mining pool, or several pools as we have experienced this week?  Yes, I think there's an interest.  The status quo is an undeveloped wild west, and it would be foolish to think that large scale spoofing and theft will go unpunished in the long run.

You say it's not possible, but if you have the complete list of transactions, it is possible to deny exchange to other currencies.  You can't prevent exchange of coins within the currency, but there's no reason anyone has to willingly accept a bitcoin that was originally stolen from a miner in exchange for a traditional currency.  In reality, the value of bitcoins today is only as good as what you are able to exchange them for in terms of real goods and services, or in traditional currencies.  While a thief may steal a bitcoin and pawn it off on someone else, here's no rule that says an exchange has to accept that bitcoin address for exchange with a dollar, or other currency.

They can do that as much as they want, but all transactions can be traced back to the blacklisted address because they are all in the blockchain.  Any address that is only 1 or 2 hops away could be considered "tainted" by the blacklisted address...

If you could track to to a bitcoin address, it ought to be possible for the crytpocurrency community to "blacklist" an address used by thieves.  Since the transactions have a complete history in the blockchain, an exchange could reject transactions that are traceable back to an address involved in theft, fraud, etc.

Hi,
  If you edit the Makefile.am and remove the "-ldl" and rerun the autogen.sh, and make, does it link, or not?  Does your system have a libdl.so or libdl.a in /lib, /lib64, or /usr/lib or /usr/lib64?

Cheers,
  John

All miners that respond to "reconnect" messages sent by the pool are impacted, which is most of them....

Kalroth just posted  patch for his miner:
  https://bitcointalk.org/index.php?topic=433634.3220
  https://github.com/Kalroth/cgminer-3.7.2-kalroth/commit/d78f8c896010049a06275db13a2816c0e201e41e

I see people are now working on patches for other miners (just got back from dinner so I'm catching up):
  https://bitcointalk.org/index.php?topic=433634.3200

It's happening on a bunch of pools.  So far I've heard: cleverminer, wafflepool, multipool.us, and others that I'm forgetting just now.  The wafflepool thread has some extensive discussion about it, protocol captures, etc.

I assume cudaminer honors reconnect requests because a quick 'grep shows that it has logging code for a reconnect message.  Given the man-in-the-middle/spoofing attacks going on with several of the pools, there should probably be a way to tell cudaminer not to accept reconnect requests when started with a particular command line flag, and optionally to log the reconnect data or report it in some way.

I have been seeing this on wafflepool recently.  In my case, this occurs for periods ranging from 5 seconds, up to as long as 3 minutes.  I hadn't observed this behavior until wafflepool changed their stratum code about a week back, but I now see it happen about 6 times per hour.  I sent protocol logs and idle info to the wafflepool guys and they are looking into it.  Some other NVIDIA users have seen the same issue at wafflepool, but I hadn't previously heard of anything like this going on with other pools.  The wafflepool guys are looking into potentially tweaking their stratum code, but I haven't heard anything concrete yet.

Are you cross compiling or anything unusual?
What do you get if you list your system libraries, libdl.so and libdl.a should be part of your Linux install, hrere's a listing on my CentOS 6.5 box:
orion - johns:/home/johns/cudaminer/mine % ls -al /lib/libdl*
-rwxr-xr-x. 1 root root 17892 Nov 21 15:13 /lib/libdl-2.12.so
lrwxrwxrwx. 1 root root    13 Feb 27 22:28 /lib/libdl.so.2 -> libdl-2.12.so
orion - johns:/home/johns/cudaminer/mine % ls -al /lib64/libdl*
-rwxr-xr-x. 1 root root 22536 Nov 21 15:38 /lib64/libdl-2.12.so
lrwxrwxrwx. 1 root root    13 Feb 27 14:16 /lib64/libdl.so.2 -> libdl-2.12.so

Just sent you a relevant section of my log for one of these cases that occured at 13:40pm central time today.  I can also send you full logs if that isn't enough.  I emailed it to your gmail address.

Yes, I have been logging both the protocol and the GPU utilization for the last 12 hours or so, so I should have several examples of where this occurs in my log.
Right now I see it happening again at about 1:40pm central time...idle for about 1 minute and 45 seconds before it recovered.  No errors from cudaminer when it happens, but no activity either.  Same cudaminer binary worked fine for the last 2-3 weeks before the stratum change.  I can send you a PM with a gzipped copy of the logs if you like.  I sent you a short log snippet already last night, but sending the whole log may be more useful for you.

I should also add that the observed idle periods are occasionally quite long, often 15 to 20 seconds.  This seems like a very long time to me.  When it occurs, no timeouts or errors are printed by cudaminer, so from its point of view there is no problem.  This behavior began when wafflepool switched to the new stratum code the other day.  Prior to that, I never observed this behavior before.

I have also observed the same behavior on 3 machines, and I have been collecting logs of GPU utilization through nvidia-smi which correlate to the cudaminer log I'm also keeping.  I ran cudaminer with "-P" so I've also got a lot of the network protocol.  I captured this happening probably ten times last night.  It occurs on machines that are also connected to different stratum endpoints.  So it's not just an issue with useast, or uswest, for example.

At work we have a number of NVIDIA QuadroPlex boxes that are cabled to a card that goes into the host machine.  The cables on these boxes are something approximating 2m in length.  The host card contains some kind of PCIe bridge chip and somewhere, either on the host card or in the external box backplane, there's a PCIe switch to allow the two GPUs in the box to connect to the single PCIe slot in the host machine.  I have no idea how special the hardware is there, but clearly the 2m long cable doesn't cause problems in that scenario.  They use VHDCI cables for the link from the host card to the external box.  I know that the USB-based PCIe riser cables are nothing compared to what NVIDIA did for the QuadroPlex, but the QuadroPlex might be considered the top-end version of what is feasible.  Besides the QuadroPlex boxes, there are various vendors that sell other variants of high-end external PCIe backplanes with on-board PCIe switches and the like.  The only problem is that all of these external boxes tend to cost $5k to $10k for an empty box of PCIe slots and power supply.

It would be interesting to see how well these low-cost PCIe risers would work if they used a higher quality cable more along the lines of what NVIDIA does for the QuadroPlex.

Since Christian brought up the HF frequencies:  One thing that's not so good about building the "milk crate" or "open air" machine that lots of people do is that with no computer case, there's no RF shielding, and you're likely going to emit all manner of RFI, polluting the radio spectrum with all kinds of terrible hash.  As an amateur radio hobbyist, I would beg that people take that into consideration and consider ways to do better than leaving the boards just laying on a shelf.  If you've got a pile of motherboards sitting on a shelf, some conductive mesh (e.g. for window screen) fashioned into a faraday cage around the systems would help null that out...

The NVIDIA Titan cards have 6GB, and they tend to hover close to a kilobuck.  The Xeon Phi (in its current form at least) is no match for state-of-the-art GPUs.  I mentioned Xeon Phi only to provide context that multiple vendors are already building hardware with large high bandwidth memories now, and that the memory capacities (again, from multiple vendors) are expected to go up dramatically in the near future.
I understand the sticker shock, $2K to $4K is costly, but then that's what the high-end ASIC boards cost for crypto currency mining.  To keep the ASICs out, there just has to be a commodity option that's price-competitive, and there are definitely high-end GPUs that, for a memory-bandwidth-bound algorithm at least, should still be more cost effective than low-volume ASIC boards for any non-trivial memory capacity.

I'm not convinced that the only way to parallelize these algorithms is the way that it's being done currently.  It is often possible to write GPU codes where several threads or even a whole warp/wavefront work collectively on an algorithm step.  I haven't looked at the details of scrypt-chacha specifically, but I wouldn't be surprised if there are alternative algorithm formulations other than the one you refer to.  The top-end GPUs today have 8GB to 12GB of RAM.  In the next two years, there will be GPUs and other GPU-like hardware (e.g. Xeon Phi) that will have significantly more memory than they do now, likely in the range of 32GB.  I've read analyst articles that expect that Intel will put at least 16GB of eDRAM onto the next Xeon Phi (though likely on its own separate die), a much larger scale variant of what Intel is already doing for integrated graphics.  Next week is NVIDIA's GPU conference, perhaps there will be some public announcements about what they're doing for their next-gen GPUs.