Topic: What Bitcoin Could Learn From Gnutella (or, why devs need a spanking) - page 4. (Read 9638 times)

I refuse to say anything negative about Gavin or any of the other bitcoin devs but the above is missing and it is a must.

The bitcoin protocol is Implementation defined, which means that no-one can go write a client in a language of their choice. It's the one official client or it won't work right.

Also add robust testing to the above list. But don't underestimate the complexity of a fit for purpose testing setup for complex software that has to work flawlessly under all situations and with many historic versions of clients.

Bitcoin certainly needs all these things, and for the reasons that you gave. But we should be realistic about what is possible and/or probable given the current environment. A good "first step" on the road to rigor would be a tightening up of the development process, realignment of priorities for what is worked on, and a commitment to improve the process.

You've made me want to eat custard creams now, curse you

The situation with gnutella is also laughable when compared to how any even halfway respectable financial company handles these kind of issues.

The first thing that is done in all the companies I have worked in always is a REQUIREMENT SPECIFICATION. Without that you do not know which features must be written into the protocol specification and jumping to define that is just going to lead into fail. In case of gnutella it does not matter much. Planning bitcoin to take over the world and last for centuries as the king of the hill is not going to succeed in an adhoc way of working. Talking about how the source code is the best protocol spec is about the most horrendous adhoc way of working possible. Anybody talking about that is seriously fooling themselves.

For example the issue of how much capacity the network should have to process transactions should be first specified in the requirement spec. Now nobody knows and nobody agrees about what the capacity should be and that means that any attempt to fix the issue is futile. It might be so that the needed capacity is 100x of what there is now or the needed capacity should be 10000x of current capacity. I don't know, nobody knows. What I do know that the current attempts to increase it by 2x or 4x or whatever are just a bandaid and adding a lot of bandaid, bubblegum and duct-tape into the system now could be later found to cause huge problems when the next step needs to be taken and somebody might need to work with the multiple versions with varying amount of ducttape in them.

One thing that I have seen done in all companies I have worked in is test specification. And an comprehensive set of implemented testcases should be available in some way so that everybody could have them and run them against any client they want to test and then for their part add to that set of implemented testcases.

Many companies trying to implement an system of this magnitude and complexity could decide to build first is a simulation of the thing at the network level. That could be done so that it could be run inside one computer when in the simulation model the CPU-expensive hashing is replaced with something else much less CPU intensive but still showing the main characteristics of the hashing that are visible at the network level. This model could be later upgraded to be closer and closer to the protocol spec but sill retaining the low CPU usage so that it could be practically run in a realistically available HW.

The tests defined in the test specification could be first tested running them against this simulator. Many other financial institutions have I guess multiple complete datacentres across the globe as redundancy and I guess they can take some of them offline in quiet periods to test a new version of their SW in real HW and to be able to run tests to them at loads that are close to real capacity of the network. Similar is not possible with bitcoin and it is a huge problem.

Bitcoin is lacking in testing in so many areas. The test spec, there is no real environment to test. There are no automated test generators that can read the protocol spec and create random tests without human intervention. This is one of the ways I believe major financial institutions handle the issue whether all cornercases are tested or not. The automated testvector generator that reads in the computer readable protocol spec can be guaranteed given enough time to test all the cornercases of the protocol-spec. Just let it run and run.

Multiple implementations of the client written before most of the previously talked about stuff is done however makes things just worse, not better.

Some people talk about how the current issue is solved by telling everybody complaining to go write some C++ to fix the issue. This attitude could not be more wrong. I understand that the proper specs are not maybe going to emerge in the near future. What however should really be done first before coding begins is some whitepapers addressing the questions how the current problems are going to be solved. At least two subjects have become quite clear are needed.

One whitepaper that goes through all the issues related to capacity how much it is going to be needed and how that goal is going to be reached. From this whitepaper then can be seen how much the increase of blocksize makes actual sense or not.

Another whitepaper should be dedicated on how to deal with all the issues related to spam, both friendly spam like SD and also hostile spam from someone wanting to bring bitcoin down whether they are some botnet, fiat-world-banking institution or black hand of some government.

After these whitepapers exist and hopefully multiple attempts at them they can be discussed and some action planed based on them.

I am optimistic that the capacity issue is solvable somehow. However I am not sure the spam issue is solvable at all. It might be that since spam can be made to be totally similar to real traffic, there is nothing that could be used to even detect spam and much less something that could be used to deal with it without massive sideeffects. I hope to be proven wrong with maybe when the whitepapers emerge.

That's what 0.8 followed but 0.7 didn't.

If there is no specification, what is this?

https://en.bitcoin.it/wiki/Protocol_specification

Agreed

Write a spec, get multiple implementations. Majority of them should be correct and those who disagree must be fixed. I believe it's the best long term strategy. It's really bad to base entire thing on one implementation in long run.

I'm all for having a spec that allows an ecosystem of multiple compatible implementations to arise, but in this case it wouldn't have prevented this problem. No amount of examination of the Bitcoin source code would have revealed the limitation in BDB, and the resulting need for a configuration file to change the BDB default values.

Unit tests might not have even caught the problem because they said that not all 0.7 nodes rejected the large block. This implies that different BDB versions and/or platforms have different default values so consequently not all of them would have exhibited the problem, possibly including the platform used to run the unit tests.

An how would specification prevent what happened yesterday? Document the unknown bugs? Only thorough examination of source code could reveal hidden flaws.

I completely agree on the importance of Bitcoin.

Source code which contains unknown cases isn't acceptable for system (to be) used as medium of exchange. Bitcoin does have much much more at stake than some filesharing network, which is why there should be spec to follow.

For something that my life depend on, I want certainty that it's well understood and tested.

The source code is the best specification. No documentation written in human language be complete and unanimous enough to be sure that everything is covered. You cannot compile Hemingway writings into executable code.

Bitcoin with connectivity difficulties would have problems with different Bitcoin clients, but will happily create disconnected network and all sorts of other nasty things.

Bitcoin have much more at stake than Gnutella warez download.

Right, you're referring to the most recent isolated incident. Recognize that this is a symptom of a much larger problem, that realistically speaking there is only one implementation of Bitcoin and that it is difficult or impossible to write and maintain a separate implementation. First of all because there is no specification, and second because the current developers have the freedom to change the protocol at their whim.

If we had more diversity in interoperable implementations, a bug like the recent database problem would have been less severe.


And even more disturbing is the complete apathy of both the current developers and the Bitcoin Foundation at changing the status quo.

What I find somewhat disturbing that there is no real specification to adhere to. Just on reference implementation, which isn't obviously fully understood...

The problem wasn't the lack of a specification.  The problem was the new version met the specification and the old version had an unknown bug that limited it to a subset of the specification.  When the new version exercised this previously unused area of the specification space, it triggered the bug in the old version.

My opinion is that the extent to which a project succeeds is tied to the attributes of the leader. Gnutella was strongly influenced by LimeWire and BearShare's participation with the community in creating a subset of open standards and encouraging interoperability. LimeWire in particular made a point of keeping accurate protocol specifications, submitting proposals in writing ahead of time, and soliciting feedback from the community.

If we want Bitcoin development to follow the same trajectory, the first step is to get people involved who share these values, or convince the developers to adopt these values. Here's a start:


* Develop a comprehensive protocol specification from the code and stick to it
* Feature freeze until a protocol has been written
* Eliminate external dependencies in the reference client
* Define formal process for commits to the official repository


Commits which change the wire protocol or behavior of the reference client with respect to other nodes should only after the changes are fully described in a proposal paper and agreed upon.

Bitcoin implementations with connectivity bugs would find themselves unable to participate effectively in the network. But this situation is preferable to the current situation, which is a monoculture of developers who lack the motivation to define and adhere to a standard.

False. Different Gnutella implementations had interconnectivity issues in past. Bitcoin did it only once and even then a minor one.

Reserved

(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.4

Gnutella'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.6

Nodes 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 Proposals

The 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 Forum

The 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 Scalability

No 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 Network

Although 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:


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?"


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.