Older blog entries for apenwarr (starting at number 607)

9 May 2011 (updated 9 May 2011 at 03:03 UTC) »

Why bitcoin will fail

    Reading about bitcoin. Thought about writing a blog rant, but "OMG they're all totally crazy" wasn't long enough, so here we are. Filler.

        -- Me on twitter

    I now have had my foggy crystal ball for quite a long time. Its predictions are invariably gloomy and usually correct, but I am quite used to that and they won't keep me from giving you a few suggestions, even if it is merely an exercise in futility whose only effect is to make you feel guilty.

        -- E.W. Dijkstra

I'm in the "commerce" group at work, and I've done quite a bit of work in the world of banking, so it seemed vaguely relevant when I ran into the technical paper about bitcoin (Google it) and its associated various web sites. This led to my above, admittedly rather smarmy, twitter post...

...and then someone, yes, inevitably, asked me for clarification.

See, a bitcoin rant is almost too over-the-top for me. Asking why I think bitcoin won't work is like asking why the sky isn't red. I mean, wait, you think it *is* red? You actually took that seriously? Oh boy. Where do I even start?

But just for you, because I know all the valued subscribers to this diary have been deprived of my ranting lately, I will expand on it a little.

Just one more side note. Most of the time, I try to give projects the benefit of the doubt. If they don't affect me, then it's really no matter to me if they succeed or fail. I might keep an eye on them to see if my prediction (usually failure) comes true or not, and try to learn from the result. But I don't actively *want* projects to fail. I would much rather they succeed.

In this case as well, I don't really care. I don't own any bitcoins. I don't particularly want to. If one day I have to own some for some reason, I will buy them at the market rate and get screwed, just as I do today with U.S. and Canadian dollars.

Since I don't actually care, I had a bit of trouble motivating myself to write more than 140 characters about it. I wasn't going to bother. So, um, thanks to my followers on twitter for providing the motivation.

So here we go:

FAIL #1: If you like bitcoin, then you must think the gold standard was a good idea.

The gold standard, for those who don't know, was the (now thoroughly discredited) idea that for every dollar you print, you need to have an appropriate amount of gold stored away somewhere that someone, someday, theoretically, could demand to get back in exchange for your worthless piece of paper. If you honestly believe that abandoning the gold standard was a bad idea - and there are indeed people who believe this - then you might as well stop reading now. Wiser men than I have explained in excruciating detail why you're an idiot. This article will not convince you, it will just make you angry.

Still with me?

Okay, just for background, for people who don't already have a pre-formed opinion, the gold standard is a bad idea for several reasons. Here are some of them:

In order to create currency, you have to do a bunch of pointless busywork. Originally, that meant mining for gold, so you could take this gold (obtained at great expense) and hide it in a fortress where nobody would ever see or feel or admire it. In all of history, it is extremely doubtful that anybody has *ever* walked into a U.S. government office and demanded their gold in exchange for dollars. That's because:

Gold is a stupid inconvenient currency that's worse than paper. Go up to the street vendor selling a hot dog, and try to get him to give you a hot dog in exchange for the equivalent value in gold dust. (That's really not very much dust.) See what happens. Gold is the universal currency, is it? The thing that anybody would and will take, any time, throughout history? No. It's heavy, messy, hard to measure, and I can't get my ATM to withdraw or deposit it. If I want 1000x as much gold as one gold nugget, I can't just get a $1000 bill; I have to get a gold nugget 1000x as big and heavy. Who wants this?

Believing in the gold standard is disbelieving in capitalism. The magic of capitalism is entirely contained in the following two words: MAKING MONEY. Have you ever thought about those two words? What's interesting about them is they don't seem to make any sense. When I go into the office and do work, am I literally "making" money? Why do they call it that? Well, as a matter of fact, you *are* literally making money. You are a machine: you eat food and breathe air and magically, you produce outputs that can be sold for much more money than the cost of the food and air. You produced actual value, and that value can be measured, and that measurement is called money. You made money. Out of nothing. *That* is capitalism. (Compare with digging up useless coloured rocks and then hiding them in a fortress so nobody can see them. Those people make the economy go round?)

If the gold standard worked, the 1930s depression wouldn't have happened, and we couldn't have recovered, period, from the recent banking crisis.

Back in the 1930s, the U.S. still had gold-backed currency. Why was there a depression? Because people stopped producing valuable stuff. The amount of money was constant; the gold didn't disappear. But somehow, suddenly people didn't have enough food or housing. Why? Because they refused to produce unless they got paid for it. When they didn't get paid, they couldn't spend that money, and so they couldn't pay for other things, and so other people refused to produce since they wouldn't get paid either, and so on in a giant cycle. The money was there, but it stopped moving.

How did the depression get resolved? In short, people started doing stuff (especially a big war) whether they could afford it or not. It turned out that all those idle people could be productive if they had a good reason. Gold turned out not to be a good enough reason.

Relatedly, the U.S. survived the 2008 banking crisis - which had a legitimate opportunity to convert itself into another depression - by spending its way out. As it happens, the U.S. was able to spend money it didn't actually have. Why? Because they don't care about the gold standard. If they had had a constant amount of gold, then they would not have been able to spend more than they had, and so people wouldn't have been paid, and those people would have refused to produce, and they wouldn't be able to buy things, so more people would refuse to produce... and we're back to square one.

Motivation is everything. Gold is nothing.

Which leads us to the last, most important reason to abandon the gold standard:

The ability of governments to print (and destroy) money is a key tool in economic management.

The Federal Reserve (and other related institutions in each country, like the Bank of Canada) has the right to print money. It largely does this through a pretty blunt mechanism, the interest rate. I won't go into a lot of detail - look up "federal funds rate" if you want to learn more. But in short, when they lower the rate, banks are willing to "borrow more money" from the federal reserve (which they then lend to you, and so on). When the federal funds rate is high, banks need to give back this money, so they don't give out as many loans, and so on.

What is this money that the federal reserve "lends" to banks? It's fictional. Bits in a computer database. No fancy encryption. They just manufacture it on the spot, as needed. And when it's returned, they make it disappear.

    Update 2011/05/08: Some gold standard supporters will tell you that in fact, this ability to print money is what causes hyperinflation, which causes economic collapse. But no, the causality doesn't work like that. Hyperinflation occurs when government nutbars try to stop an economic collapse by wildly printing money. No economic system can protect you when nutbars are in charge. But yes, the early symptoms of failure will look somewhat different.

The Federal Reserve uses this control to speed up or slow down the economy and try to reduce fluctuations. The results aren't always perfect (humans aren't very good at acting like math equations) but it's actually not too bad overall.

If governments can't control the money supply, then they can't set interest rates. If they can't set interest rates, they can't control the economy, and if nobody is controlling the economy, then the economy will act like any uncontrolled complex system: it'll go crazy.

(Incidentally, this is also why it's important that the Federal Reserve not be controlled directly by politicians. Find me a politician who will say anything other than, "OH YEAH! MAKE THAT ECONOMY GO FASTER!" at election time.)

...

Okay, so, back to bitcoin. Bitcoin is exactly like the gold standard, only digital:

  • "Mining" (they even borrowed the word!) bitcoins is pointless busywork that produces nothing of real value.
  • Bitcoins are less convenient than paper currency.
  • Bitcoin denies the truth of capitalism, that it's about *value*, not about money, by preventing the money supply from expanding when the economy does.
  • Bitcoin allows for random unrecoverable effects like the 1930s depression.
  • Bitcoin removes government control over the economy, which means there is *no* control over the economy.
By comparison, look at our current currencies:

  • Generating money is essentially free (most money isn't even paper, but printing the paper is pretty cheap too).
  • Current currency is very convenient and has many convenient forms.
  • When more valuable stuff is created, more money appears without having to mine for unrelated crap first.
  • Current currency allowed us to spend out of a depression caused by the banking crisis.
  • The current system allows the government to reduce economic fluctuations.
FAIL #2: Even if it was a good idea, governments would squash it.

In the previous section, it might have sounded like I think governments are altruistic peace-loving tea-drinking hippie commies.

I don't actually think that. (I think the government of British Columbia might be like that, which explains why they don't get any work done, but that's another story.)

The truth is that governments are power structures. Governments control ("govern") things. And while the economy - like any complex engineering construction - needs to have controls on it, some of the controls end up going too far, and all of them end up being manipulated by people in power.

One of the lures of bitcoin is the idea of taking power away from the people in power. Admit it. That's one of the reasons why you like it.

Well, word to the wise: if there's one thing the people in power already know, it's that money is power. It's not like you're going to catch them by surprise here. They don't have to be the smartest cookies in the jar to figure that part out.

Digital money is *not* like pirating digital music and movies. The government sort of cares about those, but let's be serious: pirating a few movies will not topple the U.S. government. Losing control of money will.

Governments have big weapons and propaganda machines and actual secret agents and citizens who believe that keeping the economy under control is a good idea. If you threaten the currency, you are threatening the entire power structure of the civilized world. You are, quite literally, an enemy of the state. You are attempting to build nuclear weapons in your bedroom. Or at least they'll see it that way.

Do you think you'll get away with it because your monopoly money is made of bits instead of paper? I don't.

The only reason you'd get away with it is if you're too small to matter. Which is certainly the current situation.

FAIL #3: The whole technological basis is flawed.

Bitcoin is, fundamentally, a cryptosystem. Some people argue that it's "as strong as SHA256" and that "if someone could break SHA256, then banks would be in trouble as it is."

Wrong on both counts.

First of all, I admit, I don't totally understand the bitcoin algorithms and systems. I don't really need to. I understand only this: the road to crypto hell is paved with the bones of people who thought that a good cryptosystem can be designed by combining proven algorithms in unproven ways. SHA256 may be the strongest part of bitcoin, but a cryptosystem is only as strong as its weakest link.

You want to replace the world economy with a hard-to-guess math formula? Where's your peer review? Where are the hordes of cryptographers who have spent 30+ years trying to break your algorithm and failed? Come talk to me in 30 years. Meanwhile, it's safe to assume that bitcoin has serious flaws that will allow people to manufacture money, duplicate coins, or otherwise make fake transactions. In that way, it's just like real dollars.

But what's *not* like real dollars is the cost of failure. With real dollars, when people figure out how to make counterfeit bills, we find those people and throw them in jail, and eventually we replace our bills with newer-style ones that are more resistant to failure. And the counterfeiters are limited by how many fake bills their printing press can produce.

With bitcoin, a single failure of the cryptosystem could result in an utter collapse of the entire financial network. Unlimited inflation. Fake transactions. People not getting paid when they thought they were getting paid. And the perpetrators of the attack would make so much money, so fast, that they could apply their fraud at Internet Scale on Internet Time.

(Ha, and don't even talk to me about how your world-changing financial system would of course also be protected by anti-fraud laws so we could still punish people for faking it. If we still need the government, what is the point of your currency again?)

The current financial system is slow, and tedious, and old, and in many ways actually broken or flawed. But one thing we know is that it's *resilient*. One single mathematical error will not send the whole thing into a tailspin. With bitcoin, it will.

And no, a break in SHA256 would not break the current financial system or ruin any banks. How could it? What would even be the mechanism for such an attack? How would it make the paper bills in my pocket stop working for buying hot dogs? Can't we just hunt down and arrest the people who forged the fake transactions?

FAIL #4: It doesn't work offline.

Stupid, crappy, printed paper money is old fashioned and flawed, but you know what? It actually works offline, because the easily-forged piece of paper is just barely hard enough to forge that normal people won't try to forge it. It's the original peer-to-peer financial network, although there's a "central coordinator" somewhere issuing tokens.

As soon as you go electronic, forgery becomes trivial to do on a massive scale, so offline just isn't an option. Yes, there are "offline" mechanical paper-based credit card readers, but they aren't anonymous: they have your name and card number. If you bounce too many transactions from one of those, someone will be sent to hunt you down. The risk is contained.

There is no way to make bitcoin even remotely safe offline. There is no fallback mechanism except exchanging your bitcoins for cash. But if you're going to rely on a paper currency anyway, what is bitcoin buying you? It's just yet another way to spend money. As a person currently suffering through managing U.S. versus Canadian dollars, I can tell you, exchange rates are just not worth the hassle.

...

Summary

1. Like the gold standard, a successful bitcoin would send our economy back into the dark ages.

2. Even if it became popular, governments would squash it because of #1 and because they like being in power.

3. A single mathematical or other error in the cryptosystem would cause instant, unresolvable, worldwide hyperinflation. After hundreds of years of analysis, there are no known flaws in the current financial system that could lead to that. (Other than the known causes of hyperinflation of course, ie. total gross mismanagement of the entire country.)

4. It's not even useful except as an online-only addition to normal currency, and my normal currency already works fine online.

The sky is JUST NOT RED, dammit.

Tell me again why you think it is?

...

Update 2011/05/08: Counterpoint!

An anonymous (really, they anonymized their return address) reader replies with the following. I'll just reprint it in full because it's awesome. There's nothing quite like just letting an unelected representative of a movement embarrass himself. Oh Internet, how I love you.

    Was that for real? I'm not sure if your stupid or just trolling.

    The US dollar has lost 97% of it's value since leaving the gold standard.

    Germans in the Weimer republic had to buy their sausage with wheelbarrows full of paper currency. Too long ago for you? Mid-90's Yugoslavia, samething.

    "Believing in the gold standard is disbelieving in capitalism" and how do you think capitalism came about?

    "If the gold standard worked, the 1930s depression wouldn't have happened, and we couldn't have recovered, period, from the recent banking crisis."

    You really don't know history.

    "The ability of governments to print (and destroy) money is a key tool in economic management."

    REALLY? Then why did the Soviet Union fail? They should have been the richest country in the world if your statement was true.

    "What is this money that the federal reserve "lends" to banks? It's fictional. Bits in a computer database. No fancy encryption. They just manufacture it on the spot, as needed. And when it's returned, they make it disappear."

    Loaned with interest. How does the interest disappear when more money is owed then exists?

    I wouldn't be surprised if you said somewhere else that current debts are managable.

    "If governments can't control the money supply, then they can't set interest rates. If they can't set interest rates, they can't control the economy, and if nobody is controlling the economy, then the economy will act like any uncontrolled complex system: it'll go crazy."

    From, "disbelieving in capitalism"" to that? See also; Soviet Union.

    I don't use BitCoin (yet) but your reasoning there is even more pathetic.

    No reply because your the stupidest person I've seen this week and that's saying something.

For the record, I'm stupid *and* trolling. That's why it was hard to tell.

Syndicated 2011-05-08 23:48:33 (Updated 2011-05-09 03:03:32) from apenwarr - Business is Programming

26 Apr 2011 (updated 2 May 2011 at 22:06 UTC) »

Avery, sshuttle, and bup at LinuxFest Northwest (Bellingham, WA) April 30

Where: LinuxFest Northwest conference (Bellingham, WA)
When: 1:30-3:30 on Saturday, April 30 (conf runs all weekend)
Price: FREE!

You might think that now that I live in New York, I would stop doing presentations on the West coast. But no. Ironically, right after moving to New York, I'll have done three separate presentations (four, if you count this one as two) on the West coast in a single calendar month.

In this particular case, it's because I proposed my talks back when I lived in BC, when Bellingham was a convenient one-hour drive from Vancouver's ferry terminal. Now it's a day-long trip across the continent (and twice across the US/Canada border). But oh well, it should be fun.

Also, I foolishly took someone's advice from a Perl conference one time (was it Damian Conway?) and proposed *two* talks, under the theory that if you propose two talks, you double your chances that the conference admins might find one of them interesting, but of course nobody would be crazy enough to give you *two* time slots. Clearly this theory is crap, because this is the second time I've tried it out, and in both cases *both* of my talks have been selected. Thanks a lot.

The good news is that at least they're in consecutive time slots. So while I'll be hoarse by the end, I only have to psych myself up once.

Bellingham is convenient to reach from Vancouver, Seattle, and Portland, among other places, and the conference is free, so take your chance to come see it! If you like open source, it promises to be... filled with open source.

Um, and I promise to start writing something other than my presentation schedule in this space again soon. I realize how annoying it is when a blog diary turns into a glorified presentation schedule. I'm working on it.

Update 2011/05/02: By popular request, my slides from the conference:

Enjoy.

Syndicated 2011-04-26 03:02:29 (Updated 2011-05-02 22:06:06) from apenwarr - Business is Programming

Avery is doing a presentation in Mountain View (maybe about bup)

Where: Hacker Dojo in Mountain View, California
When: 7:30pm on Tuesday, April 12
Why: Because (as Erin tells me) I have trouble saying no.

I have heard unconfirmed rumours that there are programmers of some sort somewhere in the region of Silicon Valley, despite how silly this sounds in concept. (Silicon? That stuff you make beaches out of? Why would any nerd go anywhere near a beach?) Nevertheless, after my thrilling and/or mind boggling presentation and/or rant about bup in San Francisco on Saturday, there was some interest in having me do something similar out in the middle of nowhere, so I accepted.

You're invited! I'm not expecting a very big crowd, given the short notice, which means it will probably be more Q&A and less presentation. But I'll bring my presentation slides just in case. There will be demos. There will be oohing and aahing, I guarantee it, even if I have to do it myself.

I might also talk about sshuttle or redo, or maybe Linux arcnet poetry, if there are any poetry lovers in the audience. (I doubt there will be any arcnet users on the beach, so a talk on arcnet is unlikely.)

Syndicated 2011-04-11 17:11:33 from apenwarr - Business is Programming

Avery's doing a bup presentation in San Francisco

When: Saturday, April 9, 2:30 PM
Where: San... Francisco... somewhere

The venue is not quite certain yet since we don't know how many people are actually interested.

If you want to see me talk about how we took the git repository format and made a massively more scalable implementation of it, as well as my evil (disclaimer: I do not speak for my employer) schemes for the future, please email [tony at godshall.org] with subject "bup SF". Thanks to Tony for organizing this little adventure.

Tell your friends!

Or skip the boring meatspace stuff and jump straight to bup on github.

Syndicated 2011-04-05 22:41:46 from apenwarr - Business is Programming

3 Apr 2011 (updated 3 Apr 2011 at 18:04 UTC) »

What you can't say

Normally I don't write a new post just about updates to a previous post, but I have added quite a lot of clarifications and notes to I hope IPv6 never catches on, in response to copious feedback I've received through multiple channels. Perhaps you will enjoy them.

One very interesting trend is that the comments about the article on news.ycombinator were almost uniformly negative - especially the highly upvoted comments - while I simultaneously saw tons and tons of positive comments on Twitter (it was my most popular article ever) and numerous people wrote me polite messages with agreement and/or minor suggestions and clarifications. Only one person emailed me personally to say I was an idiot (although it was my first, at least from people I don't know).

The trend is curious, because normally news.yc has more balanced debate. Either I'm utterly completely wrong and missed every point somehow (as a highly upvoted point-by-point rebuttal seems to claim)... or I seriously pinched a nerve among a certain type of people.

All this reminds me of Paul Graham's old article, What You Can't Say. Perhaps some people's world views are threatened by the idea of IPv6 being pointless and undesirable.

And all *that*, in turn, reminded me of my old article series about XML, sadomasochism, and Postel's Law. I was shocked at the time that some people actually think Postel's Law is *wrong*, but now I understand. Some people believe the world must be *purified*; hacky workarounds are bad; they must be removed. XML parsers must not accept errors. Internet Protocol must not accept anything less than one address per device. Lisp is the one truly pure language. And so on.

Who knows, maybe those people will turn out to be right in the end. But I'm with Postel on this one. Parsers that refuse to parse, Internet Protocol versions that don't work with 95% of servers on the Internet, and programming languages that are still niche 50+ years later... sometimes you just have to relax and let it flow.

Update 2011/04/02: Another big example of a "less good" technology failing to catch on for similar reasons as IPv6: x86 vs. non-x86 architectures. Everyone knows x86 is a hack... but we're stuck with it. (ARM is making an impact in power-constrained devices, though, just like IPv6 is making an impact in severely IPv4-constrained subnets. Who will win? I don't know, I just know that IPv4 and x86 are less work for me, the programmer, right now.)

Thinking about the problem in that way - why "worse" (hackier) technologies tend to stick around while the purified replacements don't - reminded me of Worse is Better by Richard Gabriel. In retrospect, when I divided people above into "purists" and "Postel's Law believers", I guess I was just restating Gabriel's much better-written point about "worse-is-better" vs. "the right thing." If you haven't read the article, read it; it's great. And see if you're firmly on one side or the other, and if you think the other side is clearly just crazy.

If you think that, then *that*, in turn, brings us back to "What You Can't Say." The truth is, you *can* say it, but people will jump down your throat for saying it. And not everybody will; only the very large group of people in the camp you're not in.

That's why we have religious wars. Figurative ones, anyway. I suspect real religious wars are actually about something else.

Syndicated 2011-04-03 01:30:12 (Updated 2011-04-03 18:04:57) from apenwarr - Business is Programming

28 Mar 2011 (updated 29 Mar 2011 at 02:13 UTC) »

I hope IPv6 *never* catches on

(Temporal note: this article was written a few days ago and then time-released.)

This year, like every year, will be the year we finally run out of IPv4 addresses. And like every year before it, you won't be affected, and you won't switch to IPv6.

I was first inspired to write about IPv6 after I read an article by Daniel J. Bernstein (the qmail/djbdns/redo guy) called The IPv6 Mess. Now, that article appears to be from 2002 or 2003, if you can trust its HTTP Last-Modified date, so I don't know if he still agrees with it or not. (If you like trolls, check out the recent reddit commentary about djb's article.) But 8 years later, his article still strikes me as exactly right.

Now, djb's commentary, if I may poorly paraphrase, is really about why it's impossible (or perhaps more precisely, uneconomical, in the sense that there's a chicken-and-egg problem preventing adoption) for IPv6 to catch on without someone inventing something fundamentally new. His point boils down to this: if I run an IPv6-only server, people with IPv4 can't connect to it, and at least one valuable customer is *surely* on IPv4. So if I adopt IPv6 for my server, I do it in addition to IPv4, not in exclusion. Conversely, if I have an IPv6-only client, I can't talk to IPv4-only servers. So for my IPv6 client to be useful, either *all* servers have to support IPv6 (not likely), or I *must* get an IPv4 address, perhaps one behind a NAT.

In short, any IPv6 transition plan involves *everyone* having an IPv4 address, right up until *everyone* has an IPv6 address, at which point we can start dropping IPv4, which means IPv6 will *start* being useful. This is a classic chicken-and-egg problem, and it's unsolvable by brute force; it needs some kind of non-obvious insight. djb apparently hadn't seen any such insight by 2002, and I haven't seen much new since then.

(I'd like to meet djb someday. He would probably yell at me. It would be awesome. </groupie>)

Still, djb's article is a bit limiting, because it's all about why IPv6 physically can't become popular any time soon. That kind of argument isn't very convincing on today's modern internet, where people solve impossible problems all day long using the unstoppable power of "not SQL", Ruby on Rails, and Ajax to-do list applications (ones used by breakfast cereal companies!).

No, allow me to expand on djb's argument using modern Internet discussion techniques:

Top 10 reasons I hope IPv6 never catches on

Just kidding. No, we're going to do this apenwarr-style:

What I hate about IPv6

Really, there's only one thing that makes IPv6 undesirable, but it's a doozy: the addresses are just too annoyingly long. 128 bits: that's 16 bytes, four times as long as an IPv4 address. Or put another way, IPv4 contains almost enough addresses to give one to each human on earth; IPv6 has enough addresses to give 39614081257132168796771975168 (that's 2**95) to every human on earth, plus a few extra if you really must.

Of course, you wouldn't really do that; you would waste addresses to make subnetting and routing easier. But here's the horrible ironic part of it: all that stuff about making routing easier... that's from 20 years ago!

Way back in the IETF dark ages when they were inventing IPv6 (you know it was the dark ages, because they invented the awful will-never-be-popular IPsec at the same time), people were worried about the complicated hardware required to decode IPv4 headers and route packets. They wanted to build the fastest routers possible, as cheaply as possible, and IPv4 routing tables are annoyingly complex. It's pretty safe to assume that someday, as the Internet gets more and more crowded, nearly every single /24 subnet in IPv4 will be routed to a different place. That means - hold your breath - an astonishing 2**24 routes in every backbone router's routing table! And those routes might have 4 or 8 or even 16 bytes of information each! Egads! That's... that's... 256 megs of RAM in every single backbone router!

Oh. Well, back in 1995, putting 256 megs of RAM in a router sounded like a big deal. Nowadays, you can get a $99 Sheevaplug with twice that. And let me tell you, the routers used on Internet backbones cost a lot more than $99.

It gets worse. IPv6 is much more than just a change to the address length; they totally rearranged the IPv4 header format (which means you have to rewrite all your NAT and firewall software, mostly from scratch). Why? Again, to try to reduce the cost of making a router. Back then, people were seriously concerned about making IPv6 packets "switchable" in the same way ethernet packets are: that is, using pure hardware to read the first few bytes of the packet, look it up in a minimal routing table, and forward it on. IPv4's variable-length headers and slightly strange option fields made this harder. Some would say impossible. Or rather, they would, if it were still 1995.

Since then, FPGAs and ASICs and DSPs and microcontrollers have gotten a whole lot cheaper and faster. If Moore's Law calls for a doubling of transistor performance every 18 months, then between 1995 and 2011 (16 years), that's 10.7 doublings, or 1663 times more performance for the price. So if your $10,000 router could route 1 gigabit/sec of IPv4 in 1995 - which was probably pretty good for 1995 - then nowadays it should be able to route 1663 gigabits/sec. It probably can't, for various reasons, but you know what? I sincerely doubt that's IPv4's fault.

If it were still 1995 and you had to route, say, 10 gigabits/sec for the same price as your old 1 gigabit/sec router using the same hardware technology, then yeah, making a more hardware-friendly packet format might be your only option. But the router people somehow forgot about Moore's Law, or else they thought (indications are that they did) that IPv6 would catch on much faster than it has.

Well, it's too late now. The hardware-optimized packet format of IPv6 is worth basically zero to us on modern technology. And neither is the simplified routing table. But if we switch to IPv6, we still have to pay the software cost of those things, which is extremely high. (For example, Linux IPv6 iptables rules are totally different from IPv4 iptables rules. So every Linux user would need to totally change their firewall configuration.)

So okay, the longer addresses don't fix anything technologically, but we're still running out of addresses, right? I mean, you can't argue with the fact that 2**32 is less than the number of people on earth. And everybody needs an IP address, right?

Well, no, they don't:

The rise of NAT

NAT is Network Address Translation, sometimes called IP Masquerading. Basically, it means that as a packet goes through your router/firewall, the router transparently changes your IP address from a private one - one reused by many private subnets all over the world and not usable on the "open internet" - to a public one. Because of the way TCP and UDP work, you can safely NAT many, many private addresses onto a single public address.

So no. Not everybody in the world needs a public IP address. In fact, *most* people don't need one, because most people make only outgoing connections, and you don't need your own public IP address to make an outgoing connection.

By the way, the existence of NAT (and DHCP) has largely eliminated another big motivation behind IPv6: automatic network renumbering. Network renumbering used to be a big annoying pain in the neck; you'd have to go through every computer on your network, change its IP address, router, DNS server, etc, rewrite your DNS settings, and so on, every time you changed ISPs. When was the last time you heard about that being a problem? A long, long time ago, because once you switch to private IP subnets, you virtually never have to renumber again. And if you use DHCP, even the rare mandatory renumbering (like when you merge with another company and you're both using 192.168.1.0/24) is rolled out automatically from a central server.

Okay, fine, so you don't need more addresses for client-only machines. But every server needs its own public address, right? And with the rise of peer-to-peer networking, everyone will be a server, right?

Well, again, no, not really. Consider this for a moment:

Every HTTP Server on Earth Could Be Sharing a Single IP Address and You Wouldn't Know The Difference

That's because HTTP/1.1 (which is what *everyone* uses now... speaking of avoiding chicken/egg problems) supports "virtual hosts." You can connect to an IP address on port 80, and you provide a Host: header at the beginning of the connection, telling it which server name you're looking for. The IP you connect to can then decide to route that request anywhere it wants.

In short, HTTP is IP-agnostic. You could run HTTP over IPv4 or IPv6 or IPX or SMS, if you wanted, and you wouldn't need to care which IP address your server had. In a severely constrained world, Linode or Slicehost or Comcast or whoever could simply proxy all the incoming HTTP requests to their network, and forward the requests to the right server.

(See the very end of this article for discussion of how this applies to HTTPS.)

Would it be a pain? Inefficient? A bit expensive? Sure it would. So was setting up NAT on client networks, when it first arrived. But we got used to it. Nowadays we consider it no big deal. The same could happen to servers.

What I'd expect to happen is that as the IPv4 address space gets more crowded, the cost of a static IP address will go up. Thus, fewer and fewer public IP addresses will be dedicated to client machines, since clients won't want to pay extra for something they don't need. That will free up more and more addresses for servers, who will have to pay extra.

It'll be a *long* time before we reach 4 billion (2**32) server IPs, particularly given the long-term trend toward more and more (infinitely proxyable) HTTP. In fact, you might say that HTTP/1.1 has successfully positioned itself as the winning alternative to IPv6.

So no, we are obviously not going to run out of IPv4 addresses. Obviously. The world will change, as it did when NAT changed from a clever idea to a worldwide necessity (and earlier, when we had to move from static IPs to dynamic IPs) - but it certainly won't grind to a halt.

Next:

It is possible do do peer-to-peer when both peers are behind a NAT.

Another argument against widespread NATting is that you can't run peer-to-peer protocols if both ends are behind a NAT. After all, how would they figure out how to connect to each other? (Let's assume peer-to-peer is a good idea, for purposes of this article. Don't just think about movie piracy; think about generally improved distributed database protocols, peer-to-peer filesystem backups, and such.)

I won't go into this too much, other than to say that there are already various NAT traversal protocols out there, and as NAT gets more and more annoyingly mandatory, those protocols and implementations are going to get much better.

Note too that NAT traversal protocols don't have a chicken-and-egg problem like IPv6 does, for the same reason that dynamic IP addresses don't, and NAT itself doesn't. The reason is: if one side of the equation uses it, but the other doesn't, you might never know. That, right there, is the one-line description of how you avoid chicken-and-egg adoption problems. And how IPv6 didn't.

IPv6 addresses are as bad as GUIDs

So here's what I really hate about IPv6: 16-byte (32 hex digit) addresses are impossible to memorize. Worse, auto-renumbering of networks, facilitated by IPv6, mean that anything I memorize today might be totally different tomorrow.

IPv6 addresses are like GUIDs (which also got really popular in the 1990s dark ages, notably, although luckily most of us have learned our lessons since then). The problem with GUIDs are now well-known: that is, although they're globally unique, they're also totally unrecognizable.

If GUIDs were a good idea, we would use them instead of URLs. Are URLs perfect? Does anyone love Network Solutions? No, of course not. But it's 1000x better than looking at http://b05d25c8-ad5c-4580-9402-106335d558fe and trying to guess if that's *really* my bank's web site or not.

The counterargument, of course, is that DNS is supposed to solve this problem. Give each host a GUID IPv6 address, and then just map a name to that address, and you can have the best of both worlds.

Sounds good, but isn't actually. First of all, go look around in the Windows registry sometime, specifically the HKEY_CLASSES_ROOT section. See how super clean and user-friendly it isn't? Barf. But furthermore, DNS on the Internet is still a steaming pile of hopeless garbage. When I bring my laptop to my friend's house and join his WLAN, why can't he ping it by name? Because DNS sucks. Why doesn't it show up by name in his router control panel so he knows which box is using his bandwidth? Because DNS sucks. Why can the Windows server browse list see it by name (sometimes, after a random delay, if you're lucky), even though DNS can't? Because they got sick of DNS and wrote something that works. Why do we still send co-workers hyperlinks with IP addresses in them instead of hostnames? Because the fascist sysadmin won't add a DNS entry for the server Bob set up on his desktop PC.

DNS is, at best, okay. It will get better over time, as necessity dictates. All the problems I listed above are mostly solved already, in one form or another, in different DNS, DHCP, and routing products. It's certainly not the DNS *protocol* that's to blame, it's just how people use it.

But still, if you had to switch to IPv6, you'd discover that those DNS problems that were a nuisance yesterday are suddenly a giant fork stabbing you in the face today. I'd rather they fixed DNS *before* making me switch to something where I can't possibly remember my IP addresses anymore, thanks.

Server-side NAT could actually make the world a better place

So that's my IPv6 rant. I want to leave you with some good news, however: I think the increasing density of IPv4 addresses will actually make the Internet a better place, not a worse one.

Client-side NAT had an unexpected huge benefit: security. NAT is like "newspeak" in Orwell's 1984: we remove nouns and verbs to make certain things inexpressible. For example, it is not possible for a hacker in Outer Gronkstown to even express to his computer the concept of connecting to the Windows File Sharing port on your laptop, because from where he's standing, there is no name that unambiguously identifies that port. There is no packet, IPv4 or IPv6 or otherwise, that he can send that will arrive at that port.

A NAT can be unbelievably simple-minded, and just because of that one limitation, it will vastly, insanely, unreasonably increase your security. As a society of sysadmins, we now understand this. You could give us all the IPv6 addresses in the world, and we'd still put our corporate networks behind a NAT. No contest.

Server-side NAT is another thing that could actually make life better, not worse. First of all, it gives servers the same security benefits as clients - if I accidentally leave a daemon running on my server, it's not automatically a security hole. (I actually get pretty scared about the vhosts I run, just because of those accidental holes.)

But there's something else, which I would be totally thrilled to see fixed. You see, IPv4 addresses aren't really 32-bits. They're actually 48 bits: a 32-bit IP address plus a 16-bit port number. People treat them as separate things, but what NAT teaches us is that they're really two parts of the same whole: the flow identifier, and you can break them up any way you want.

The address of my personal apenwarr.ca server isn't 74.207.252.179; it's 74.207.252.179:80. As a user of my site, you didn't have to type the IP (which was provided by DNS) or the port number (which is a hardcoded default in your web browser), but if I started another server, say on port 8042, then you *would* have to enter the port. Worse, the port number would be a weird, meaningless, magic number, akin to memorizing an IP address (though mercifully, only half as long).

So here's my proposal to save the Internet from IPv6: let's extend DNS to give out not only addresses, but port numbers. So if I go to www2.apenwarr.ca, it could send me straight to 74.207.252.179:8042. Or if I ask for ssh.apenwarr.ca, I get 74.207.252.179:22.

Someday, when IPv4 addresses get too congested, I might have to share that IP address with five other people, but that'll be fine, because each of us can run our own web server on something other than port 80, and DNS would transparently give out the right port number.

This also solves the problem with HTTPS. Alert readers will have noticed, in my comments above, that HTTPS can't support virtual hosts the same way HTTP does, because of a terrible flaw in its certificate handling. Someday, someone might make a new version of the HTTPS standard without this terrible flaw, but in the meantime, transparently supporting multiple HTTPS servers via port numbers on the same machine eliminates the problem; each port can have its own certificate.

(Update 2011/03/28: zillions of people wrote to remind me about SNI, an HTTPS extension that allows it to work with vhosts. Thanks! Now, some of those people seemed to think this refutes my article somehow, which is not true. In fact, the existence of an HTTPS vhosting standard makes IPv6 even *less* necessary. Then again, the standard doesn't work with IE6.)

This proposal has very minor chicken-and-egg problems. Yes, you'll have to update every operating system and every web browser before you can safely use it for *everything*. But for private use - for example, my personal ssh or VPN or testing web server - at least it'll save me remembering stupid port numbers. Like the original DNS, it can be adopted incrementally, and everyone who adopts it sees a benefit. Moreover, it's layered on top of existing standards, and routable over the existing Internet, so enabling it has basically zero admin cost.

Of course, I can't really take credit for this idea. It's already been invented and is being used in a few places.

Embrace IPv4. Love it. Appreciate the astonishing long-lasting simplicity and resilience of a protocol that dates back to the 1970s. Don't let people pressure you into stupid, awful, pain-inducing, benefit-free IPv6. Just relax and have fun.

You're going to be enjoying IPv4 for a long, long time.

Syndicated 2011-03-27 02:00:38 (Updated 2011-03-29 02:13:30) from apenwarr - Business is Programming

27 Mar 2011 (updated 27 Mar 2011 at 02:09 UTC) »

Time capsule: assorted cooking advice

Hi all,

As I mentioned previously, I'm about to disappear into the Google Vortex, across which are stunning vistas of trees and free food and butterflies as far as the eye can see. Thus, I plan to never ever cook for myself again, allowing me to free up all the neurons I had previously dedicated to remembering how.

Just in case I'm wrong, let me exchange some of those neurons for electrons.

Note that I'm not a "foodie" or a gourmet or any of that stuff. This is just baseline information needed in order to be relatively happy without dying of starvation, boredom, or (overpriced ingredient induced) bankruptcy, in countries where you can die of bankruptcy.

Here we go:

  • Priority order for time-saving appliances: microwave, laundry machine, dishwasher, food processor, electric grill. Under no circumstances should you get a food processor before you get a dishwasher. Seriously. And I include laundry machine here because if you have one, you can do your laundry while cooking, which reduces the net time cost of cooking.

  • Cast-iron frying pans are a big fad among "foodies" nowadays. Normally I ignore fads, but in this case, they happen to be right. Why cast iron pans are better: 1) they're cheap (don't waste your money on expensive skillets! It's cast iron, it's supposed to be cheap!); 2) unlike nonstick coatings, they never wear out; 3) you're not even supposed to clean them carefully, because microbits from the previous meal help the "seasoning" process *and* makes food taste better; 4) they never warp; 5) they heat very gradually and evenly, so frying things (like eggs) is reliable and repeatable; 6) you can use a metal flipper and still never worry about damage; 7) all that crap advice about "properly seasoning your skillet before use" is safe to ignore, because nothing you can do can ever possibly damage it, because it's freakin' cast iron. (Note: get one with a flat bottom, not one with ridges. The latter has fewer uses.)

  • You can "bake" a potato by prodding it a few times with a fork, then putting it on a napkin or plate, microwaving it for 7 minutes, and adding butter. I don't know of any other form of healthy, natural food that's as cheap and easy as this. The Irish (from whom I descend, sort of) reputedly survived for many years, albeit a bit unhappily, on a diet of primarily potatoes. (Useless trivia: the terrible "Irish potato famine" was deadly because the potatoes ran out, not because potatoes are bad.) Amaze your friends at work by bringing a week's worth of "lunch" to the office in the form of a sack of potatoes. (I learned that trick from a co-op student once. We weren't paying him much... but we aimed to hire resourceful people with bad negotiating skills, and it paid off.)

  • Boiled potatoes are also easy. You stick them in a pot of water, then boil it for half an hour, then eat.

  • Bad news: the tasty part of food is the fat. Good news: nobody is sure anymore if fat is bad for you or not, or what a transfat even is, so now's your chance to flaunt it before someone does any real science! Drain the fat if you must, but don't be too thorough about it.

  • Corollary: cheaper cuts of meat usually taste better, if prepared correctly, because they have more fat than expensive cuts. "Correctly" usually means just cooking on lower heat for a longer time.

  • Remember that cooking things for longer is not the same as doing more work. It's like wall-clock time vs. user/system time in the Unix "time" command. Because of this, you can astonish your friends by making "roast beef", which needs to cook in the oven for several hours, without using more than about 20 minutes of CPU time.

  • Recipe for french toast: break two eggs into a bowl, add a splash of milk, mix thoroughly with a fork. Dip slices of bread into bowl. Fry in butter in your cast iron pan at medium heat. Eat with maple syrup. And don't believe anyone who tells you more ingredients are necessary.

  • Recipe for perogies: buy frozen perogies from store (or Ukranian grandmother). Boil water. Add frozen perogies to water. Boil them until they float, which is usually 6-8 minutes. Drain water. Eat.

  • Recipe for meat: Slice, chop, or don't, to taste. Brown on medium-high heat in butter in cast-iron skillet (takes about 2 minutes). Turn heat down to low. Add salt and pepper and some water so it doesn't dry out. Cover. Cook for 45-60 minutes, turning once, and letting the water evaporate near the end.

  • Recipe for vegetables: this is a trick question. You can just not cook them. (I know, right? It's like food *grows on trees*!)
Hope this advice isn't too late to be useful to you. So long, suckers!

Syndicated 2011-03-24 03:38:29 (Updated 2011-03-27 02:09:10) from apenwarr - Business is Programming

The Google Vortex

For a long time I referred to Google as the Programmer Black Hole: my favourite programmers get sucked in, and they never come out again. Moreover, the more of them that get sucked in, the more its gravitation increases, accelerating the pull on those that remain.

I've decided that this characterization isn't exactly fair. Sure, from our view in the outside world, that's obviously what's happening. But rather than all those programmers being compressed into a spatial singularity, they're actually emerging into a parallel universe on the other side. A universe where there *is* such a thing as a free lunch, threads don't make your programs crash, parallelism is easy, and you can have millions of customers but provide absolutely no tech support and somehow get away with it. A universe with self-driving cars, a legitimate alternative to C, a working distributed filesystem, and the entire Internet cached in RAM.

A universe where on average, each employee produced $425,450 in profit in 2010, after deducting their salary and all other expenses. (Or alternatively: $1.2 million in revenue.)

I don't much like the fact of the Google Vortex. It's very sad to me that there are now two programmer universes: the haves and the have-nots. More than half of the programmers I personally know have already gone to the other side. Once you do, you can suddenly work on more interesting problems, with more powerful tools, with on average smarter people, with few financial constraints... and you don't have to cook for yourself. For the rest of us left behind, the world looks more and more threadbare.

A few people do manage to emerge from the vortex, providing circumstantial evidence that human life does still exist on the other side. Many of them emerge talking about bureaucracy, politics, "big company attitude", projects that got killed, and how things "aren't like they used to be." And also how Google stock options aren't worth much because they've already IPO'd. But sadly, this is a pretty self-selecting group, so you can't necessarily trust what they're complaining about; presumably they'll be complaining about something, or they wouldn't have left.

What you really want to know is what the people who didn't leave are thinking. Which is a problem, because Google is so secretive that nobody will tell you much more than, "Google has free food. You should come work here." And I already knew that.

So let's get to the point: in the name of science (and free food, and because all my friends said I should go work there), I've agreed to pass through the Google Vortex starting on Monday. The bad news for you is, once I get through to the other side, I won't be able to tell you what I discover, so you're no better off. Google doesn't stop its employees from blogging, but you might have noticed that the blogs of Googlers don't tell you the things you really want to know. If the NDA they want me to sign is any indication, I won't be telling you either.

What I can do, however, is give you some clues. Here's what I'm hoping to do at Google:

  • Work on customer-facing real technology products: not pure infrastructure and not just web apps.
  • Help solve some serious internet-wide problems, like traffic shaping, real-time communication, bufferbloat, excessive centralization, and the annoying way that surprise popularity usually means losing more money (hosting fees) by surprise.
  • Keep coding. But apparently unlike many programmers, I'm not opposed to managing a few people too.
  • Keep working on my open source projects, even if it's just on evenings and weekends.
  • Eat a *lot* of free food.
  • Avoid the traps of long release cycles and ignoring customer feedback.
  • Avoid switching my entire life to Google products, in the cases where they aren't the best... at least not without first making them the best.
  • Stay so highly motivated that I produce more valuable software, including revenue, inside Google than I would have by starting a(nother) startup.
Talking to my friends "on the inside", I believe I can do all those things. If I can't achieve at least most of it, then I guess I'll probably quit. Or else I will discover, with the help of that NDA, that there's something even *better* to work on.

So that's my parting gift to you, my birth universe: a little bit of circumstantial evidence to watch for. Not long from now, assuming the U.S. immigration people let me into the country, I'll know too much proprietary information to be able to write objectively about Google. Plus, speaking candidly in public about your employer is kind of bad form; even this article is kind of borderline bad form.

This is probably the last you'll hear from me on the topic. From now on, you'll have to draw your own conclusions.

Syndicated 2011-03-23 22:29:01 from apenwarr - Business is Programming

Suggested One-Line Plot Summaries, Volume 1 (of 1)

"The Summer of My Disco-tent."

Discuss.

Syndicated 2011-03-20 20:42:42 from apenwarr - Business is Programming

Celebrating Failure

I receive the monthly newsletter from Engineers Without Borders, an interesting organization providing engineering services to developing countries.

Whether because they're Canadian or because they're engineers, or both, they are unusual among aid organizations because they focus on understanding what didn't work. For the last three years, they've published Failure Reports detailing their specific failures. The reports make an interesting read, not just for aid organizations, but for anyone trying to manage engineering teams.

I wish more organizations, and even more individuals would write documents like that. I probably should too.

Syndicated 2011-03-18 22:03:22 from apenwarr - Business is Programming

598 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!