The problem is double-spending. You have to check the whole blockchain to make sure an address hasn't already spent the coins it's trying to give you. I had thought of adding explicit back-references to the last block/transaction that an address is referenced in so that you only have to backtrack to specific blocks to find a trustworthy balance for an address, but it would be a major protocol change and old addresses from before the change would still need the full ~13GB of blockchain. You'd also have to trust the metadata a bit more; it's easy to check all transactions, but trusting that clients and miners have properly verified the back-references without being lazy is more dangerous.

And it's basically a no-brainer; set the prices in dollars or other local currency and do real-time conversion to bitcoin prices using the recent exchange history. It's almost certainly going to be converted to another currency at that exchange fairly quickly anyway. Bitcoin will be a payment method and not a stable currency for, in my guess, quite a long time to come. If not because of the speculation but because of its tiny market cap compared to global markets. As such, bitcoin will never become useless until its market cap is smaller than the smallest purchase one might want to make, or if all the exchanges die. In fact, the lack of exchanges would tend to stabilize the currency value so it could still be used to send a few dollars worth of value across the Internet.

Financial markets like MtGox could easily maintain fractional reserves because many account-holders don't withdraw their entire balance of bitcoins every night. There is plenty of opportunity for the exchange to do whatever they want with a portion of the deposits. In essence "mtgox bitcoins" are already a fiat currency that are payable in real bitcoins upon request. They just haven't started paying out at less than 1 bitcoin per mtgox bitcoin yet, like half of the other bitcoin exchanges/banks/whatever have when they got hacked.

Of course the certificate expired in April, but it's the thought that counts.

To give the rods a heave out of the tube perhaps? I'm not sure how many of you have personally de-orbited anything from LEO, but you can't just "drop" things on the Earth from up there.

There is absolutely no reason that I'm aware of not to think the certificate authorities weren't compromised from the very beginning.

Even if you had compromised a CA, there would be a huge risk of being exposed the very first time you abused it. You have to send a legitimate certificate to the site owner, otherwise they would not be able to setup their https site in the first place. However a CA cannot abuse the legitimate certificate because they don't know the corresponding secret key. So in order to do any abuse, you have to forge another certificate.

Now there are two certificates each of which is definitely visible to a small set of legitimate users. If certificate pinning was widespread, then that would be enough to guarantee exposure. We just need a standard for chaining the legitimate certificates over time, such that certificate pinning can work well when the legitimate certificate is replaced with a new legitimate certificate before the old has expired. Ideally it would be designed in a way, that does not require cooperation from the CAs, because they might be afraid of losing control, if such a chaining was readily available.

It is useful and important to focus on as strong security against passive attacks as possible, even if it doesn't improve security against active attacks. Strong security against passive attacks will mean active attacks are needed in more cases, and it also means it is hard to make those active attacks well targeted. And systematic active attacks is both difficult to pull off and also easily detected. Additionally widespread deployment of cryptography, which is only resilient to passive attacks is easier, since it does not rely on key distribution.

It is just important to ensure that you still do use methods secured against active attacks, when the extra security is really needed. Additionally protocols must be designed such that an active attack is required to find out if a connection was protected against them. If you can passively tell if a connection is secured against active attacks, then passive security is practically worthless.

That's obvious. If you are restricted from possessing a small, machined piece of steel then you are not very free. Guns are inert without ammunition and yet it is the rare government that actually makes this critical distinction. Possessing harmful or dangerous chemicals is the real problem; more specifically possessing dangerous potential energy is what society unfortunately has need to regulate because of people's harmful intentions and simple incompetence. Unfortunately for gun-control advocates, addressing the real danger would logically require giving up gasoline, natural gas, and other volatile fuels, or implementing heavy-handed restrictions such as only allowing trained, licensed professionals to dispense gasoline into vehicles with fines or jail time for the irresponsible nuts who dared to open the gas cap or do mechanic work on the fuel system without authorization.

And, of course, the typical response is "Oh, but gasoline is NECESSARY! It's USEFUL!" but it ultimately kills far, far more people when it's mixed with self-driven vehicles than ammunition fired from a gun. So which is it; do you advocate the freedom to drive yourself around instead of being forced to walk or use mass transit or do you advocate serfdom so that you can feel safe from guns that have less of a chance of killing you than your car does? For that matter, statistically twinkies and big macs will kill you with a much higher success rate than guns. Banning personal vehicles or unhealthy food or dangerous sports or mountain climbing (have you seen the death rate for climbing Mt. Everest?) would only require people to give up portions of their lifestyle which is no more than gun-control advocates ask of gun/ammunition owners. Wouldn't it be better to give up just some of your personal freedom for just a little more safety and security?

Points taken; I spend a lot of time in the man pages and other references. I think the part I misinterpreted was the "I couldn't write a quicksort to save my life", which if taken literally means an inability to write simple programs. What I think you meant was "I couldn't write a quicksort in a few minutes without spending some time looking up reference material." I think anyone who has studied computer science should be able to come up with quicksort given enough time and motivation (and pencil and paper, at least). The concepts of divide and conquer and in-place array operations are just too basic to programming for something like quicksort to not eventually be developed by a competent programmer.

That is kind of sad. Could you describe how quicksort works, at least? Does divide and conquer ring a bell? How about a pivot element? I'm not going to require you to do it in-place or anything. If you've forgotten how to program I'm not sure what to say, except that you have my condolences.

The first time they pick up some megablocks or other imitations, they get a pretty good idea.

Comparative (not competitive) advantages are disappearing. When walmart (or, more likely, amazon/google/some-other-tech-company) can plop a robotic liquor store in your neighborhood the microbreweries and corner stores are (nearly) history. They become a luxury item instead of a commodity, and while luxury beer will always have a market it's a much smaller market than the general liquor market. Eventually, robotically microbrewed local beer will have the comparative advantage if it's marketed as Luxury Robot Beer (Hand-Programmed Limited Edition).

TFA is about the shrinking number of comparative advantages that human labor has. You're not competing against Walmart, you're competing against automation that won't leave you with any comparative advantages in the end. Become a pure capitalist because labor won't pay. Buy/build robots.

Not only that, but consumers are free to not buy products at prices that ultimately lead to their own lowered wages.

Uh oh, I see the problem. There is no perfect economic information and so large hierarchical entities can collude to manipulate market prices and wages because of their ability to solve the coordination problem for the actions of their independent agents more efficiently than free individuals who have trouble just avoiding the tragedy of the commons, not to mention the problems of self-governance.

Corporations are more efficient processes for accumulating wealth. The problem is that corporations have no intrinsic terminal value for individuals, and so a society of individuals must constantly enforce its own terminal values at the expense of corporate values.

What reasons are there to cause one to want to generate a new key instead of reusing the old one?

For the same reasons that you would rotate passwords. It is just a precaution in case it accidentally was leaked. When changing certificate anyway there is no inconvenience to the users from replacing the key, so you might as well replace it. It would for example help a bit in case an old backup of the webserver had been leaked. The difference in security is minor though, there are much greater threats from insecure CAs.

Certificates have an expiry date. They are supposed to be changed before the expiry date is reached. On a well managed system, you'll never see a certificate which has less than a week left of its validity period. Once the certificates are changed, it should be considered best practice to rotate the server key as well, so the new certificate will always be signing a different key from the previous certificate.

It would be nice to have more information to verify the correctness of the new certificate than just the existing CA certificate chain. I would like to see a small extension to SSL where the server can tell the client that any new certificate will be signed using the current certificate. When the client is told that, it can cache the current certificate and warn the user if it sees a new certificate lacking a chain from the old to the new certificate.

I've also seen Skype work when it shouldn't - behind corporate firewalls that are supposed to be blocking traffic.

When parties on both sides of a firewall are cooperating in getting data through the firewall, there is little you can do to stop them. The solution is to limit what software gets to run on the trusted side of the firewall. If you don't want Skype on your network, then don't install it. Some corporations do use Skype as part of their work. Those corporations are happy that Skype is so easy to get working through their firewall.

The point where it gets difficult to get data through is when there are two firewalls in play, and each of them blocks traffic in opposite directions. The only reason any communication is possible at all in such a scenario is, that somebody between the two firewalls is cooperating with the parties, which want to communicate.