(Apologies if there are historical errors in my recounting of the Gnutella story)
"If Gnutella Had A Protocol Specification, Why Can't Bitcoin?"Gnutella was a peer to peer file sharing program written by Justin Frankel from Nullsoft and released in 2000 as an executable with accompanying source code. There was no documentation or written specification other than the source code and comments contained inside. Gnutella immediately became popular, and the company Clip2 was formed whose first opus was to write a quick protocol specification based on an analysis of the code:
Gnutella Protocol Specification v0.4Gnutella's popularity immediately spawned a number of clones. These clones offered various features but all interoperated together on the same peer to peer network. Commercial entities like BearShare and LimeWire were formed to produce their own Gnutella clients and build new features. As more companies appeared, it was in everyone's interests to have an up to date specification so that clients from different vendors could be compatible. Volunteers worked with the commercial and open source Gnutella client providers to write the next iteration of the Gnutella protocol:
Gnutella Protocol Specification v0.6Nodes identified their vendor origin and Gnutella protocol version number on the initial handshake. Using this information, newer implementations would accomodate older implementations by behaving appropriately as per the different versions of the protocol specification. To distinguish their products, vendors would add features that were only enabled when both hosts were from the same vendor. This allowed vendors to improve their implementations while maintaining compatibility with other nodes.
Thanks to the availability of language-agnostic protocol specifications, academic research into Gnutella was made easy. Many papers were written analyzing the Gnutella protocol and suggesting improvements:
Improving Gnutella Protocol: Protocol Analysis and Research ProposalsThe largest entities developing Gnutella clients worked together in a vendor-neutral message board to discuss improvements to the protocol. In many ways this is similar to the Bitcoin development mailing list except that representatives of more than one client implementation were present instead of just one:
The Gnutella Developers ForumThe technical merits and details of each improvement were discussed until a consensus was reached. Documentation was written, and test code developed. After some iterations and refinement, the official version of the proposal was submitted and became part of the growing official protocol. Here's an example of the “ultrapeer” proposal from LimeWire, which re-structured the overlay network to make better use of bandwidth:
Ultrapeers: Another Step Towards Gnutella ScalabilityNo single vendor or programmer had control over the Gnutella specification. Changes to interoperability was always done through cooperation, discussion, and consensus. Vendors who wanted to create their own variations of these proposals were free to to so when two of their own nodes were talking to each other. But when talking to nodes from other vendors they could follow the official specification. The flood-fill nature of queries created bandwidth problems, and scaling issues were always at the forefront. In many ways, Gnutella faced the exact same problems that Bitcoin is facing. Bloom Filters were proposed for Gnutella, a specification hammered out and a document produced:
Query Routing for the Gnutella NetworkAlthough LimeWire, LLC was a commercial entity, they had a strong desire to see Gnutella succeed as an open protocol and to this end they contributed resources and efforts to define the specification so that anyone could write their own implementation and interoperate on the Gnutella network. At the peak of Gnutella's adoption, there were many vendors and many different implementations. They all worked together on the same peer to peer network. A “monoculture” did not exist – Gnutella implementations were written in a variety of languages but they all had the Gnutella protocol specification to work from.
Bitcoin has many features in common with Gnutella, both technical and social. It uses a peer to peer overlay network. The reference implementation is open source. They both have the “commons”: shared bandwidth, storage, and computing resources. Unfortunately, the development process for these two software systems is completely different. Unlike Gnutella, Bitcoin has only one real reference implementation. The build process for this implementation is difficult and cumbersome, requiring a hodge-podge of separate dependencies to get built. There is no protocol specification for Bitcoin, and the developers have not expressed any interest in creating one. They make changes to the “wire protocol” (messages exchanged between peers) which would ordinarily break other vendors' implementations. But since there are no other vendors, there is little incentive to stop. The Bitcoin Foundation is nothing like the Gnutella Developers Forum and lacks the benevolence of the LimeWire employees. There is no altruistic vision, just a group of corporate individuals with partially overlapping financial interests.
Bitcoin would greatly benefit from having multiple robust node implementations, but this is hamstrung because there is no formal protocol specification, and developers feel free to make breaking changes on their whims. Every web standard has a specification. It has often been stated that "Bitcoin is different" because it transmits money. Doesn't that make the case for an official specification even stronger?
When I compare the development of Gnutella to the development of Bitcoin, the contrast is extreme. Whereas Gnutella had dedicated individuals who set the bar high, Bitcoin developers often make excuses:
the only precise enough specification...is the source code. Which means if you can't read C++ fluently you can't reimplement Bitcoin, yes, but who cares? If you can't keep up, don't step up.
Are we to believe that the programmers who hold the blockchain in their very hands are not capable of producing a document with a concise, language-agnostic description of a particular aspect of the Bitcoin protocol? Shouldn't we hold commits to the official repository to a higher standard than "just read the code?"
How can we expect any serious corporate or institutional involvement in Bitcoin if the developers' attitude is "If you can't keep up, don't step up?"...because some parts of the protocol are directly exposed to underlying libraries like OpenSSL, you have to match their behaviour exactly as well, including all their bugs. Failure to do so can lead to people losing money.
Then Bitcoin developers need to stop adding new features and document all of these obscurities fully. There are a finite number of them, and they can be enumerated. In the words of Mike Hearn, “If you can't keep up, don't step up.” If you can't document all the idiosyncrasies of every external dependency, the don't be adding new features. In fact, don't make any commits at all and leave it to someone more capable.
The argument that Bitcoin is “too complicated” or “too important” to have a fully documented specification and formal process for making “wire breaking changes” is shown to be false by the success of Gnutella. Multiple vendors, producing separate client implementations in different programming languages, working together on protocol improvements and adhering to a formal written specification agreed upon by all.
Why can't we have the same thing for Bitcoin? As users we must demand that Bitcoin development is held to a higher standard. The Bitcoin Foundation isn't interested in doing it, so we need to step up.
