description: Bitcoin's long gestation indicates it is an example of the 'Worse is Better' paradigm

...

Some wonder who is the real man under the Satoshi Nakamoto mask; a hard question - how many libertarian cryptographers are there? But the interesting thing is, Satoshi could be *anybody*. Bitcoin involves no major intellectual breakthroughs, so Satoshi need have no credentials in cryptography or be anything but a self-taught programmer! Satoshi published his [whitepaper](http://www.bitcoin.org/bitcoin.pdf) May 2009^[`bitcoin.org` was registered 18 August 2008, so presumably Satoshi had been developing the bitcoin idea at least as early as 2008.], but if you look at the cryptography that makes up Bitcoin, they can basically be divided into:

- Public key cryptography

- Cryptographic signatures

- Cryptographic hash functions

- Hash chain used for proof-of-work

i. Hash tree

ii. Bit gold

- cryptographic time-stamps

# Pre-requisites

> "So the first answer to Why Now? is simply 'Because it's time.' I can't tell you why it took as long for weblogs to happen as it did, except to say it had absolutely nothing to do with technology. We had every bit of technology we needed to do weblogs the day Mosaic launched the first forms-capable browser. Every single piece of it was right there. Instead, we got Geocities. Why did we get Geocities and not weblogs? We didn't know what we were doing."^[["A Group Is Its Own Worst Enemy"](http://www.shirky.com/writings/group_enemy.html), by [Clay Shirky](!Wikipedia), published July 1, 2003 on the "Networks, Economics, and Culture" ML]

The interesting thing is that by even the most generous accounting, all the pieces were in place for at least 8 years before Satoshi's publication, which was followed more than half a year later^[The first revision in the [Github repository](https://github.com/bitcoin/bitcoin) is dated August 2009 by 'sirius-m'.] by the first public[^private] prototype. If we look at the citations in the whitepaper and others, and then order the relevant technologies by year in descending order:

[^private]: Satoshi claims that before he write the whitepaper, he [wrote a prototype](http://www.mail-archive.com/cryptography@metzdowd.com/msg10011.html)

1. 2001-2005[^bit-gold]: Nick Szabo, Bit Gold

2. 2001: [SHA-256](!Wikipedia) finalized

3. 1998: Wei Dai, [B-money](http://weidai.com/bmoney.txt)^[In the same vein of 'the network is a third party which keeps a copy of all signed transactions', you could include Ian Grigg's 2005 paper ["Triple Entry Accounting"](http://iang.org/papers/triple_entry.html).]

[^bit-gold]: It's hard to figure out when Szabo devised bit gold; his [post](http://unenumerated.blogspot.com/2005/12/bit-gold.html) claims to be from December 2008 but the URL indicates 2005 and it is linked in November 2008 emails. Szabo has long been interested in proof-of-work systems, writing on them in ~1998. [A paper](http://web.archive.org/web/20101008225926/http://szabo.best.vwh.net/ttps.html) started in 2001 motivates the existence of bit gold and describes, but that may be material from the 2004 or 2005 revisions. [Hal Finney](!Wikipedia "Hal Finney (cypherpunk)") [mentioned](http://www.mail-archive.com/cryptography@metzdowd.com/msg09975.html) bit gold in 2008 (in the context of a bitcoin discussion) describing Szabo's proposal as 'many years ago', and inasmuch as Hal has been active in cryptography circles since the '80s (was a member of the Cypherpunks mailing list etc.), it seems unlikely Hal was speaking of something then just 3 years ago.

This lack of novelty is part of the appeal - the fewer new parts of a cryptosystem, the less danger^[In cryptography, new parts are guilty until proven innocent. [Hundreds of past systems](!Wikipedia "Category:Broken cryptography algorithms") have been broken, sometimes after decades of study & use.]. All that was lacking was a Satoshi to start a Bitcoin.

# Delay

But why this delay? If the idea is easy to understand and uses basic ideas[^laurie], if it is very far from the cutting-edge of cryptography^[One thinks of the formidable mathematical difficulties surrounding the area of [homomorphic encryption](!Wikipedia) where one *would* expect any breakthrough to be from a bona fide genius, or at least a credentialed expert.], then there's no obvious reason it would not be seriously tried. Certainly the [cypherpunks](!Wikipedia) of the '90s were wildly creative, inventing everything from [Cypherpunk](!Wikipedia "Cypherpunk anonymous remailer")/[Mixmaster](!Wikipedia "Mixmaster anonymous remailer") to [MojoNation](!Wikipedia) to [assassination markets](!Wikipedia) to [data havens](!Wikipedia) (memorably depicted in _[Cryptonomicon](!Wikipedia)_). We have already seen 2 of their proposed cryptocurrencies, and proof-of-work was one of the most common proposals to deal with the rising tsunami of spam^[Although ironically, proof-of-work never seemed to go into widespread use because of general inertia and because to deter large amounts of spam, proof-of-work would [deter legitimate users](http://www.cl.cam.ac.uk/~rnc1/proofwork.pdf) under some models; spam seems to have been kept in check by better filtering techniques (eg. [Paul Graham](!Wikipedia "Paul Graham (computer programmer)")'s ["A Plan for Spam"](http://www.paulgraham.com/spam.html) using [Bayesian spam filtering](!Wikipedia)) and [legal action](!Wikipedia "CAN-SPAM Act of 2003") against botnets & spammers.]. Why did Bitcoin take a decade to be born? The problem nags at me - similar to the historical question of why England experienced the Industrial Revolution and grew to empire, and not China, which seems better equipped in every respect[^china]. There must be an answer.

[^china]: For more on that history, see Wikipedia on [Industrial Revolution#Causes for occurrence in Europe](!Wikipedia), [Chinese_industrialization#Reasons_for_the_delay_in_industrialization](!Wikipedia), the [Great Divergence](!Wikipedia); I strongly recommend [Gregory Clark's](!Wikipedia "Gregory Clark (economist)") _A Farewell to Alms_.

[^laurie]: I am only a layman with an interest in cryptography, but I am not alone in seeing this lack of really novel primitives or ideas in the Bitcoin scheme; Ben Laurie expresses exactly this idea in an aside in [a blog post](http://www.links.org/?p=1164) attacking Bitcoin:

> "A friend alerted to me to a sudden wave of excitement about Bitcoin. I have to ask: why? What has changed in the last 10 years to make this work when it didn't in, say, 1999, when many other related systems (including one of my own) were causing similar excitement? Or in the 20 years since the wave before that, in 1990? As far as I can see, nothing."

## Impractical?

Is the problem one of resources? In the whitepaper, Satoshi remarks:

> A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.

That's fine to say in 2008, after many doublings. Would memory be a problem in the 1990s? It doesn't have to be. The difficulty of bitcoin mining is obviously adjustable, so the problem boils down to:

1. disk usage

- With a smaller hash like SHA1^[SHA-1, as of 2011, has not been cracked [in practice](!Wikipedia "SHA1#SHA-1").], the 80 bytes can be shrunk

- 10 minutes is not graven in stone; why not 20 minutes? Right there we have halved the hash tree

- the hash tree can be 'garbage collected' and shrunk^[My understanding is that simply no one has bothered to program this functionality since 400MB is not that much space.]

- it is only necessary to maintain a full hash tree if one is paranoid.

In practice, like many programs of the era such as mail or Usenet clients, the default could simply be to hold onto the last _n_ blocks/hashes (Satoshi estimates [12kb/day](http://www.mail-archive.com/cryptography@metzdowd.com/msg09964.html)); this would consume a limited amount of disk space.

2. network connectivity is solvable by solutions to #1

1. A function of the existing hash tree size

2. And frequency of new transactions

It's worth pointing out that it's generally expected that at some point ordinary desktop users like you or me are expected to stop being full-fledged nodes and bitcoin miners and will instead make use of some specialist service running powerful servers of its own; in a counterfactual universe where Bitcoin was begun in the early 1990s, the changeover would simply have occurred sooner. (And with all the investment money desperately investing in the first Internet bubble, it would be quite easy to start such a service regardless of the technical demands.)

# Contemporary objections

As well, few of the objections to cryptocurrencies seem to have been "computers which can run it are fantastically expensive"^[Or rather, the objections were that cryptocurrencies had to be mobile - usable on the contemporary PDAs and cellphones, with the computing power of a watch.]. In computing, applications and techniques are often invented many decades before Moore's law makes them practically useful^[[Garbage collection](!Wikipedia "Garbage collection (computer science)") and most of artificial intelligence (or machine learning in particular) seem to have waited decades for sufficiently fast hardware. Indeed, I sometimes feel that [Alan Kay](!Wikipedia)'s entire career has essentially been sketching out what he could do if only he had some decent cheap hardware.], but this does *not* seem to have happened with Bitcoin. A similar objection obtains with patents or published papers; if Bitcoin was a known idea, where are they? I have yet to see anybody point out what patents might have deterred cryptography researchers & implementers; the obvious answer is that there were none. Because there was no investor interest? Not that Satoshi needed investors, but there were a tremendous number of online payment services started in the '90s, each searching for the secret sauce that would let them win 'mindshare' and ride 'network effects' to victory; [DigiCash](!Wikipedia) again comes to mind.

So if the basic idea is accessible, and it's useful on consumer-grade hardware for the last 20 years or so, then what's the problem?

## Cryptographers' objections

I think it's instructive to look at Satoshi's [ANN thread](http://www.mail-archive.com/cryptography@metzdowd.com/msg09959.html) on the Cryptography newsgroup/mailing list; particularly the various early criticisms:

- [disk/bandwidth won't scale](http://www.mail-archive.com/cryptography@metzdowd.com/msg09963.html)^[It probably will. [Some](https://en.bitcoin.it/wiki/Scalability) [informal](http://www.reddit.com/r/Anarchism/comments/hdf2t/so_i_guess_bitcoin_is_probably_a_mutualists_wet/c1ulirk) projections have been made of what it would take to run millions of transactions worth trillions of dollars, and they tend to come in at comparable to the existing resource use of companies like Google (which [fund](http://articles.economictimes.indiatimes.com/2011-04-12/news/29410039_1_energy-projects-solar-energy-clean-energy) [their](http://www.fastcompany.com/1748331/google-sinks-100-million-into-worlds-largest-wind-project) own power plants or monopolize convenient [hydroelectric](http://www.itmanagement.com/features/columbia-river-security-risk-062507/) [dams](http://www.nytimes.com/2006/06/14/technology/14search.html) to run their datacenters).]

- [proposal is underspecified](http://www.mail-archive.com/cryptography@metzdowd.com/msg09975.html) (omitting all the possible [race conditions](!Wikipedia) and [desynchronization attacks](http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html) and scenarios in a distributed system) and details [available only in ad hoc code](http://www.mail-archive.com/cryptography@metzdowd.com/msg09996.html)[^messy]

- it is [very difficult](http://www.mail-archive.com/cryptography@metzdowd.com/msg09995.html) to achieve [consensus](!Wikipedia "Consensus (computer science)") on large amounts of distributed data even without incentives to corrupt it or attacks

- [domination of the hash tree](http://www.mail-archive.com/cryptography@metzdowd.com/msg10005.html) by fast nodes and starvation of transactions

[^messy]: Recent criticism, too, sometimes focuses on the [quality](http://www.reddit.com/r/Anarchism/comments/hdf2t/so_i_guess_bitcoin_is_probably_a_mutualists_wet/c1uobdl) of the C++ codebase and _ad hoc_ nature of many of the choices; from an [anonymous Facebook comment](https://gist.github.com/1005927/4836d6231566bebd766966c7689c4094c1296700):

> "The protocol is not well-defined and clearly designed by an amateur (that is, not someone who has done much protocol implementation work). It's a binary protocol with a smattering of length-prefixing, [null terminated strings](!Wikipedia), etc. The messages look reasonable, just a horrible encoding. The rules of the protocol are poorly defined and tightly coupled to implementation; the implementation is done by someone who feels it's good and well to have only 5 major source files for 17 [KLOC](!Wikipedia "Source lines of code"). Due to lack of a well-specified protocol, there is also a bit of client monoculture going on.

>

> It's worth noting that the whole system assumes SHA-256 -- the bitcoin community says that rolling over to something else is just a matter of introducing a new algo, but in actuality it's not nearly that simple. The protocol has no concept of upgrading to different algos, so it would necessitate a complete overhaul of the protocol (since there's a lot of 32-byte fields in there) AND a re-computation/rollover of the entire transaction history.

> ...The protocol also has had no thought put into it re: network architecture -- there are peers and that's it. Due to the cryptographic nature of transactions, it's simply not possible to have realtime transactions with bitcoin as the network scales (it already take 5-10 mins on average for the network to see a single transaction). Thus, there will need to be some concept of a node in the network that can facilitate interactions between two peers in a faster fashion, with the assumption of a measure of trust. You shouldn't *require* it, of course, but it should be defined, I think."

Security expert [Dan Kaminsky](!Wikipedia) is similarly appalled at the bandwidth requirements to scale (":0" was his emoticon) and predicts that the Bitcoin network will eventually turn into a quasi-bank-like oligarchy of supernodes (which changes the system and "offers a host of ugly semantics" since the supernodes "don't need 50% -- just need to inconvenience 50% to accept your opinion"). He [comments](http://www.slideshare.net/dakami/bitcoin-8776098) that while "Normal Code" seems good but "Scratch the surface, it's actually really bad", the Bitcoin codebase "Looks really bad up front" and "Scratch the surface, it's actually surprisingly good". _[New Yorker](!Wikipedia)_ article's ["The Crypto-currency: Bitcoin and its mysterious inventor"](http://cryptome.org/0005/bitcoin-who.pdf):

> "'When I first looked at the code, I was sure I was going to be able to break it', Kaminsky said, noting that the programming style was dense and inscrutable. 'The way the whole thing was formatted was insane. Only the most paranoid, painstaking coder in the world could avoid making mistakes.'...He quickly identified nine ways to compromise the system...when he found the right spot, there was a message waiting for him. 'Attack Removed', it said. The same thing happened over and over, infuriating Kaminsky. 'I came up with beautiful bugs', he said. 'But every time I went after the code there was a line that addressed the problem.'...'I've never seen anything like it', Kaminsky said, still in awe...'Either there's a team of people who worked on this', Kaminsky said, 'or this guy is a genius.'"

On a technical basis, he dislikes the use of SHA-256 as opposed to slower [time-lock crypto](Self-decrypting files) functions like [bcrypt](!Wikipedia), because SHA-256 "can be accelerated massively with GPUs" leading to GPU shortages and massive hashing disparities between peers, and his slides conclude "BitCoin is actually well designed, if you accept that anonymity and scaling forces the entire present model to be shifted into something that effectively looks like banking"

[^szabo]: Nick Szabo, discussing [Chaumian ecash](http://web.archive.org/web/20110724123419/http://szabo.best.vwh.net/bearer_contracts.html) ("the greatest simple equation since $e=mc^2$"), comments with almost palpable distaste of a hypothetical system akin to Bitcoin in this respect:

> "A use-once-address communications mix plus forswearing any reputation gain from keeping accounts, in theory also buys us unlinkability, but a communications mix [BTC: ["mixing service"](https://en.bitcoin.it/wiki/Mixing_service); not necessarily [easy](http://andrewbadr.com/log/11/anonymizing-bitcoin/)] is weak and very expensive."

The most widely known, popular, and secure communications mix is probably [Tor](!Wikipedia "Tor (anonymity network)#Weaknesses"); a number of flaws have been [found in it](http://freehaven.net/anonbib/topic.html) over time, and Tor will never be very secure - it's fundamentally difficult to impossible to have a anonymizing communications mix which is also near real-time. Some flaws *can't* be removed by the Tor network, like the ability of exit nodes to snoop on traffic (as has been done many times, most memorably during the startup of [Wikileaks](!Wikipedia)). Communications mixes are usually expensive in resources, so typically only make up a part of an overall network - and the rest of the network leaks considerable information, including [in Bitcoin](http://arxiv.org/abs/1107.4524).

As well, let's toss in some recent blog posts on Bitcoin by the cryptographer [Ben Laurie](!Wikipedia) and Victor Grischchenko; Laurie particularly criticizes[^Laurie] the hash-contest which guarantees heavy resource consumption:

1. ["Bitcoin"](http://www.links.org/?p=1164)

2. ["Bitcoin 2"](http://www.links.org/?p=1171)

3. ["Bitcoin is Slow Motion"](http://www.links.org/?p=1175)

3. ["Decentralised Currencies Are Probably Impossible: But Let’s At Least Make Them Efficient"](http://www.links.org/files/decentralised-currencies.pdf)

> "I think people have missed the more subtle point that Ben Laurie made here. Bitcoin requires the use of an unusual sort of secure consensus protocol to work reliably, and such protocols are not known to exist in this context. In the presence of such a protocol, however, there is no longer any need for mining -- the system can simply elect a member to acquire a new coin every _N_ seconds via a secure election protocol (and those are known given the rest). Thus, Ben's point that if you're going to have a system like bitcoin, one could at least have an efficient system of this sort rather than a stupid one based on an electrical potlatch."

What's the common thread? Is there any particular fatal flaw of Bitcoin that explains why no one but Satoshi came up with it?

### Aesthetics

No! What's wrong with Bitcoin is that it's *ugly*. It is not [elegant](!Wikipedia "Mathematical beauty")[^beauty]. It's clever to define your bitcoin balance as whatever hash tree is longer, has won more races to find a new block, but it's *ugly* to make your network's security depend solely on having more brute-force computing power [than your opponents](http://www.mail-archive.com/cryptography@metzdowd.com/msg09966.html), *ugly* to need now and in perpetuity at least half the processing power just to avoid double-spending[^Laurie-2]. It's clever to have a P2P network distributing updated blocks which can be cheaply & independently checked, but there are tons of ugly edge cases which Satoshi has not proven (in the sense that most cryptosystems have security proofs) to be safe and he himself says that what happens will be a 'coin flip' at some points. It's ugly to have a hash tree that [just keeps growing](http://www.mail-archive.com/cryptography@metzdowd.com/msg09963.html) and is going to be gigabytes and gigabytes in not terribly many years. It's ugly to have a system which can't be used offline without proxies and workarounds, unlike Chaum's [elegant](!Wikipedia "ecash") solution[^may]. It's ugly to have a system that has to track all transactions, publicly; even if one can use bitcoins anonymously [with effort](https://en.bitcoin.it/wiki/Anonymity), that doesn't count for much - a cryptographer has learned from incidents like [anon.penet.fi](!Wikipedia "Penet remailer") and decades of successful attacks on pseudonymity^[For example, see some of the most recent research I linked in [_Death Note_: L, Anonymity & Eluding Entropy](Death Note Anonymity#de-anonymization).]. And what's with that arbitrary looking 21 million bitcoin limit? Couldn't it have been a rounder number or at least a power of 2? (Not that the bitcoin mining is much better, as it's a massive give-away to early adopters. [Coase's theorem](!Wikipedia) may say it doesn't matter how bitcoins are allocated in the long run, but such a blatant bribe to early adopters rubs against the grain. Again, ugly and inelegant.) Bitcoins can simply disappear if you send them to an invalid address. And so on.

> '"It's like the Mona Lisa." said Bruce Wagner, an IT consultant who discovered bitcoin in October and now hosts an online TV show about it. "It's a masterpiece of technology."'

[^may]: Chaum pays a price for his systems' ability to work offline. Don't take my word for it; see [Tim May](!Wikipedia) in [section 12.6.6](http://koeln.ccc.de/archiv/cyphernomicon/chapter12/12.6.html) of his early '90s _[Cyphernomicon](!Wikipedia)_ (not to be confused with [Stephenson's](!Wikipedia "Neal Stephenson") [novel](!Wikipedia "Cryptonomicon") drawing heavily on it):

> "...Chaum went to great lengths to develop system which preserve anonymity for single-spending instances, but which break anonymity and thus reveal identity for double-spending instances. I'm not sure what market forces caused him to think about this as being so important, but it creates many headaches. Besides being clumsy, it require physical ID, it invokes a legal system to try to collect from "double spenders", and it admits the extremely serious breach of privacy by enabling stings. For example, Alice pays Bob a unit of money, then quickly Alice spends that money before Bob can...Bob is then revealed as a "double spender," and his identity revealed to whomever wanted it...Alice, IRS, Gestapo, etc. A very broken idea. Acceptable mainly for small transactions.

>

> - Multi-spending vs. on-line clearing

>

> - I favor on-line clearing. Simply put: the first spending is the only spending. The guy who gets to the train locker where the cash is stored is the guy who gets it. This ensure that the burden of maintaining the secret is on the secret holder.

> - When Alice and Bob transfer money, Alice makes the transfer, Bob confirms it as valid (or verifies that his bank has received the deposit), and the transaction is complete.

> - With network speeds increasing dramatically, on-line clearing should be feasible for most transactions. Off-line systems may of course be useful, especially for small transactions, the ones now handled with coins and small bills."

[^Laurie-2]: ["Decentralised Currencies Are Probably Impossible: But Let’s At Least Make Them Efficient"](http://www.links.org/files/decentralised-currencies.pdf), Ben Laurie:

> "Now that we understand the core problem, namely that of agreement, we can quite easily understand Bitcoin’s solution to the problem. Bitcoin defines the consensus group as “all the computing power in existence”, and requires participants to prove their possession of whatever fraction of this power they care to spend on Bitcoin by using it to produce proof-of-work tokens. And once we state the problem like this, we can quite clearly see the flaw. Until at least half of the computing power in existence is actually used to produce Bitcoins, we cannot know that we have consensus! If, for example, 1% of the total power available^Strictly,\ I\ mean\ energy\ rather\ than\ power,\ since\ Bitcoin\ actually,\ in\ effect,\ sums\ power\ over\ time.^ is used to produce Bitcoins at present (in fact, the amount is far less than that), then at any point someone could come along with a further 1.1% of the total power and use this to define their own consensus^By\ forking\ history\ right\ back\ to\ the\ first\ block,\ and\ producing\ a\ hash\ chain\ that\ is\ longer\ than\ the\ current\ consensus.^, thus invalidating all the work, *and all the money*, of the initial group, and instead take possession of the entire currency for themselves.

>

> ...Even worse, it is clear that arriving at the equilibrium state for Bitcoin is incredibly expensive: half of all the computing power in existence must be burnt, in perpetuity, maintaining agreement about the current state of the currency. It also unknowable: we can never be sure that we actually are burning half of all the power in existence, because we do not know how much power exists."

Laurie points out that in practice, the Bitcoin community does *depend* on a centralized authority which periodically passes down 'blessed' block-chains - the Bitcoin developers periodically hardwire known-good states of the block-chain into the clients (which of course is a theoretical weakness).

### How Worse is Better

In short, Bitcoin is a perfect example of [Worse is Better](!Wikipedia) ([original essay](http://www.dreamsongs.com/WorseIsBetter.html)). You can see the tradeoffs that Richard P. Gabriel enumerates: Bitcoin has many edge cases; it lacks many properties one would desire for a cryptocurrency; the whitepaper is badly underspecified; much of the behavior is socially determined by what the miners and clients collectively agree to accept, not by the protocol; etc.

But it *seems to work*. Just like Unix, there were countless ways to destroy your data or crash the system, which didn't exist on more 'proper' OSs like [OpenVMS](!Wikipedia), and there were countless lacking features compared to systems like [ITS](!Wikipedia "Incompatible Timesharing System") or the [Lisp machine](!Wikipedia) OSs. But like the proverbial cockroaches, Unix spread, networked, survived - and the rest did not.[^preface]

[^preface]: _[The UNIX-HATERS Handbook](!Wikipedia)_, which contains many entertaining and often still-applicable descriptions of the fecklessness and sharp edges of Unixes, also contains an extremely funny 'Anti-Foreword' by Dennis Ritchie:

> "To the contributors to this book: I have succumbed to the temptation you offered in your preface: I *do* write you off as envious malcontents and romantic keepers of memories. The systems you remember so fondly ([TOPS-20](!Wikipedia), [ITS](!Wikipedia "Incompatible Timesharing System"), [Multics](!Wikipedia), [Lisp Machine](!Wikipedia), [Cedar/Mesa](!Wikipedia "Mesa (programming language)"), the Dorado) are not just out to pasture, they are fertilizing it from below...You claim to seek progress, but you succeed mainly in whining. Here is my metaphor: your book is a pudding stuffed with apposite observations, many well-conceived. Like excrement, it contains enough undigested nuggets of nutrition to sustain life for some. But it is not a tasty pie: it reeks too much of contempt and of envy. Bon appetit!"

A cryptographer would have difficulty coming up with Bitcoin because it is so ugly and there are so many elegant features he wants in it. Programmers and mathematicians often speak of 'taste', and how they lead one to better solutions. A cryptographer's taste is for cryptosystems optimized for efficiency and theorems; it is not for systems optimized for virulence, for their sociological appeal[^Ponzi]. Centralized systems are natural solutions because they are easy, like the integers are easy; but like the integers are but a vanishingly small subset of the reals, so too are centralized systems a tiny subset of decentralized ones[^subset]. DigiCash and all the other cryptocurrency startups may have had many nifty features, may have been far more efficient, and all that jazz, but they died anyway. They had no communities, and their centralization meant that they fell with their corporate patrons. They had to win in their compressed timeframe or die out completely. But "that is not dead which can eternal lie".

[^Ponzi]: Many [anonymous commenters](http://www.links.org/?p=1171#comment-415465) point this out because it makes Bitcoin smell like some sort of [Ponzi scheme](!Wikipedia) or [multilevel marketing scheme](!Wikipedia):

> "Bitcoin, like the recent commercial phenomenon [Groupon](!Wikipedia), tends to turn people into marketers because they feel they have something to gain, however small it might be in the end; I think that partly accounts for its temporary success."

Or ["The Rise and Fall of Bitcoin"](http://www.wired.com/magazine/2011/11/mf_bitcoin/all/1), _Wired_:

> "Stefan Brands, a former ecash consultant and digital currency pioneer, calls bitcoin “clever” and is loath to bash it but believes it’s fundamentally structured like “a pyramid scheme” that rewards early adopters."

> "Lots of people are saying: "The deflation built into bitcoin was a terrible idea. People are getting rich." In fact, it was a brilliant idea. It brought in speculators (people that are buying/selling it as if in a game). It created a bubble. The bubble put it on the map. The bubble has attracted thousands of developers/participants. Think of how the [Netscape IPO](!Wikipedia) fueled the Web/Internet."

[^subset]: Decentralized systems are usually convertible into centralized systems easily, while the converse is not true. (Much like [parallel](!Wikipedia "Parallel computing") versus serial programming - to make a parallel program serial, just insert a lot of [blocking](!Wikipedia "Blocking (scheduling)").) For a simple example, consider cases where _n_=2: imagine a [BitTorrent](!Wikipedia) swarm (a decentralized system) with one seed and one leech. Or take [Distributed Revision Control Systems](!Wikipedia) like [Darcs](!Wikipedia) or [Git](!Wikipedia "Git (software)"); it's a commonplace to point out that if a group really wants a 'centralized' workflow, they can just designate one particular repository the 'master' canonical repository and continue onwards with the DVCS as a more capable replacement for [Apache Subversion](!Wikipedia) or [CVS](!Wikipedia "Concurrent Versions System").

<!--

### Objection: Bitcoin is not Worse, it's Better

Nick Szabo and Zooko Wilcox-O'Hearn disagree strongly with the thesis that 'Bitcoin is Worse is Better'. They contend while there may be bad parts to Bitcoin, there is a novel core idea which is actually very clever - the hash chain is a clever sidestep around classic problems of distributed computing, which gives us something similar enough to a trustworthy non-centralized2 authority that we can use it in practice.

> "Gwern's post fails to appreciate the technical advances that BitCoin originated. I have been trying, off and on, to invent a decentralized digital payment system for fifteen years (since I was at DigiCash). I wasn't sure that a practical system was even *possible*, until BitCoin was actually implemented and became as popular as it has. Scientific advances often seem obvious in retrospect, and so it is with BitCoin" http://themonetaryfuture.blogspot.com/2011/05/bitcoin-timing-is-everything.html?showComment=1306860158361#c6958602700376442348

Satoshi explains this in an [early email](http://www.mail-archive.com/cryptography@metzdowd.com/msg09997.html). The hash chain can be seen as a way to coordinate mutually untrusting nodes (or trusting nodes using untrusted communication links), and to solve the [Byzantine Generals' Problem](!Wikipedia). If they try to collaborate on some agreed transaction log which permits some transactions and forbids others (as attempted double-spends), naive solutions will fracture the network and lead to no consensus. So they adopt a new scheme in which the reality of transactions is whatever the group with the most computing power says it is! The transaction log does not aspire to record true reality or figure out who is a scammer or not, but like Wikipedia, simply mirrors one somewhat arbitrarily chosen group's consensus:

> "...It has been decided that anyone who feels like it will announce a time, and whatever time is heard first will be the official attack time. The problem is that the network is not instantaneous, and if two generals announce different attack times at close to the same time, some may hear one first and others hear the other first.

>

> They use a proof-of-work chain to solve the problem. Once each general receives whatever attack time he hears first, he sets his computer to solve an extremely difficult proof-of-work problem that includes the attack time in its hash. The proof-of-work is so difficult, it's expected to take 10 minutes of them all working at once before one of them finds a solution. Once one of the generals finds a proof-of-work, he broadcasts it to the network, and everyone changes their current proof-of-work computation to include that proof-of-work in the hash they're working on. If anyone was working on a different attack time, they switch to this one, because its proof-of-work chain is now longer.

>

> After two hours, one attack time should be hashed by a chain of 12 proofs-of-work. Every general, just by verifying the difficulty of the proof-of-work chain, can estimate how much parallel CPU power per hour was expended on it and see that it must have required the majority of the computers to produce that much proof-of-work in the allotted time. They had to all have seen it because the proof-of-work is proof that they worked on it. If the CPU power exhibited by the proof-of-work chain is sufficient to crack the password, they can safely attack at the agreed time.

>

> The proof-of-work chain is how all the synchronisation, distributed database and global view problems you've asked about are solved."

from the New Yorker article:

> Haber is a director of the International Association for Cryptologic research and knew all about bitcoin. "Whoever did this had a deep understanding of cryptography", Haber said when I called. "They've read the academic papers, they have a keen intelligence, and they're combining the concepts in a genuinely new way."

But slowly, word of bitcoin spread beyond the insular world of cryptography. It has won accolades from some of digital currency’s greatest minds. Wei Dai, inventor of b-money, calls it “very significant”; Nick Szabo, who created bit gold, hails bitcoin as “a great contribution to the world”; and Hal Finney, the eminent cryptographer behind RPOW, says it’s “potentially world-changing.”...Stefan Brands, a former ecash consultant and digital currency pioneer, calls bitcoin “clever”...

-->

It may be that Bitcoin's greatest virtue is not its deflation, nor its microtransactions, but its viral distributed nature; it can wait for its opportunity. "If you sit by the bank of the river long enough, you can watch the bodies of your enemies float by."