Prediction update

In mid-2009 I said:

Personally, I still don't see I Robot coming to life any time soon, but I do see things that got written off as impossible during the dead-and-debunked phase starting to stir to life again. I'm thinking, say, competent machine translation or robots that can pick things up and carry them around a house, happening gradually in the next decade or so.

So we're about 70% of the way there now.  I retried the round-trip translations from this post with a popular translation tool and got considerably better results, maybe even what you might call "competent".  I don't see any signs of thing-lugging robots appearing in the stores as mass-market consumer products in the next couple of years, but I wouldn't be surprised if someone somewhere is selling such a thing before long -- or has already.

That's the nice thing about vague predictions -- it all depends on how you count.

Wikipedia considered harmful ... or not

In an old post on Wikipedia, I said that

[I]t's easy to spot a backwater article that hasn't seen a lot of editing. This is not necessarily a bad thing. Obscure math articles, for example, tend to read like someone's first draft of a textbook, full of "Let x ..." and "it then clearly follows that ..." The prose may be a bit chewy, but whoever wrote it almost certainly cared enough to get the details right.

My feeling was that if you were really interested in, say, the functoriality of singular homology groups,  you'd probably have enough context to chew through prose like "This generality implies that singular homology theory can be recast in the language of category theory."*

In a recent ars technica article, John Timmer argues that impenetrable technical articles are actively harmful: "The problematic entries reinforce the popular impression that science is impossible to understand and isn't for most people—they make science seem elitist. And that's an impression that we as a society really can't afford."

I think that's a good point, but I'm not sure how bad the problem really is in practice.  A hard-to-read article is most likely to be harmful if a lot of people are seeing it, which also makes it more likely that someone will be able to improve it.  This is a fundamental assumption of Wikipedia in general, I think.  As such, it would be interesting to see some data behind it -- is there a strong correlation between the number of times a page is landed on and the number of edits (or edits per word, or such)?

Assuming that correlation holds, then someone coming to Wikipedia to learn about, say, physics should have a good chance at a gentle introduction.  Let's try:

• The main article on Physics seems like a perfectly good Wikipedia page.  It starts with a general introduction, goes into history, core theories, relation to other fields and so forth.  Let's look at one of those fields:
• Condensed matter physics still seems to be in good shape.  The first sentence doesn't seem completely useful at first: "Condensed matter physics is a branch of physics that deals with the physical properties of condensed phases of matter," but the next paragraph goes on to explain nicely what a condensed phase of matter is.  The rest of the article continues in a well-structured way to give an outline of the field.  Let's look at one of the theoretical aspects:
• Symmetry breaking "needs attention from an expert in Physics".  I'd agree with that assessment.  The general idea is still there, but we're definitely getting technical: "In physics, symmetry breaking is a phenomenon in which (infinitesimally) small fluctuations acting on a system crossing a critical point decide the system's fate, by determining which branch of a bifurcation is taken."  For example, what's a bifurcation?  Well, we can at least chase the link and find out:
• Bifurcation theory is actually a better-structured article, but no less technical.  It's actually a math article, not a physics article.

I would say that either of the last two would be intimidating to a non-physicist/mathematician.  I don't know if you could say the same about the first two.  Yes, there are still technical terms and concepts, but it's pretty hard to get away from that and still cover the material.  I would also say that a non-physicist interested in physics in general would be far more likely to land on the Physics article than the other three.

I also noticed that, while I have run across a few really impenetrable technical articles in Wikipedia, it didn't seem -- in this particular random walk, at least -- that the quality of the articles dropped off steadily as one went off the beaten path.  Fields intersect, and perhaps you're never too far from someone's beaten path.  I did chase a link from Bifurcation Theory to Stationary point, which was marked "The verifiability of all or part of this article is disputed", not something one expects in math articles, but it didn't seem particularly better or worse than the previous two, the warning notwithstanding.

Let's say that the random walk above is fairly representative -- and I think it is, based on other experience browsing Wikipedia.  What of Timmer's claim that general interest articles such as The Battle of the Wilderness are accessible, while technical articles such as Reproducing kernel Hilbert space are hostile?

I suspect Selection bias.  Timmer (and myself, and anyone who browses a lot of technical articles) sees a lot more technical articles than the average reader.  In fact, we should broaden that a bit and say "specialized" instead of "technical".  Just as math geeks might read a lot of math articles, history geeks will read a lot of history articles, sports geeks a lot of sports articles and so forth.  Should we really expect Reproducing kernel Hilbert space to be as newbie-friendly as The Battle of the Wilderness when the battle site has a plaque on a public highway talking about it?

Let's try following History like we did for Physics above, since Timmer's example of an excellent article is from that field.  The first area of study is Periodization, and already we see a notice that the article's sources remain unclear.  A large chunk of the article covers Marxian periodisation, giving the almost certainly false impression that this is the only significant way that historians divide history into periods.  This section seems to be a copy of the corresponding section in Marx's theory of history, suggesting that one of the most basic Wikipedia cleanups -- making sure that the bulk of the information is in one definitive place and everything else links to that place -- hasn't been done.

Just as impenetrable math or physics articles may give the impression that scientists are a bunch of elitists, the article on Periodization -- the second history article I tried -- may give the impression that historians are a bunch of leftists.  So maybe Wikipedia as a whole is unfriendly to academics as a whole?  That would be a sad irony indeed, but I doubt that's really what's going on.  Wikipedia is filling more than one function, after all.  It's a general introduction in some places, and a specialized reference work in others.  That seems fine.

There's a lot more to be said here.  Maybe survey articles like the ones on physics and history are the wrong place to look -- not that we've really defined what we're looking for.  I tried putting "The battle of" into the search bar and clicking on a few of the battles that came up.  All the articles seemed quite well written.  Perhaps the Wikipedia process works better for documenting specific events?  Or perhaps the search bar was just showing me the most popular articles, which in turn would be popular for being well written and well-written for being popular?

Overall, the proposition that Wikipedia articles on the sciences are bad for the sciences seems like a testable hypothesis, at least in principle, but properly testing it requires a lot more machinery -- methodology, statistical models, surveys, etc. -- than you'll find in a blog post or op-ed.  Without a more thorough study, we should take assertions like Timmer's as good starting points, not conclusions.

* I should point out that the article I linked to is not necessarily the kind of article that Timmer is complaining about.  I just picked a handy example of a technical article that would probably not be too familiar to most readers.  Yep, I ... just happened ... to be reading up on singular homology theory over my winter break.  What can I say?

Field notes: Proudly answering none of your pressing questions

Browsing through old posts and statistics, one thing that jumped out is that a fair chunk of traffic comes from people seeking answers to questions I specifically don't answer.  Examples:

• Information age: Not dead yet was a reply to someone else's blog post, arguing that you couldn't really say when an "age" began or ended, and in any case "ages" tend to overlap rather than each new age supplanting the last.  If you came there searching for "When did the information age begin/end?", as several people have, you may be disappointed.
• Off topic: Welcome to the new decade was, well, first of all, off topic.  It's a pet peeve of mine that people will argue that everybody gets some fine point of usage wrong, in this case when decades start.  Somewhere I ran across someone's argument that a decade is just a block of ten years and you can start one whenever you want, and that clicked.  I really should have linked to wherever I read that, but then, I doubt it was their original idea either.  In any case, if you landed there looking to settle a bar bet about whether 2010 was the first year of a new decade, you may be disappointed.
• Now what happened to my bookmarks? Was further speculation on a previous post about why I no longer found myself using my browser's bookmark feature so much and never really ended up doing much with deli.cio.us (Remember them? They still seem to be around, actually, under plain delicious.com).  Naturally, pretty much anyone who ended up there was searching for help in recovering lost browser bookmarks.  I added some links for that up at the top a few years back, and even updated them a couple of times, but I have no idea if they're still useful.  As I said, I don't really use bookmarks myself anymore.
• "When I use a word, it means just what I choose it to mean" is the most popular Field Notes post of all time.  I'm not sure exactly what brought people to it -- the bulk of the activity seems to have scrolled off the easy-to-find summaries -- but it's just a rant on an annoying customer service involving spectacular overuse of boilerplate macros.  If you were thinking Alice in Wonderland, you would probably have given up a little past the title.

Two of these are genuine Field Notes posts -- analysis of things webby.  But those are the two that people seem to land on mainly in search of something else.  The other two, that is, the ones people might end up on more-or-less on purpose (depending on what was driving traffic to the last one), don't really convey what this blog is mostly about.  Of those two, the one that people probably land on looking for answers doesn't really answer the question.

And I'm not even disappointed.  To the contrary, there's something in all this that's deeply reflective of the web as I understand it.

My phone, then and now (or: Maybe coverage is the new coverage?)

(August? Really?  This must be a record gap even for the new, unhurried Field Notes.  Oh well ... it's been busy)

Re-reading through the blog, I ran across a short post on wireless carriers' advertising having shifted from coverage to bandwidth.  Most old posts seem to hold up well, but this one seemed remarkably out of date:

• With 4G building out, coverage is very much an issue -- at least in ads
• At the time I was using a "feature phone", mainly as an alarm clock and ... as a phone.  I finally took the plunge with a proper smart phone a while back.  I use it as ... 
• An alarm clock
• A phone
• A GPS
• A way to check email
• A camera (but I also used the old feature phone as that)
• A way to browse news stories, check sports scores, weather etc.
• A way to text -- it's noticeably easier to text with autocomplete, though not miraculously so
• A way to schedule appointments and to check my schedule and reminders
• A way to look up stuff quickly on the web
• A few other random applications

It's interesting that even feature phones had several of those -- phone, clock, text, camera, calendar -- and probably more or less the right set of them to get the most out of the limited bandwidth and CPU.  The newer iterations are generally better (auto backup of photos to the cloud comes to mind), but not mind-blowingly, night-and-day better.

My attitude at the time was "Meh ... I'm usually near my laptop and it has a bigger screen"  While I find I use my phone quite a bit during the day, I'm still near my laptop most of the time, and I'd only really miss the phone for really "mobile" applications, like

• phone
• GPS
• camera
• receiving texts anywhere
• checking email everywhere

Oh ... and as an alarm clock.

Margaret Hamilton: 1 New Horizons: 0

A bit more on Pluto, from a compugeek perspective if not a full-on web perspective ...

The New Horizons flyby was not completely without incident.  Shortly before the flyby itself, the craft went into "safe mode", contact was lost for a little over an hour and a small amount of scientific data was lost.  The underlying problem was "a hard-to-detect timing flaw in the spacecraft command sequence".  This quite likely means what's known in the biz as a "race condition", where two operations are going on at the same time, the software behaves incorrectly if the wrong one finishes first and the developers didn't realize it mattered.

Later investigation concluded that the problem happened when "The computer was tasked with receiving a large command load at the same time it was engaged in compressing previous science data."  This means that the CPU would have been both heavily loaded and multitasking, making it more likely that various "multithreading issues" such as race conditions would be exposed.

Now, before I go on, let me emphasize that bugs like this are notoriously easy to introduce by accident and notoriously hard to find if they do creep in, even though there are a number of well-known tools and techniques for finding them and keeping them out in the first place.

The incident does not in any way indicate that the developers involved can't code.  Far from it.  New Horizons made it through a ten-year, five billion kilometer journey, arriving within 72 seconds of the expected time, and was able to beam back spectacularly detailed images.  That speaks for itself.  It's particularly significant that the onboard computers were able to recover from the error condition instead of presenting the ground crew with an interplanetary Blue Screen of Death.  More on that in a bit.

Still ...

It's July 20, 1969.  The Apollo 11 lunar lander is three minutes from landing on the Moon when several alarms go off.  According to a later recounting by the leader of the team involved

Due to an error in the checklist manual, the rendezvous radar switch was placed in the wrong position. This caused it to send erroneous signals to the computer. The result was that the computer was being asked to perform all of its normal functions for landing while receiving an extra load of spurious data which used up 15% of its time.

This is a serious issue.  If the computer can't function, the landing has to be aborted.  However,

The computer (or rather the software in it) was smart enough to recognize that it was being asked to perform more tasks than it should be performing. It then sent out an alarm, which meant to the astronaut, I'm overloaded with more tasks than I should be doing at this time and I'm going to keep only the more important tasks; i.e., the ones needed for landing ... Actually, the computer was programmed to do more than recognize error conditions. A complete set of recovery programs was incorporated into the software. The software's action, in this case, was to eliminate lower priority tasks and re-establish the more important ones.

This is awesome.  Since "awesome" is generally taken to mean "kinda cool" these days, I'll reiterate: The proper response to engineering on this level is awe.  Let me try to explain why.

Depending on where you start counting, modern computing was a decade or two old at the time.  The onboard computer had "approximately 64Kbyte of memory and operated at 0.043MHz".  Today, you can buy a system literally a million times faster and with a million times more memory for a few hundred dollars.

While 64K is tiny by today's standards, it still leaves plenty of room for sophisticated code, which is exactly what was in there.  It does, however, mean that every byte and every machine cycle counts, and for that reason among others the code itself was written in assembler (hand-translated from a language called MAC and put on punch cards for loading).  Assembler is as low-level as it gets, short of putting in raw numbers, flipping switches or fiddling with the wiring by hand.

Here's a printout of that code if you're curious.  The dark bands are from printing out the listing on green-and-white-striped fanfold paper with a line printer such as used to be common at computer centers around the world.  The stripes were there to help the eye follow the 132-character lines.  Good times.  But I digress.

Just in case writing in assembler with an eye towards extremely tight code isn't enough, the software is asynchronous.   What does that mean?  There are two basic ways to structure a program such as this one that has to deal with input from a variety of sources simultaneously: the synchronous approach and the asynchronous approach.

Synchronous code essentially does one thing at a time.  If it's reading temperature and acceleration (or whatever), it will first read one input, say temperature from the temperature sensor, then read acceleration from the accelerometer (or whatever).  If it's asking some part of the engine to rotate 5 degrees, it sends the command to the engine part, then waits for confirmation that the part really did turn.  For example, it might read the position sensor for that part over and over until it reads five degrees different, or raise an alarm if doesn't get the right reading after a certain number of tries.

Code like this is easy to reason about and easy to read.  You can tell immediately that, say, it's an error if you try to move something and its position doesn't reach the desired value after a given number of tries.  However, it's no way to run a spaceship.  For example, suppose you need to be monitoring temperature continuously and raise a critical alarm if it gets outside its acceptable range.  You can't do that if you're busy reading the position sensor.

This is why high-performance, robust systems tend to be asynchronous.  In an asynchronous system, commands can be sent and data can arrive at any time.  There will generally be a number of event handlers, each for a given type of event.  The temperature event handler might record the temperature somewhere and then check to make sure it's in range.

If it's not, it will want to raise an alarm.  Suppose the alarm is a beep every five seconds.  In the asynchronous world, that means creating a timer to trigger events every five seconds, and creating an event handler that sends a beep command to the beeper when the timer fires (or, you can set a "one-shot" timer and have the handler create a new one-shot timer after it sends the beep command).

While all this is going on, other sensors will be triggering events.  In between "the temperature sensor just reported X" and "the timer for your beeper just went off", the system might get events like "the accelerometer just reported Y" and "the position sensor for such-and-such-part just read Z".

To move an engine part in this setup, you need to send it a command to move, and also create a handler for the position sensor's event.  That handler has to include a counter to remember how many position readings have come in since the command to move, along with the position the part is supposed to get to (or better, a time limit and the expected position).

A system like this is very flexible and doesn't spend time "blocked" waiting for things to happen, but it's also harder to read and reason about, since things can happen in any order and the logic is spread across a number of handlers, which can come and go depending on what the system is doing.

And then, on top of all this, the system has code to detect and recover from error conditions, not just in the ship it's controlling but in its own operation.  Do-it-yourself brain surgery, in other words.


I report my occupation as "software engineer" for tax purposes and such, but that's on a good day.  Most of us spend most of our time coding, that is, writing detailed instructions for machines to carry out.  True software engineering means designing a robust and efficient system to solve a practical problem.  The term was coined by Margaret Hamilton, the architect of the Apollo 11 control systems quoted above and a pioneer in the design of asynchronous systems.  As the story of the lunar landing demonstrates, she and her team set a high bar for later work.

New Horizons ran into essentially the same sort of problem that Apollo 11 did, but handled it less robustly (going to "safe mode" and then recovering, as opposed to automatically re-prioritizing), all building on techniques that Hamilton and her team helped develop, and using vastly more powerful equipment and development tools based on decades of collective experience.  So, with all due respect to the New Horizons team, I'd have to say Apollo 11 wins that one.

Latency, bandwidth and Pluto

As you may well know, the New Horizons spacecraft flew by Pluto last month, dramatically increasing our knowledge of Pluto and its moons (let's not even get into whether Pluto and Charon jointly constitute a "binary dwarf planet" or whatever).  There are even a few pictures on the web.

But wait ... that's not very many pictures for a ten-year mission.  Even worse, if you were watching at the time you'll know that New Horizons went completely dark for most of a day, right when it was flying by Pluto.  Isn't this the modern web, where everything is available everywhere instantly?  What gives, NASA?

Part of the problem is the way New Horizons is designed.  It's expensive to accelerate mass to the speed New Horizons is going, and since you can't exactly send a repair crew out to Pluto, it's good to have as few moving parts as possible.  As a result, the ship has a small battery and both the antenna and the cameras are mounted firmly in place.  If you want to turn the antenna toward Earth, you have to move the whole ship, using some of the small store of remaining fuel dedicated to course corrections and attitude control.  If you want to point the cameras toward Pluto, you have to turn the ship that way.  You can't do both.

That explains why the ship went dark for the duration of the flyby, but actually it effectively went dark for considerably longer than that.  It takes about 4.5 hours for a signal to travel the distance between Earth and Pluto.  That means the sequence of events is, more or less

• t + 0: Flight control sends commands to New Horizons to point the cameras at Pluto, take pictures, orient the antenna toward Earth, and report back.
• t + 4.5 hours: New Horizons gets the command and starts re-orienting and taking pictures
• t + 9 hours: Last time at which any signal from before the pointing operation will reach Earth
• t + 25.5 hours (more or less): New horizons, now with the antenna pointed back toward earth, sends "Phone home" message reporting status.
• t + 30 hours (more or less): "Phone home" message arrives

The important thing to note here is that, while the ship is actually out of contact for 21 hours, it's 25.5 hours from the time the command is sent to the time the ship is reachable again, and 30 hours before the ground crew knows it's reachable again.   If the phone home signal hadn't arrived, it would be 9 more hours, at a minimum, before they knew if any corrective action they'd taken had worked.  By internet standards this is ridiculously high latency, but anyone who's played a laggy video game or been on a conference call with people on the opposite side of the world has experienced the same problem on a smaller scale.

So part of the reason pictures have been slow in coming is latency.  It's going to take a minimum of 4.5 hours to beam anything back, and longer if the ground crew has to send instructions.

The other problem is bandwidth.  Pluto is about 5 billion kilometers (about 3 billion miles) away.  Signal strength drops off as the square of the distance, so, for example, a signal from Pluto is about 160 times weaker than a signal from Mars and, since the power source has to be small (around 15 watts), the signal is not going to be extremely powerful to start with.  Lower power means a lower signal to noise ratio and less bandwidth (or at least that's my dim software-engineer understanding of it -- in real life "bandwidth" doesn't exactly mean "how many bits you can transmit", and I'm sure there's lots more I'm glossing over).

Put all that together and on a good day we have about 2Kbps coming back from Pluto.  That's about what you could get out of a modem in the mid 1980s.   Internet technology has progressed just a bit since then, but internet technology doesn't have to cope with vast distances and stringent mass limitations.  At 2Kbps, one raw image from LORRI (the hi-res black-and-white camera) takes close to two hours to transmit.  This is why, if all goes well, we'll be getting Pluto pictures (and other data) well into 2016.

I'd still say that New Horizons is "on the web" in some meaningful sense, but the high latency and low bandwidth make it a great example of Deutsch's fallacies in action.

[Update: Not only is New Horizons sending back data slowly, it's not sending back particularly pretty data at the moment.  From their main page:

Why hasn’t this website included any new images from New Horizons since July? As planned, New Horizons itself is on a bit of a post-flyby break, currently sending back lower data-rate information collected by the energetic particle, solar wind and space dust instruments. It will resume sending flyby images and other data in early September.

-- D.H. 24 Aug 2015]

A decoy within a decoy ...

It's not news that more-or-less legitimate news sites like to surround their articles with enticing links to somewhat-less-legitimate news sites: 20 reasons your dog may be considering a new career ... You'll never believe this simple secret for removing egg yolk from pine trees ... Read this before you buy a moose ... you know, those sorts of things.

Click through on one of those and there's a good chance there will be some sort of slide show surrounded by a minefield of garish ads.  Sure, why not?  Putting together pictures of whatever sort of fluff for people to page through is somewhere around neutral on my personal scale of good or bad ways to make a living.

Except, when you lay out the page with a large ad at the top with an arrow icon next to it, and white space between, looking for all the world like it's going to take you to the article you're really interested in (well, at least maybe kinda interested in).  Except that arrow icon takes you to the advertiser's page.  That tilts ever so slightly toward "bad" in my book.  For the reader, it's a straight-up bait and switch.  For the advertiser, it's a steady stream of annoyed readers and, if it's a pay-per-click model, they get to pay for the privilege.  True, there's not supposed to be any such thing as bad publicity, but still.

OK, this is cool, and it's on the web:

Hyrodium is the pseudonym (presumably) of a Japanese student who has put together a really neat blog of visualizations of mathematical proofs and objects.  Exactly the kind of thing the Web was originally supposed to be good for, and sometimes still is.

The mobile web in a nutshell

Randall Munroe FTW

Now available on its own domain

At least for the next year, more or less, you'll be able to reach this blog not only at fieldnotesontheweb.blogger.com, but at plain old fieldnotesontheweb.com.  I doubt this will really affect anyone's life greatly, but hey, why not?

Protocol basics: Packets and connections

Not so long ago, the easiest way, and in some cases the only practical way, to get in touch with someone a long distance away was to send a message by mail.  Physical mail, that is.  I found it handy when traveling in Europe, um a while ago, for example.  Rather than hunt down a payphone (really, spell check, you don't recognize "payphone"?), double-check that the other person was likely to be awake, buy a card or assemble the right pile of coins, dial, wait to see if the other person was actually home, and then worry about cramming a conversation into an alarmingly small number of minutes, it was often easier and more fun to buy a few postcards, scrawl "Having a lovely time, wish you were" on them, address them, stamp them and throw them in the nearest post box.

It's not that one couldn't make an international phone call, or that it was never worth it, just that it was often cheaper and easier not to.

Mail and the telephone are canonical examples of two basic ways of sending information.  These two ways have gone by various names, but the two that stick in my head are "packet-switched" (mail) vs. "circuit-switched" (phone), and "connection-oriented" (phone) vs. "connectionless" (mail).  Each approach has its own pros and cons and neither is perfect for every situation, which is why both are still going strong.

Connection-oriented protocols require time to set up the connection.  In the case of the telephone, this means identifying the other party (dialing the number) and establishing a connection (whatever the phone company does, plus waiting for the other party to pick up).  Both parties must participate in the connection at the same time.  Once this is done, however, communication is efficient.  I say something to you and you can reply immediately.  Depending on the exact protocol, we may even be able to both talk at once ("full-duplex") or we may have to take turns ("half-duplex"), but this distinction is more important in computer protocols than human conversations (human conversations are effectively half-duplex, as anyone who's ever said "no, you go ahead" at the same time as the other person will realize).

Connectionless protocols are the mirror image of this.  Setup is minimal.  You only have to identify the other party and send the message.  Depending on the protocol, your party may or may not have to be present to receive the message when it arrives.  On the other hand, you generally don't know whether your message arrived at all, and if you send two messages to the same person, they may or may not arrive in the order you sent them, and in some cases the same message might get sent more than once (though this is not likely to happen through the mails).

Of the common ways we exchange information as people, some are connection-oriented, for example, phone calls and video conferences, and some are connectionless, such as texting and email.

The underlying protocol of most of the internet, IP (for ... wait for it ... Internet Protocol) is connectionless.  You build a packet of data, slap an address on it, send it and hope for the best.  Generally there is no specific connection involved, though it used to be more common (in the days of dedicated T1 lines, PLIP and such) for IP to run on top of something that happened to us a point-to-point connection at a lower level.

However, most actual applications of the internet are connection-oriented.  When you browse a web page, for example, your browser uses a connection to the server serving the page.  That way it doesn't care whether the page fits in a single packet (which it almost certainly doesn't) and it knows for sure when it's retrieved the entire page.  Likewise, when you send mail, your mail client makes a connection to a mail server, when you join a videoconference your device makes a connection to the videoconference server, and so forth.

To bridge this gap, we use what is hands-down one of the most successful inventions in the field of computing: the Transmission Control Protocol, or TCP.  TCP assumes that you have some way -- it doesn't much care what -- to deliver packets of information -- it doesn't care what's in them and doesn't much care how big they are -- to a given address.  IP is one way of doing this, so you'll see the term TCP/IP for TCP using IP to transport packets, but it's not the only way.

From these basic assumptions, TCP allows you to pretend you have a direct connection to another party.  If you send a series of messages to that other party, you know that either they will all arrive, in order, or the whole connection will fail and you will know it failed.

This is a big improvement over simply sending messages and hoping they arrive.  The cost is that it takes time to set up a TCP connection, TCP adds extra traffic, particularly ACK (acknowledgement) messages to be sure that messages have arrived, it may have to re-send messages, and it requires each side of the connection to remember a certain amount of previous traffic.  For example, if I'm sending you a bunch of data, TCP will break that down into packets, and then keep track of which packets have and haven't been acknowledged.  If too many haven't been acknowledged, it will stop sending new data, slowing things down.  Each side also has to keep around any packets that it's sent but hasn't had acknowledged yet, since it may have to resend them.

Since setting up connections is expensive, we try to avoid it.  The worst case is establishing a fresh connection for each message to be sent.  In the early days of the web, HTTP/1.0 required a fresh connection for each object retrieved.  If your web page included an image, the browser would have to set up one connection to get the text of the web page, tear it down, and then set up a fresh connection to get the image, even if it was stored on the same server.  HTTP/1.1 fixed this with its "keep-alive" mechanism, but the same problem comes up in other contexts, with the same solution: re-use connections where possible.

A great many "application layer" protocols are built on TCP.  They all start by making a connection to a remote host and then sending messages back and forth on that connection.  These include

• HTTP and HTTPS, the fundamental protocols of the web
• SMTP, POP and IMAP, used for email
• SSL/TLS, for making secure connections to other hosts (HTTPS is essentially HTTP using SSL/TLS)
• SSH, also used for making secure connections to other hosts
• FTP, SFTP and FTPS, used for transferring files (technically, SFTP is built on SSH, which is in turn built on TCP)
• XMPP, one way of sending short messages like texts
• Any number of special purpose protocols developed over the years

Several of these (particularly SSH and HTTP) allow for "tunneling" of TCP, meaning you can establish a TCP connection on top of SSH or TCP, which will in turn be using a different TCP connection.  There are actually legitimate reasons to do this.

To bring things full circle, email protocols and file transfer protocols are essentially packet protocols, just with nicer addresses and bigger packets.  You could, in principle, use them as an underlying protocol for TCP.  This would be hugely inefficient for a number of reasons.  Among others, you'd generally be paying the cost of setting up a connection for each "packet", which is pretty much the worst of both worlds ... but it's certainly possible.  In a more abstract way, an email thread is essentially an ad-hoc connection on top of email (packets), which in turn is delivered via TCP (connection), which in turn (generally) uses IP (packets).

Bitcoin: Volume matters

It's easy to get fixated on prices, particularly if the price you're interested in keeps going up and up and up (or down and down and down).  In early December of 2013, for example, when Bitcoin was trading over $1000 with no limit in sight, the only logical conclusion was that it would soon take over the world.

Since then, the dollar price of BTC has fallen into the 300s.  Considering that the famous 10,000 BTC pizza would be $3 million at today's prices (if just a bit stale), that's still pretty good.  On the other hand, it's around a quarter of the peak price.

The exact exchange rate between BTC and reserve currencies shouldn't really matter greatly, though, so long as it's reasonably stable and there's enough money supply to handle whatever it is BTC is being used for.  But what about volume?  How much BTC is changing hands on a given day?  How much Bitcoin, measured in dollars or some other reserve currency, is there in all?

As an aside, there's a whole body of established techniques for using volume in conjunction with price to make buying and selling decisions.  I won't even pretend to know much about that.  I'm more interested in how Bitcoin stacks up against other currencies (if you consider it a currency) and money transfer networks (if you consider it that).

According to bitcoincharts.com, around half a million Bitcoins are "sent" daily, or about $150 million worth at current prices.  I believe this is taken from the blockchain that records all Bitcoin transactions, and so would include activity on the various exchanges, miners collecting and redeeming their bounties, direct transfers of BTC to and from long-term holdings (the "pure" Bitcoin economy) and whatever else.

If I buy a Bitcoin for $320 or whatever, that would show up as one Bitcoin sent to me from the exchange, and if I use that Bitcoin to pay you for some good or service, that would in turn show up as one Bitcoin sent to you, and if you turn around and sell that Bitcoin for $320, that's another Bitcoin sent, to the exchange from you.  In other words, a typical transaction using Bitcoin as an intermediary between reserve currencies will be counted three times.  If we want to consider Bitcoin as a money transfer network, we should probably allow for some amount of non money-transfer activity, then divide by three, but in what follows let's count all $150 million, if only because it's simpler.

The Bitcoin money supply is deliberately easy to calculate.  While there are several measures of "how many dollars are there?", the total number of Bitcoins at any given time is a known parameter of the protocol.  Currently, the BTC money supply is about 14 million, or $4 billion.

By contrast:

• About 100 nations have more than $4 billion in currency
• The US M1 money supply is around $2 trillion, or about 500 times the Bitcoin money supply
• The US M2 money supply is around $12 trillion, or about 3000 times the Bitcoin money supply
• The US GDP is close to $50 billion per day, or about 300 times total Bitcoin activity (1000 times or more if you buy the triple-counting argument above)
• VISA processes about $9 billion in transactions every day, or about 60 times total Bitcoin activity (or about 200+ with triple-counting)

and so forth.

I'm actually struck that the Bitcoin economy, or whatever you want to call it, is as big as it is.  There may be 100 countries with more money, but there are also 50 or so with less.  You could literally run a small country on Bitcoin.  I'm not saying it would be good policy, but in some sense the numbers are there.  A small fraction of US GDP is still a fair bit, as is a small fraction of Visa.  For a while Bitcoin was arguably bigger than Western Union.  Your call whether that's a matter of Bitcoin being big, WU being small, or some of both.

The main point remains: If you want to get an idea of how important Bitcoin might be, don't look at the price alone.  Look at volume as well.