Ah, I was curious about that. (Was looking for a merged mining pool frontend to go with an experimental backend I was working on a couple of months ago. There didn't seem to be any open source ones out there.)

The key part there is the "ETA 6 months". The problem with BFL's original claims wasn't that 1GHs at 20W is impossible, but that it made no sense for a company to suddenly appear selling boxes that achieved it because it requires ASICs with long lead times and huge up-front costs. If you're going to be producing this kind of ASIC, it makes sense to announce it up-front in order to discourage anyone else from trying to manufacture them too and cutting into your profit margins.

This is probably a bad idea. I think it might allow the calculation of the private key from the chain code, which you presumably don't want. (If you have a signature, the value of k used to make that signature, and the data being signed you can compute the private key from them. That's why it's so important that k is both randomly generated and different for each signature.)

I think Maged my be over-optimistic in thinking we'll get any kind of meaningful answer out of Mt Gox. In similar previous cases they've done things like make vague insinuations that the user is a criminal with no actual details given to anyone, including said user.

No idea, they're not actually shipping yet. Obviously XC7K325T costs about $1,500 from Digikey but it's always possible the smaller chips might offer better value for money.

There should probably be a T on there actually.

Well, I did a synthesis run ages ago using the preliminary support for the smaller XC7K70 and ISE reckoned that could hit 250 MH/s - and this was just by throwing some Verilog I already had lying around at it and using the default options. Only took about 20 minutes or so too. (This is based on post-place-and-route timing and so should hopefully be fairly realistic.) Obviously the XC7K70 isn't actually available yet, and ISE apparently tends to have problems with multiple-miner designs so this may not scale up to larger chips, but it seems reasonably promising.

That's not quite right; as I understand it the reason the internal switching rate is so high is the 1.05 GHash/s of SHA-256 in itself. In theory it's inherent to this kind of high-speed hashing. (Not that there's really many uses for this sort of hash rate other than Bitcoin mining anyway...)

Would this incentivize miners to do tricks with fees that are harmful to the health of the network? Currently, if you don't include enough fees in a transaction for the big miners to pick it up you have to wait for the old transaction to be forgotten and resend it with the same prevouts. If miners can steal coins that are double-spent in this way, they may have an incentive to deliberately delay transactions in the hope that the sender resorts to resending with larger fees, allowing them to steal the coins.

Well, if we're being pedantic I don't think Luke-Jr actually has one yet, he just connected remotely to a BFL computer with one attached like I did. He pre-ordered one but they're obviously not actually shipping yet and presumably won't be until new units with beefier regulators come in.

Probably more like somewhere in the range of 5-20 MHash/sec and I'm not entirely confident about that. It's a bit difficult to actually estimate performance that accurately.

That's roughtly of the impression I got, actually. It's still kind of murky, but the murkiness seems to lie partly in the way the US handles incorporation and partly in Wyoming for some reason having a register of corporations that doesn't necessarily list anyone actually involved in said corporation. (Which is really quite daft.)

Also, I managed to get remote access to a machine with a BitForce board attached for the purposes of testing my poclbm-based miner, and came to a few conclusions:

• The board does appear to run at the (reduced) speed stated, though obviously I could actually be mining on wreckage from Roswell or something
• I'm getting the odd hash verification error, not sure if it's a bug in my code or something else
• Either something weird in their network is mangling long polling horribly or there's a truely bizarre bug somewhere

(This is a slight overestimate - I calculate closer to 850 MHash/sec including stales due to the broken long polling, which for some reason masterpool.eu isn't showing. This roughly aligns with the performance I was told to expect.)

It appears that Nancy Hernandez is most likely an employee of Pacific Registered Agents, Inc, the corporation acting as their registered agent in Wyoming. Slightly murky.

This was actually one of the things that worried me at the time; if you didn't realise that Bitcoin mining would use so much power it seemed unlikely that you would've designed the boards with power circuitry capable of handling its power consumption. (The various Spartan-6 boards have generally been designed with regulators capable of handling the maximum possible power usage.) It may have been a good idea to be more open about the problems you were experiencing.

I actually managed to blow up a wall wart testing the 25 MHash/sec bitstream mentioned in my sig, and that was obviously a lot smaller-scale than your BitForce boards!

Don't suppose anyone would be willing to give me a copy of the protocol specs and access to a box or VM with a board connected? I already have a poclbm-based FPGA mining client lying around that could almost certainly be adapted. (It does fancy things like pool failover, roll-ntime support and testing found nonces against the previous work unit as well as the current one for increased efficiency.)

Well, there's a software section on the website that appears to have software downloads and instructions, though I've no idea if that's the latest version and obviously don't have the hardware to actually use it.

Ah yes, I remember Luke-Jr mentioned he'd been writing mining client code for it that he thought you might be using for your test. It's unfortunate that it seems to be taking so long to get working code. (If it helps, I released some poclbm-based code a while ago that could probably be adapted to the BitForce boards with a little work, though it's hard to be sure given that they haven't released any interface specs or code. It's not a general purpose solution but...)

No. There's intentionally no way of tying transactions to blocks, because block chain reorganisations or even just blocks arriving sooner than expected would cause payments to simply disappear. Solidcoin 2 has a trusted block scheme based on trusted parties inserting transactions into the block chain and it failed exactly because transactions can't be tied to blocks. Your suggested method also opens up a whole bunch of new 51% attacks.

There are two problems with this. Firstly, not everyone would necessarily make a good scientist or engineer and not every graduate job needs that kind of employee. (Some of them would honestly be better off employing a Women's Studies or Black History graduate.) Secondly, scientists and engineers have been having trouble finding jobs.

It wouldn't. Remember the MyBitcoin incident? I don't think they ever followed through with their promises to release more information about what happened either.

My entire point is that the test doesn't actually prove that, you were aware of the reason why it doesn't prove that and published a test plan with precautions designed to prevent that specific method of cheating, and you came to the conclusion that it did anyway. That's kind of unfortunate. It wouldn't matter if you'd given people enough details to draw their own conclusionsin the first place - after all, it was just a preliminary test - but the information just wasn't available to us.

You can get down to a few hundred milliseconds round-trip time over 3G with a fair wind and a bit of luck, or tens of milliseconds over wireless. Depends partly on how much BFL controlled the environment that the tests were carried out in. I don't even bother polling my toy mining FPGA for results more than a few times a second; doesn't really matter that much. (Also, it's convenient in an FPGA design to keep the nonce counter rolling continuously and not bother to reset it for new work units, so any delay is likely to be lost in the noise across two trials.)

In a way that's quite odd - even though it's entirely possible to build hardware that does what they claim, they've been putting off the isolated testing time and time again and we still haven't seen evidence that it can mine at all. Admittedly it'd be rather expensive to build the hardware and require unusual technical knowledge, and scammers have been known to cut corners before, but still.

This might possibly be a reasonable response if the "but the computer could be connecting to mining hardware elsewhere" problem was just something I came up with after the test that you didn't think of beforehand. It wasn't. It was important enough that your original test plan went to great lengths to explain why this would be impossible - obviously you knew people wouldn't believe a test that didn't block this kind of outside communication. Yet somehow you concluded that their box could actually mine shares based on a proof of concept test that didn't exclude this potential cheating, and failed to mention the change so that people could judge for themselves how reliable the test was, instead leading us all to assume that the test proved more than it actually did.