Given HN's recent obsession with Bitcoins, it's probably worth noting that the "double-spend" problem is a variation on the Two Generals problem (or, more accurately, the Byzantine Generals problem). Regardless of your views on Bitcoin as a currency replacement, it's hard to deny that the block chain is a rather clever solution to this problem.
Of course, it's not exactly a breakthrough solution. As noted in the article, it is possible to increase the confidence of coordination at the expense of speed and resources. In this case, requiring the "commander" to commit limited resources (computational power to generate hashes) and a majority of the "lieutenants" to agree on one commander's solution, then chaining multiple decision events together, the result is actually fairly robust.
Obviously, for most use cases something like the block chain is completely impractical. You wouldn't want to have to wait an hour for each commit to your web app's database. That said, it will be interesting to see if future variations on this theme make their way into other applications.
You may be interested in looking into some of the research that has been done in other areas on Byzantine consensus. Depending on the system model, solutions that are much more efficient than the Bitcoin block chain (but have other tradeoffs) exist. For example, check out Castro and Liskov (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.127....). Personally, I think some people in the Bitcoin community have been a bit dishonest in claiming that bitcoin's protocol solves a consensus problem which wasn't solvable before.
Lower bounds on Byzantine consensus in any practical system model exist which makes it very attractive, for efficiency reasons, to solve a subset of that problem for things like database replication in trusted systems. Lower bounds for consensus vary from f+1 (for f faults) to 2f+1 to 3f+1 depending on what kinds of faults you admit. Still it's very interesting to think about.
Of course, it's not exactly a breakthrough solution. As noted in the article, it is possible to increase the confidence of coordination at the expense of speed and resources. In this case, requiring the "commander" to commit limited resources (computational power to generate hashes) and a majority of the "lieutenants" to agree on one commander's solution, then chaining multiple decision events together, the result is actually fairly robust.
Obviously, for most use cases something like the block chain is completely impractical. You wouldn't want to have to wait an hour for each commit to your web app's database. That said, it will be interesting to see if future variations on this theme make their way into other applications.