Possibly closer to 1500 BTC total, though that obviously doesn't make much difference because...

After poking my wallet a bit, I'd like to increase my previous bet to:

20 BTC
1FXWXErhhfdrGvu65earaRss5wNcyigupL

Still not entirely sure what Matthew's point is with all this, but I suspect it may not work out the way he's hoping it to.

Ah, normally that means that the FPGAs aren't being fed new work fast enough. It might help to add "--icarus-timing=2.4" to the cgminer command line. Also, does cgminer complain about not getting work from your pool fast enough?

Ah, that could be the bitstream bug I just fixed, though it doesn't generally seem to cause problems with the 200 MH/s bitstream. Please do reflash the badly-performing board with the new dcmwd4e bitstream when you get back home and have got a moment - this is a pain for me to test because the issue takes a while to show up and affects some boards more than others.

Curious. Have you been getting a lot of warnings from cgminer about your pool not providing work fast enough? It's not just the U/m that's underperforming, the MH/s reported by cgminer is lower than it should be and I think that's generally caused by a slow pool.

OK, thank you! I see Glasswalker has spotted this and replied already. Hopefully (touch wood) with the fixes above and/or the new 210 and 220 MH bitstreams I've already released performance should be comfortably over the line and you won't regret paying out. My testing board is actually at 855 MHash/s of a theoretical 860 based on the U/m reported in MPBM right now, though it's only been running for 12 hours. I believe ebereon was seeing similar speeds on his farm with the bitstream this is based on before it started falling over, so (fingers crossed) the new one ought to be able to manage that stably on a decent proportion of boards.

I've actually released full-performance bitstreams (dcmwd4e) with the fix now and am waiting to hear how they work out. My own testing is looking really, really promising though.

Ouch. No wonder you didn't have any time for bitstream development.

I somehow doubt that filharvey was getting 7% a week, since that would require a large investment and as far as I'm aware pirate hasn't paid out any of the larger investors yet.

Yeah, it does require reverting back to the 1.3 or 1.5 controller. No doubt ebereon and others will have some news as to how stable it is in a day or two, might be worth waiting until then. (Glasswalker will probably also be coming out with faster bitstreams at some point but he's really busy right now.)

In this case, it's actually easy to confirm that Shadow383 is correct - it's GPUMAX. I should really have googled the address myself:

OK. I think I've managed to track down an issue in my previous bitstreams which sometimes caused them to fall over and stop producing shares after a while. You can find the fixed bitstreams at: http://www.makomk.com/~aidan/shortfin-dcmwd4e-20120822.7z They should hopefully reach the same initial hashrates and invalid rates as the dcmwd4c ones did, except without the long-term stability issues that plagued those. Again, this issue affects all my previous bitstreams and for maximum stability I recommend that everyone who's using any of them upgrades to the new ones when it's convenient to do so. Plus, the 210 MHz and 220 MHz bitstreams might actually be usable this time around!

(It appears some - though not all - of the problems I was blaming on the DCM were actually caused by me failing to change a synthesis option that needed changing, meaning a particular finite-state machine was less robust than it needed to be and kept getting wedged in an invalid state. Whoops.)

Never mind.

Apparently using freshly-generated coins too in some cases, e.g. this payment http://blockchain.info/tx-index/16885882/c2d0742df8df67c0507fd270b3c262f8a0118ba3a9b91357c83a04d952d0a32d - very interesting.

Edit: not just freshly-generated coins that weren't mined by any pool that blockchain.info is aware of, but ones that were mined with a very unusual 47.5 BTC / 2.5 BTC split in the coinbase payout, which means custom software.

Edit 2: and yep, that entire payment comes from coinbase transactions paid to http://blockchain.info/address/1PSf86KnLuzM7Ris5kDhTEZwooR3p2iyfV - which represents 5+% percent of the total Bitcoin hashpower right now at a quick estimate. I have a bad feeling about this.

I'm in the process of testing a new bitstream which should improve matters a lot. Stay tuned!

The amount of cash it costs to buy a particular number of shares on GPUMAX is quite a bit more than the expected value of that number of shares, though. Miners wouldn't be willing to supply it if it wasn't.

Of course, if he's running a ponzi scheme he almost certainly doesn't have the option to pay everyone back because he doesn't have enough funds. His only options are to carry it on to the bitter end and default without making any money or to default before he's exhausted his reserves and run away with the rest.

The only real benefit of independent implementations here is that it means more people have actually looked at and understood the way Bitcoin works. For instance, if you think about it forrestv had to look at the details of the merkle root calculation in order to implement p2pool. (For that matter, I'm the only person who even admitted to having worked out the vulnerability from the patch for it, and that was largely a due to having developed code for poolserver work generation before.)

I think a clever attacker could've carried out an attack that wasn't any more noisy than double-spending through rewriting history using any other method.

There's probably a fair few sources of suitable ready-made cables out there because they're used (for instance) to connect Atmel AVR programmers to development boards and those are insanely popular with electronics hobbyists. At least, it looks like a 2x5 pin 2.54mm/0.1inch pitch IDC connector to me.

Well, the issue has now been announced by forrestv, who discovered it: https://bitcointalk.org/index.php?topic=102395.0 Design flaw in the way Bitcoin computes merkle hashes that allows an attacker to create invalid blocks with the same hash as valid blocks. Can be used to carry out a 6+ confirmation double spend with essentially no computational resources. Very feasable attack from what I can tell.

Is it actually legal to register corporations under an alias in Texas? Somehow I doubt it.

Scam victims have been known to rationalise their experiences in some really interesting ways, including blaming it on the people that warned them.

Just like with BTCST, discussion of GPUMAX is filled with people who insist that they're absolutely certain what purpose it serves and that anyone who can't figure it out or who claims it's used for pool hopping or money laundering is an idiot, yet refuse to actually say what they think it's for.

Heh. Pirateat40 was actually hinting in IRC that he knew he was going to have to shut the thing down even before bitlane's withdrawal request and that's why bitlane's withdrawal was slow.

Hmmmm. It does look that way. Interesting.

Edit: Looks like it's more complicated than that. Take a look at CTransaction::CheckProofOfStake - when calculating whether there's enough stake for the current difficulty, only the stake in the single transaction output used for that attempt counts. This is necessary to prevent various kinds of cheating. However, when calculating the reward I think you can indeed include stake from multiple transactions. This should mean that your expected number of and income from stake blocks over any given period of time depends only on the number of coin-days worth of coins older than the 30-day limit you have, and not on how that's divided up.