The Decentralized Internet

Before a computer could join a global search for extraterrestrial intelligence, exchange pieces of a file with strangers, or participate in a monetary network, engineers had to overcome a simpler obstacle: computers were difficult to connect.

Early computer networks often belonged to particular universities, laboratories, or government programs. They relied on specialized equipment and assumptions about their users. Building another network did not automatically expand the first. It might simply create another island.

During the 1960s, researchers questioned whether communication had to depend on reserving a continuous circuit. At RAND, Paul Baran studied survivable communication systems; in Britain, Donald Davies developed packet-switching work; American research on interactive computing and resource sharing helped produce ARPANET. These were overlapping but distinct histories. The popular claim that the internet was designed simply to survive nuclear attack folds different projects into one convenient origin myth.

Packet switching offered a flexible alternative. Information could be broken into smaller units, carried through shared infrastructure, and reconstructed at its destination. Multiple users no longer had to behave as though each conversation owned a dedicated line.

That achievement created a new question. What if two networks used different machinery, addressing systems, and rules? A packet that crossed one network still needed a way into the next.

The solution would not be one enormous centrally managed computer system. It would be a set of agreements allowing independently built networks to interoperate. That distinction—cooperation without identical ownership—became one foundation for everything that followed.

Well before ordinary households browsed the Web, connected computers were exchanging conversations. Usenet grew from experiments in moving messages among Unix systems around 1979–1980. Different sites could exchange discussion material using mechanisms such as UUCP. The resulting community was not hosted in one universal conversation database controlled by a single company.

Yet local administrators retained power. A site decided which groups to carry, whom to serve, and which machines could connect. Messages moved through cooperation among institutions, not through the abolition of institutions.

Internet Relay Chat made another kind of distributed community visible. Developed by Jarkko Oikarinen in 1988, IRC connected users through servers that relayed conversations. Its 1993 protocol specification described server networks, channels, and special operator roles. People could encounter a sprawling conversational world without having to share a single central machine; the system still had its operators, topology, and points of failure.

The World Wide Web provided another essential contrast. CERN's 1993 decision to release key Web software freely helped make publishing through open protocols widely available. Anyone able to operate a server could potentially become a publisher. But an open Web page was not the same thing as a file automatically replicated among all its readers. The familiar browser-server relationship remained fundamental.

These systems showed that communities and publishers could participate beyond the boundaries of any one enterprise. They also taught a lesson that would recur for decades: technical openness and distributed operation do not necessarily remove concentrated authority.

The next leap was more tangible. Ordinary machines would stop being merely places where people read messages. Their unused processing power would become part of a shared resource.

Around the same period, volunteer cryptographic key-search efforts demonstrated a related possibility. Machines run by enthusiasts could test different portions of a very large search space. Each computer did a modest part; together, they could perform work beyond the practical reach of most individual participants.

The new resource was not a proprietary supercomputer. It was an agreement between an organizing project and a dispersed population of computer owners.

That distinction held a paradox. The computation could be widely distributed while the authority to assign work and certify the result remained concentrated. Participants usually did not need to find one another or negotiate a common answer. They needed the coordinator to give them something useful to do.

The model was powerful precisely because the work could be divided into many relatively independent pieces. But its success depended on the organizer's continued ability to define the problem and receive the answers.

Soon one scientific project would make this experience part of popular culture. Its volunteers would not be searching for prime numbers or breaking a test cipher. They would be looking toward the stars.

In March 1997, volunteers participating in a cryptographic key-search effort faced a problem that seemed to undermine their distributed achievement. The central coordinating keyserver disappeared.

The people performing the calculations were scattered across different computers. That was the point of the project. But if the system coordinating their assignments became unavailable, what work should they perform next—and where should they report it?

The group that became distributed.net reorganized. Its historical records describe volunteers coordinating through IRC, the creation of proxy infrastructure, and a public proxy network announced on March 24. The organization could preserve the collective effort because its participants had the technical knowledge and willingness to rebuild the coordinating arrangements.

There are two stories here. One is about the resilience of a community: the disappearance of a machine did not end the project. The other is about the limits of its architecture: replacing the keyserver did not remove the need to allocate work and count legitimate results.

In October 1997 the project completed its RC5-56 challenge, a notable demonstration of volunteer computing. Its participants had taken small pieces of work and, through persistence and coordination, produced a result no one participant could reasonably have pursued in the same way.

This was not a failed experiment in decentralization. It was an important success in distributed computation—alongside a vivid reminder that distributing labor and distributing authority are different achievements.

There was another connection hiding in the 1997 story. IRC, built for online conversation, had served as a means for volunteers to coordinate recovery. Years later, early Bitcoin software would also use IRC, this time as an aid to locating other nodes. The shared infrastructure is documented; a common design ancestry for their core algorithms is not.

The raw information came through an arrangement involving the Arecibo telescope in Puerto Rico. In a detail that captures the era, data were recorded on physical tapes and transported to Berkeley because sending the full data stream over Arecibo's available internet connection was impractical. At Berkeley, the data were broken into work units for volunteer machines.

The project was immediately recognizable in a way earlier distributed-computing experiments rarely were. A participant did not need expertise in number theory or cryptanalysis. Curiosity about the universe was enough. The screensaver made a normally invisible contribution visible. Teams formed. People compared their computing totals. Ordinary personal computers became part of a scientific project far larger than their owners.

In their November 2002 technical account, the Berkeley researchers reported millions of participants and a level of computing activity that would have been extraordinary for a single conventional institution to assemble from personally owned machines. They also documented the operational details behind the wonder: servers, data distribution, software maintenance, result verification, and the constant challenge of managing a vast population of computers outside the project's control.

The cultural importance is inseparable from the architecture. SETI@home let ordinary people experience the power of distributed participation. Their machines were no longer merely using the internet. They were supplying productive work to something that existed because so many people joined.

But the power had a boundary. The volunteer computers did not independently decide which telescope data to analyze or whose findings counted. Berkeley defined the work and assessed the returns. Its global supercomputer was distributed in labor, not in final authority.

That distinction would become one of the key lessons this Current carries forward.

The more computers SETI@home recruited, the less the project could assume about any individual machine. Volunteers had different hardware, different software environments, and different reasons for joining. Some computers produced errors. Some users attempted to manipulate the system's credits.

The Berkeley project could not simply accept every returned calculation as accurate. It assigned some work redundantly and compared results. Behind a friendly screensaver lay the less glamorous problem of deciding which submissions deserved trust.

The project also learned that volunteers did not contribute only for the scientific mission. People wanted to see what they had accomplished. They compared credits, competed in teams, and took pride in the work their machines completed. This was a system of incentives, even without payments or transferable money.

These pressures helped inform the Berkeley Open Infrastructure for Network Computing, BOINC. A BOINC-based SETI@home client became publicly available in June 2004. Instead of treating volunteer computing as software belonging to one experiment, BOINC provided infrastructure that other scientific projects could adopt. Participants could divide resources among projects with distinct research objectives.

The arrangement expanded opportunity without eliminating project administrators. Scientists still defined their tasks; the infrastructure still needed mechanisms to account for work and detect unreliable results.

Its importance becomes clearer when placed beside Bitcoin's later design. SETI@home could ask Berkeley to judge the result. Bitcoin could not require a Berkeley-like authority to declare which monetary transfers were valid without abandoning its stated goal.

That difference should not obscure the achievement. By the early 2000s, volunteer computing had demonstrated that independent machine owners would donate extraordinary resources for goals they cared about—and that those contributions demanded real engineering attention to validation, incentives, and abuse.

The next generation of networks would put another resource into the hands of participants. Instead of sending their idle processor time to a research institution, they would exchange information directly with one another.

If Napster made locating files easy by consulting a company-controlled directory, Gnutella asked what a search would look like without that directory.

Its early protocol allowed connected computers to forward search requests among peers. A participant could ask nearby nodes, which could pass the request onward. The network's knowledge was no longer concentrated in one catalog. Each machine's connections became part of the mechanism by which queries spread.

The design was elegant in one sense and expensive in another. Requests could travel through many machines, consuming bandwidth and processing time even when most recipients had nothing useful to offer. As a network expanded, asking an ever larger population the same question became increasingly inefficient.

Gnutella also required a way to get started. A new user still needed an address of at least one existing participant. Early protocol documentation placed initial host discovery outside the core message protocol. A network with no central search index could still depend on a directory, host cache, or social channel merely to join.

Later adaptations attempted to improve performance, including more capable peers and revised network topologies. Those arrangements were not evidence that the original ambition had been pointless. They were responses to the practical consequences of scale.

The lesson was sharper than the slogan of removing middlemen: eliminating a central directory transfers the work of discovery somewhere else. Somebody—or some protocol—still has to find the information.

This realization opened the door to a major research question of the early 2000s: could peer discovery become efficient enough for large, changing networks without recreating a single indispensable index?

These ambitions created their own tensions. Routing through a changing network of machines could be inefficient. Availability and anonymity depended on technical conditions that were difficult to guarantee in every situation. A design intended to resist suppression was not automatically invulnerable to attacks, traffic analysis, or operational failure.

The historical contrast with Gnutella matters. Both departed from Napster-style central indexing, but they were not answering identical questions. Gnutella's early design concerned decentralized querying and sharing. Freenet treated the ability to suppress information as a first-order threat and tried to reshape storage and retrieval around that risk.

Other researchers pursued related problems from different directions. Berkeley's OceanStore proposal explored dependable storage across geographically dispersed and potentially untrusted machines. It emphasized persistence, replication, and cryptographic protections rather than promising an identical social mission to Freenet.

Together these projects enlarged the scope of distributed systems. The question was no longer only whether computers could exchange information directly. It was how information could remain accessible when its keepers were unreliable, untrusted, or under pressure.

For a monetary network, persistence and replication would also matter. But preserving many copies of data could not alone determine which of two conflicting claims to the same money should be accepted.

The appeal of eliminating a central directory was clear. The difficulty of doing so efficiently was just as clear. A network of thousands or millions of computers could not cheaply forward every request to every participant.

Research into distributed hash tables approached the issue differently. Rather than treating all participants as an undifferentiated crowd, these systems arranged a method for deciding which node should be responsible for a particular key and how another node could locate it.

Chord, presented in 2001, organized lookup using a structured relationship among node identifiers. Kademlia, published in 2002, used a different arrangement built around an XOR distance metric and procedures that could operate while nodes arrived, departed, or stopped responding.

A distributed hash table was not a magical global search engine. It could help find the node or peers associated with a known identifier. It did not, by itself, tell a user which movie to watch, whether a downloaded document was authentic, or who owned an asset. Those separate problems still required other mechanisms.

The ideas soon appeared in deployed applications. On January 8, 2004, eMule announced a Kad test client offering a Kademlia-based network as an alternative to its server connections. The announcement explicitly allowed users to choose servers, Kad, or both.

That detail captures the period's practical experimentation. Research into decentralized discovery did not immediately erase older architectures. Software could combine approaches while its developers and users learned which tradeoffs worked.

The deeper historical shift was that locating peers could increasingly become a responsibility shared by the network itself. But bootstrapping, authenticity, content discovery, and security still needed answers.

The first peer-to-peer experiments revealed that completely symmetrical designs could be costly. Some computers had better connections, stayed online longer, or were better positioned to help others. Why should every machine behave as though it had identical capabilities?

FastTrack, used by applications including Kazaa, employed a tiered network in which capable peers became supernodes responsible for additional coordination and search activity. eDonkey distributed directory responsibilities across independently operated servers. Direct Connect used hubs to help participants find one another while transfers could take place between clients.

These architectures were neither Napster clones nor systems free of dependencies. Each shifted the location of useful coordination. A hub was still important to the community relying on it. A supernode could improve search without necessarily becoming one corporation's master index.

Skype carried similar tensions into voice communication. Contemporary measurement research described a network of ordinary clients, supernodes, and centralized login infrastructure. Its hybrid approach helped a consumer service connect users in difficult network environments, including situations involving firewalls and address translation.

It would be a mistake to grade these systems by the purity of their decentralization alone. They were responding to actual users. People wanted reliable searches, conversations, and downloads—not an ideological demonstration that no machine could have a special role.

The resulting architectures teach a more durable lesson: engineering distributes responsibilities according to what a service needs. Some forms of hierarchy can improve usability and reliability. Others create targets whose failure, control, or removal can disrupt the system.

Bitcoin would face its own tradeoffs. But the existence of specialized roles in earlier networks cannot establish that Bitcoin copied them, and removing a server never guaranteed that influence or control vanished.

The volunteer-computing projects of the 1990s depended heavily on curiosity, public recognition, and personal commitment. Peer-to-peer sharing posed a sharper problem. If everyone wanted bandwidth and storage but few people supplied them, the system could become less useful as it grew.

Mojo Nation, publicly released in 2000, explored a more explicit answer. It proposed a distributed resource-sharing system in which participants could earn and spend units known as Mojo in connection with network contributions. Rather than assuming that generosity would always be enough, it attempted to make cooperation economically meaningful.

The experiment was historically important because it placed incentives inside the design of a P2P system rather than treating participant behavior as an afterthought. But ideas attractive on paper proved difficult in deployment. Bryce Wilcox-O'Hearn's 2002 account, Experiences Deploying a Large-Scale Emergent Network, described practical difficulties encountered after real users began operating the software.

Mojo Nation and BitTorrent approached resource contributions differently. One tried to organize rewards around a token-like unit; the other emphasized reciprocal exchange of bandwidth. Neither can be casually recast as an early version of Bitcoin's monetary consensus.

An incentive is only as meaningful as the result it rewards. A file-sharing network asks people to supply storage or bandwidth. A volunteer-science project asks them to complete calculations correctly. A monetary network must make the production and validation of a transaction history resistant to forms of dishonest behavior that directly threaten the system's core purpose.

By the early 2000s, distributed-systems designers understood that user incentives were part of the architecture. The harder question was whether incentives could secure agreement when participants had no common administrator and might deliberately disagree.

BitTorrent's peers could keep exchanging pieces of a file without requiring the original publisher to send every byte. Yet people still needed ways to discover which files existed and how to join the relevant swarms. Websites and indexes remained useful—and vulnerable.

The Pirate Bay became a famous example of the difference between a distribution protocol and the organizations built around it. Swedish police seized servers in May 2006. The website's subsequent return became part of its public reputation for resilience, although contemporary accounts indicate that early restoration was not complete in every function.

The distinction matters more than the legend. Taking a website offline could disrupt discovery and convenience. It did not switch off all BitTorrent clients or erase copies already exchanged among peers. Nor did the technical design shield site operators from investigation, litigation, or enforcement.

American litigation offered another warning about oversimplifying technical solutions. In 2001, the Ninth Circuit's Napster ruling examined centralized indexing and supervision. In 2005, the Supreme Court's MGM v. Grokster decision examined purposeful inducement of copyright infringement. Eliminating a particular technical directory did not eliminate every possible basis for legal liability.

The broader pattern was now plain. There were many different points of control: software distributors, search websites, connection services, server operators, hosting providers, domain registries, and people who governed the surrounding organizations. A protocol might continue functioning after one institution disappeared while particular users still lost an important way to find or access the network.

A decentralized architecture can reduce some kinds of dependence. It does not make human institutions irrelevant. More importantly for our conclusion, resilience of data exchange is not the same as consensus about a monetary ledger.

The internet of late 2008 was crowded with examples of independent machines cooperating. People had used their computers to search for prime numbers and extraterrestrial signals. They had exchanged files directly, shared bandwidth in swarms, and participated in networks that distributed search or storage among peers.

A new system still faced a basic operational question: how does a newly installed client find the other participants?

Early Bitcoin software provides a concrete answer. Its original implementation included IRC-based peer discovery. The software could make use of a familiar chat-network infrastructure to learn about reachable nodes. IRC had not been invented for money, mining, or consensus. It was an existing communications tool adapted to solve a practical networking problem.

This is a documented implementation connection, more specific than saying Bitcoin resembled older peer-to-peer networks. It also illustrates a limit. Bitcoin's original peer discovery did not make the IRC servers responsible for determining which Bitcoin transactions were valid. Discovery and monetary agreement were different jobs.

By that point the internet offered many methods for finding machines and exchanging data. The challenge that motivated Bitcoin was not how to send information from one computer to another. That problem had long been solved well enough for enormous networks to function.

The difficult question was what happened when participants received conflicting information about money. Two signed messages could appear to spend the same funds. Merely making more copies of both messages would not resolve the conflict.

The network needed rules for verifying transactions and determining which transaction history its nodes should accept. Unlike a volunteer-science project, it could not simply send the disagreement to a central laboratory without restoring the trusted intermediary it sought to avoid.

On October 31, 2008, Satoshi Nakamoto circulated a paper titled Bitcoin: A Peer-to-Peer Electronic Cash System. Its first pages described the problem with ordinary electronic payments: electronic transfers conventionally relied on financial institutions that could settle disputes and prevent the same funds from being spent twice.

Digital signatures could establish authorization. They could not, by themselves, establish which of two conflicting transfers was first or valid. A file can be copied indefinitely without causing a contradiction. A monetary unit cannot be validly spent twice simply because two computers received different messages.

The Bitcoin proposal combined public transaction verification with a proof-of-work chain that made the record of accepted transactions costly to rewrite. Nodes could verify information under common rules, and miners could compete to extend the chain. The system did not ask a single company to maintain the authoritative book of transfers.

This was not a claim that every participant was equally influential, or that physical infrastructure and human incentives ceased to matter. The proposal relied on explicit assumptions about honest computational power, network communication, and the rules nodes followed. Its security claims must be understood within those assumptions.

But the difference from earlier networks was decisive. SETI@home divided calculations and sent the results back to Berkeley. BitTorrent helped many peers obtain the same file. Gnutella and DHTs addressed discovery. Freenet and OceanStore examined ways to distribute or preserve information. Bitcoin was attempting to maintain an agreed monetary history when some participants might offer conflicting accounts.

The significance lay in the combination, not in an invented claim that every component was new. Cryptographic and digital-cash precedents belong in the companion Current, Cypherpunk Genesis. Here, the historical argument is about a network environment that made independent participation familiar—and a consensus problem that earlier resource-sharing systems had not been built to solve.

In February 2009, Satoshi described Bitcoin to the P2P Research mailing list as an open-source peer-to-peer currency without a central server or trusted parties. The correspondence placed a working monetary experiment before people who were already debating how independent machines might exchange resources and cooperate without conventional central services.

In replies to questions about trust and reputation, Satoshi emphasized cryptographic verification rather than reliance on the reputation of a network participant. That exchange documents a connection to the P2P research community. It does not prove that Satoshi borrowed a particular invention from Napster, Gnutella, Freenet, BitTorrent, or Mojo Nation.

The older history still matters. Packet-switched networks and common protocols made large-scale independent communication practical. Usenet and IRC showed communities distributed across cooperating servers. Volunteer computing made productive use of machines owned by strangers. SETI@home turned the idea into a mass public experience, while exposing the continuing need for coordination and correct results. Napster made the weakness of a central directory visible. Gnutella and DHTs explored alternatives. Freenet, OceanStore, and BitTorrent expanded what could be stored, found, and distributed. Hybrid systems showed that efficiency could lead designers to restore specialized roles. Legal pressure revealed that software architecture did not abolish institutions or accountability.

There was no straight road from those experiments to Bitcoin. The people involved pursued different goals, often at the same time, and their systems encountered different constraints. Some ideas survived; others were abandoned or substantially revised. Many were not designed to operate without any central authority at all.

What emerged from their combined history was a new practical understanding of the possible—and of the hard problems that remained. Independent machines could communicate, provide resources, exchange data, and survive some failures without one master computer performing every task. What they could not do merely by copying information was make conflicting monetary transactions equally valid.

Bitcoin entered that world with a particular answer. It proposed that independent participants could check transactions and converge on a proof-of-work-supported monetary record without appointing a trusted institution to keep the books.

The decentralized internet had not been building toward Bitcoin as an inevitable destination. But by the time Bitcoin appeared, decades of experimentation had made its network premise imaginable. Its distinct challenge was to turn a network of communicating participants into a network maintaining a shared history of value.