I want to do the right thing here. I honestly do.

Is this table accurate or not Josh?



So probably April - July for current orders?

The currently estimated shipping time frame if you were to order today is the end of April or Beginning of May.

Depends on the crash. Have you sent a crash report? Which email address did you use (so that I can identify your report)?

I'm sorry about this, it will be fixed in version 2.42 which will be most likely released tomorrow.

It was caused by some Java6 code creeping in, and your phone can only do Java5 unfortunately.

At any rate that is all behind us. Like I said I have paid over 1 mil in refunds and continue to do so every friday night (20k just last friday) this list is shortening and shortening and before you know it every single person will be paid back in full.

Orders placed now will likely ship around the second half of April.

I'm just curious whether in some future there will be a very bitcoin-specific method to predict, say, if you are going to have some zeros in the output or not. So you save some cycles and jump to next nonce. The algorithm can be probabilistic, of course. E.g. if we can figure out some patterns in the internal state during hash computation.

Exactly.

Also, that point is within a year, based upon the long-term growth rate:

http://blockchain.info/charts/n-transactions?timespan=all&showDataPoints=false&daysAverageString=7&show_header=true&scale=1&address=

I calculate 345,000 per day as the level where 1Mb block saturation occurs.

Some progress

The BFL casing looks better and the power requirements seem to be a lot lower

We're talking about massive overhead here, and that's if those in upper management (above Josh) are not taking salary. Speaking of salaries, the best case scenario is that no more than a quarter million dollars has been paid out to the current staff over the past six months, based on prevailing wages and about a dozen personal (no more than 18 employees).

Blaming S.DICE is useless. That service alone currently pays more fees to the network than all other Bitcoin usage combined. As S.DICE grows, it will pay more and more fees. More with each and every new user. That is how it's supposed to be of course. The problem here is nothing else than a setting that is slowly but surely becoming a problem for overall Bitcoin usage.

If services such as S.DICE become even more commonplace, obviously we can't just raise the blocksize on their account alone. We can let the fees rise a bit and control it that way. This problem is not about S.DICE though, it's about overall Bitcoin adoption. Without S.DICE it would just take a bit longer, that however would change nothing.

Every week I gather what assets I have obtained and I distribute them to the customers starting with the earliest customers first and than working my way up to the later buyers.

The absolute minimum transaction size(1) is for single input single-output transactions. They are 192 bytes each, 182 if transaction combining is aggressively used. 1MiB/10minutes * 182bytes = 9.6tx/s

February ends in about 3 days. BitSyncom, how's the shipping coming along?

I hereby once again challenge Bryan Micon to a 100 BTC or 2000 BTC (or any number in between) wager that BFL will deliver ASICs in 2013 in escrow.

Shipping charges for a box that size with DHL is relatively expensive.

It should not take more than 24 hours to bump all our chips

I don't yet know who's dropped the ball this week on the bumping

you can't pay even if you tried they have been out of stock for a long time now.

in other fun news, there's like 4000+ "pending" orders because they have never been paid, and I've canceled another few thousand, which is not too surprising.

everyone who paid should be set as "processsing", still catching up to confirmation emails at the time of writing.