On the other hand, it seems Pirate "investors" may have been making financial decisions on the assumption that Matthew will pay out. So there are some people that will have actual non-hypothetical losses if he doesn't pay out but Team Ponzi most likely aren't amongst them.

Personally, I've carefully refrained from commenting on whether I think he'll pay or not. There are some good reasons for this which you may be able to spot if you think about the issue.

It appears so. Notice how the inputs to the transaction were much, much smaller than the outputs; Bitcoin doesn't let you create coins out of thin air like this except in coinbase transactions, and those can't created more than 50 BTC.

Ponzis are apparently delicate things, especially in the early days - one big investor pulling out early on can spell doom for them. I'd be more inclined to believe he was just a pass-through if it wasn't for the fact that Maged and co. investigated his finances through the blockchain and seemed to reckon they were consistent with a highly profitable standalone ponzi scheme.

Of course, that's not actually secure unless the original page is served over https: too, because an attacker could inject their own Javascript that syphons off the credit card information.

The default rating displayed seems to be the global one. In any case, I believe that pirateat40 had positive ratings from a number of trusted members of the community including nanotube. The problem is that the fact that someone's carried out small Bitcoin-Paypal exchanges honestly doesn't mean they're trustworthy to handle a 500,000 BTC investment that looks strangely like a Ponzi. I believe various Silk Road customers may also have discovered this problem with ratings the hard way.

I suspect there isn't much of a market for exotic specialized equipment on the Bitcoin forums somehow; small community and all.

Which, of course, quite a lot of people fail to do.

They have no control over the ones they've shipped, true. However so long as the amount of ASICs they've kept back is a reasonable amount larger than the amount they've shipped they'll still be able to carry out the attack, and for various economic reasons we might expect this to actually be the case for any manufacturer of Bitcoin mining ASICs.

Have they even finished shipping BFL Singles that were ordered prior to the Bitforce SC announcement yet?

What's more, this gives miners an incentive to collude in delaying large transactions with no fee or a small fee in the hope that the sender will try resending it with a fee, allowing them to confiscate all the money. That's probably not a good thing.

Well, that estimate's going to be quite a bit lower than the actual total loss because it's based on the assumption that pirateat40 was paying out interest using other investors' deposits. So on top of that 200000 BTC loss, investors will also have lost some of their initial principle in the form of profits gained by other investors.

Actually, I think Pirate owes about 100000 BTC just to BTCMAX and their account-holders alone.

I seem to recall that in the previous Bitcoin-related Linode compromises the hacker had to reboot the VPSes in order to gain access to them. That'd lock them out of any encrypted data but not an unencrypted backup, not to mention the fact that it made the fact the VPSes had been compromised really obvious afterwards.

Mine's a bit annoying in that you can't actually build it from source and get the same level of performance that the released bitstreams reach. There's a source archive in the dcmwd4e release, and if you unpack that, download and unpack the .ncd from http://www.makomk.com/~aidan/shortfin_dcmwd4e_ed_ncd.7z, and add the unpacked .ncd to the supplied project as a SmartGuide file (right-click fpgaminer_top in the left pane in ISE, select SmartGuide, point it at that file) you ought to be able to get speeds that are good enough for testing purposes. If you're willing to do a long SmartXplorer run you ought to be able to get the speeds up to release levels; I didn't because it's a bit hit and miss and would delay the release by quite some time.

Edit: As I've said before, honestly you might be better off using the hexanchus branch if you want to build from source right now ("git clone https://github.com/makomk/Icarus.git; cd Icarus; git checkout -b hexanchus origin/hexanchus"). Slightly slower than the released bitstream, but I think it's the fastest of mine that can actually be built from source, and you should literally just be able to open the project file up in ISE and build it.

Edit 2: hexanchus requires different DIP switch settings though; on all the FPGAs where you'd normally set switch 2 to off, you also need to set switch 4 to off as well.

This isn't entirely true. As I know you're fully aware, if an ASIC manufacturer with much greater than 50% of the network hashpower has implemented some new secret hashing algorithm, they can declare that the Bitcoin network is switching to their new algorithm and that they'll use their 51% to prevent any transactions ever confirming for users that remain on the old one. They can't force everyone to change to their algorithm, but they can render the existing one useless quite easily.

Does the idea of deferred consumption necessarily make economic sense though? I mean, you certainly can't do it with labour - you can't just say, oh, I don't need those 40 hours/week of this person's labour right now, I'll defer using it for a few years. If no-one uses that labour right now it's gone, wasted, poof, and if you need labour in the future you're basically using new resources that would've been there regardless of what you consumed in the past.

In fact, let me just quote from an article I saw linked elsewhere:


The same argument applies just as well to Bitcoins as it does to any other investment scheme; we're still trading our consumption right now for future consumption that we have no rational reason to believe should be available to us at a reasonable price. Doesn't matter whether the currency is inflationary or deflationary or goes-sidewaysey because the problem isn't with the tokens we use to represent resources, the problem is with the underlying resources themselves. Actually, I suspect this might be even worse with a deflationary currency like Bitcoins.

Funnily enough, IIRC we know he was actually using Paypal to trade bitcoins for USD and vice-versa in #bitcoin-otc. It's quite likely that was just an attempt to gain the trust of the community though.

Actually, with the standard client you can spend bitcoins you've received after only 1 confirm.

Doesn't surprise me. Few people have Cyclone-IV FPGA boards and the most common one apparently can't supply enough power to the FPGA to handle Bitcoin mining at higher clock speeds. Couple that with people being unwilling to risk their expensive boards through overclocking and I don't think anyone's actually tried it yet.

Neither did this part: