Stalling tactic because the owner was worried peoples' investigations were getting too close to comfort?

We'd also ideally want the blk0001.dat and blkindex.dat from the compromised server... has anyone asked him for these yet?

That depends. If there are 7 million of - for example - a particular brand of washing machine and 1 million of them burst into flames, that obviously makes the remaining 6 million rather less valuable. (Also, most of the bitcoins lost so far have been stolen rather than destroyed, so the number in circulation hasn't decreased that much.) On the one hand you have the decrease in supply, and on the other loss in confidence in Bitcoins as a result of the heists.

You're trolling, right? Because the reason the same isn't true of the USD is fairly thoroughly explained in the bit of the article BitcoinPorn quoted.

I'm interested in finding such code too but so far I haven't had any luck. The most popular simple pure-C crypto library is libtomcrypt, but it apparently uses optimisations that are incompatible with the elliptic curve used by Bitcoin.

Anyone that can't understand how to SSH into anything is not going to be able to assess just how likely the online wallet they're using is to be full of gaping security holes - especially ones of the subtle Bitcoin-specific kind that MyBitcoins claimed they had. They certainly won't know how to use tools like Whois to figure out how easily the owner could run away with their hundredsd of thousands of dollars worth of bitcoins, and probably won't realise the implications of (for example) dealing with companies registered in Nevis. Why should we be encouraging people to act in a way they can't rationally assess the risks of again?

Ah yes, of course, because it'll help increase the value of our own bitcoins. Why did I even bother asking.

As I understand it, MyBitcoin didn't accept deposits that came directly from generation transactions - the 50 BTC would never get credited to your account no matter what happened. Most Bitcoin wallet sites have the same limitation.

Not only that - if they were the victim of double-spend attacks, they should be able to provide copies the duplicate transactions spending the same input, and probably even the two blocks with different versions of the same transaction. (The official Bitcoin client stores orphaned blocks it saw that used to be part of the main chain pretty much forever.)

A double-spend with only 1 confirmation might actually be doable in this case, though, because an attacker can just keep trying repeatedly until they succeed at little or no cost to them, and because synchronization of blocks between the big mining pools isn't very good even at the best of times. Tycho's refusal to give the IP address of his Bitcoin node for Deepbit to any of the other pool operators is actually quite damaging from what I've heard.

This is basically correct apart from one thing: if you leave the checksum digits the hacker can reject the majority of their hacking attempts after just doing a single round of SHA256, which is much cheaper than having to compute the address or public key their guess maps to. Ideally you should remove the checksum totally and insert the vanity section somewhere in the rest of the private key, but that's kind of tricky to reverse.

I really like the descriptions of Bitcoin scalability in your other set of slides; they fairly succinctly point out the issues with scaling, and how the proposed solution to dealing with large transaction volumes inevitably mean Bitcoin will become highly centralized.

Edit: Also, now I've found the correct set of slides - how would bitcoinfs by injecting data into other users' transactions work? The signature obviously can't sign itself, but the rest of the transaction script is signed - you'd have to somehow inject data into the signature value itself. Which I guess might be doable actually...

(Oh - and the suggestion of generating private keys from passwords is interesting, because Bitcoin users are obviously already using a less secure version of this using a single round of SHA256.)

That reminds me, do you regret being willing to take down the thread about how Matt (a.k.a BitMole) tried to weasel out of paying you for work done now?

That's not why MtGox got criticism. MtGox released specific statements that not just turned out to be premature and wrong, but that they had to have known were false at the time; for example, there's no way they could honestly have claimed both that it was just a single account that was compromised and that they had enough Bitcoin funds to cover their deposits because even from the outside it was easy to see they didn't have enough Bitcoins to cover the amount in that single account, let alone everyone else's deposits.

You're assuming that the technicians in question know about bitcoins and MyBitcoin and have authorization to act on their own without specific orders from Tom Williams. I suspect that neither is the case; he's probably talking about hosting company staff rather than anyone he actually employs himself, even if he's not outright lying.

The trouble is that the capital-owning class that becomes a robot-owning class will have no reason to permit everyone else access to the products created by those robots, because they'll have nothing to offer in return. (Actually I can think of a handful of things they could offer, but most of them are really not very pleasant and there wouldn't be enough demand for them anyway.)

They could do... assuming that the government chose to serve the interests of the populace at large rather than a handful of very wealthy, very powerful individuals. This requires politicians to act against their own rational interests though; the handful of powerful individuals are much more capable of damaging their political career than the populace at large is, even though in theory everyone can vote.

Hmmm. Actually, that doesn't seem to quite solve the problem. Try something like this patch. Causes slightly worse timing elsewhere on XC6SLX75 so it's actually a net loss there, but you may be able to avoid or work around this. (Edit: Also, KEEP is probably not the right constraint to use here; it will cause unneeded registers and logic and RAM we want to elimiate to be kept.)

Looks like it's true.

You'd think so, but the window for exploiting this kind of vulnerability once it's been publicly exposed generally seems to be too small for anyone to actually do so profitably. Generally the person publicly announcing it only provides a minimal proof-of-concept that's enough to show the issue exists and a lot of effort is still required to use it maliciously.

If you do it that way you can't change the total amount paid out by the outputs of the transaction to match. (While I think there may be a mode that doesn't sign the outputs that opens a huge security hole.) It's probably better just to create a fresh transaction.

Of course they couldn't. That would require convincing over 50% of the population in a significant number of areas to vote for exactly one suitable candidate in each, with no campaign funding, despite the mass media being against them and attempting to discredit them, whilst somehow avoiding both fake "people's candidates" and corruption of the genuine ones that did get elected. If not enough people vote for the candidate, the ones that did risk causing a worse candidate to get in than if they'd stuck to the best of the mainstream choices. Worse still, at the point in his scenario where the unemployed masses are essentially being imprisoned there's no need to even convince them their vote means anything - it's not like they can rise up in revolt with their every action monitored for hints of "terrorist" activity, and hardly anyone would question this monitoring initially.

You also need to take into account aspirational effects - a lot of people are willing to vote in ways that benefit the rich and powerful at their own expense in the hope that one day they'll become rich and powerful, no matter how slim that hope. This phenomenon is a massive obstacle to grassroots political reform, but it might actually encourage investment in something like the Australia Project IPO even if that did offer nothing more than an idea.

It's actually very interesting that in this story voluntary self-organisation turns out so much better in the end than central government fiat.

While intellectual property could also pose an issue, the problem here is physical property: specifically, the robots themselves, the equipment needed to manufacture them, the raw materials to feed all this, and the land from which the raw material are mined. If all of this is in the hands of said robot-owning overclass, everyone else is screwed unless they can take it from them by force; I seem to recall most libertarians are against this.

If you haven't tweaked ISE's setting for the minimum size of shift register to infer yet, you probably need to do that. (By default two or more registers in a row are automatically replaced by a shift register.)