What makes you think he'll actually refund anything?

I saw a website the other day (forgot the address, sorry) that just keeps a running statistic for how much it would cost to launch a 51% attack on bitcoin via hardware manufacturing. Right now it was something like $350m. That seems like a lot (depending on how you look at it) but if bitcoin was to gain the global acceptance that we all hope it will someday, it's not a lot at all. There is a big incentive to be the "federal reserve" of bitcoin, and a government entity might be willing to shell out that kind of money to do it.

Price competition has not only hit, it's going to scare off other competitors. The value of hardware is going to crash so quickly after september that it's likely that many people formerly planning to startup an ASIC venture have now tossed those plans entirely, too much competition. And now people are worried that Nov/Dec asics might not ROI at all.

Mining should always return to the point where the cost of electricity is just under the cost of mining bitcoin, long term.

If I were an ASIC company wanting to stay in this biz long term rather than going for the homerun, facing all these fence-swingers right now, I'd be making incredibly high efficiency ASICs, air cooled, and plan to sell them for a slight markup and make up the difference on volume. A 10gh USB stick for $20 would be a market winner, even as the large asics begin dying like flies at the end of this year.

Here is one portion of scrypt core:

for (i = 0; i < 1024; i += 2)
{
      memcpy(&V[i * 32], X, 128);

      salsa20_8(&X[0], &X[16]);
      salsa20_8(&X[16], &X[0]);

      memcpy(&V[(i + 1) * 32], X, 128);

      salsa20_8(&X[0], &X[16]);
      salsa20_8(&X[16], &X[0]);
   }

As you can see, you have to memcopy 128x8bit = 1024 bit. If you have those 64 bit rambusses you will need 16 of them to make this operation work in one cycle. This has to be done 2 times per loop, looping 1024 times (in full scrypt algorithm). You cannot hard-unroll this loop as you can with SHA256. You see, even if you had rambusses of 1024 bit, you need at least 2048 ram operations per scrypt. Assume your hardware runs at 500MHz. Divide this by 2048. Even then you cannot get higher rates than 250 kh/s. (...and you will never see an FPGA with 1024 bit rambusses)

Just in case anyone didn't see the latest update from BitSyncom, via their website:

"chips have arrived via other routes as previously announced, we are shipping them out at the rate of 40-50k on a daily basis at the moment, in addition to the ~150k or so that went out, another 40k was shipped today. There is multiple channel which the chips are arriving from various packaging facility to minimize downtime. Please bare this in mind: while we had backup/multiple packaging companies and various delivery routes, things still will go wrong. There is also testing that must be done, then they can split, packed and sent to the EZP coupled with their CN-22 and be on their way. We will provide more update as they come. In addition, the trade-in and refunds are being processed."

Meh.

Yes, there was a significant increase of hash rate for FPGAs in SHA256, but this is an effect of the possibility to fully unroll the SHA256 core. It then goes one hash per clock. MHz = MHash/s

This is algorithmically impossible for scrypt as this algorithm was specially designed to be resistant against that. In most linear algorithms you have two possibilities: Get a speed up with the need of more ressources, or save ressources but achieve a lower computation rate. If one side decreases, the other one increases and vice versa. Not so for scrypt. Both sides increase nearly equally.

Here you can see a scrypt demonstration on FPGA with hashrates ~ 2kh/s. (You need to be very experienced to make it twice that speed!):

https://github.com/kramble/FPGA-Litecoin-Miner

There are Litecoin ASICs already available on the market, no need to develop with FPGAs. They're called GPUs. Contains up to 1600 processors each, every processor has its own memory. Hashrates up to 800kh/s, you will never get a performance like that with FPGAs. Scrypt is not a question of how much memory you have, but more on how much memory portions you can access independently in parallel. Already available scrypt implementations on FPGAs have shown that hash rates of 4 kh/s per core can be achieved, 6-8 fitting into one FPGA, consuming 30W. Even if you increase throughput by factor 5 (....this will not happen), it can't compete GPUs.

To clarify, being late can't be seen as a scam .... it's common knowledge.

On Litecoin we do have a memory add-on for CM1 going into manufacture. I don't want anyone to think we have Litecoin mining now running on CM1. We don't and won't for at least some time to come give our current workload. This new module will simply be available anyone that wants to try and implement it on a CM1. On the big boards we will come back to Litecoin at some point but no promises when that might be.

+1 The litecoin aspect is really interesting and could be a gamechanger in that currency. I imagine that would bring more success than an bitcoin ASIC would - seeing as theres a lot of run on the marked for those units lately. But noone seem to have been going forward with a litecoin setup - not in public that is.

Your math is wrong. Primecoin mint rate reduction is quite slow you won't see daily production drop below 10K any time soon (diff 12 = 10K daily production, a couple thousand times more difficult than the current difficulty 9.75).

Primecoin is designed to sustain a prosperous mining market long term, yet still have stronger scarcity in the short term (first 4 years) than bitcoin's design. These are conscious design choices. The release was pre-announced 10 days in advance, to ensure no advantage to anyone and a fair initial participation.

There's this:
http://cryptometer.org/
Only some coins there, but you can click "All Days" and see all the history. Although, some of them seem to be outdated... some of them are up to date.

Hogwash. The burden of lost/late/never shipments should not be pushed down the line to the last batch. That is ridiculous. Each batch transaction is clearly independent of the others. They each had to meet a chip quantity ordered before purchased, they each have their own order date, and they each have their own Avalon order number. The only thing in common between the batches is they are organized by the same group buy leader -- that doesn't mean they should automatically become dependent on one another.

By placing an order for chips not in the first few batches I have no intention of shouldering the burden of order problems on previous batches, just like my batch purchase shouldn't be impacted by order problems in other non-steamboat group buys. If you expect the last batch or two customers to get get stuck holding the bag if any batch doesn't fulfill, then clearly those batch customers should have received a steep discount compared to the other batches. Insurance like that isn't free.

I don't think you all understand how the probability on this works. Here is some math from Statistics 101. Let's say the probability of any given shipment never arriving is 15%.
If everyone shares the burden equally then there is a 15% change you'll be SOL. Sounds fair to me. Equal burden for all.
If you push the burden down the line to later batches, then:
 the probability that batch 1 won't receive chips drops from 15% to 0.0011390625% (.15 * .15 * .15 * .15 * .15)
  - AND -
 the probability that batch 6 is screwed jumps from 15% to 62.285% (1 - [.85 * .85 * .85 * .85 * .85]).

Again, there is no way it would be fair for later batch customers to have all of the burden of lost/late/never shipments. That burden should be spread out across the batches evenly.

Couldn't you say exactly the same about bitcoin a few years ago?