I'm all for a specification of some kind of the protocol. We gave it a first shot when trying to get a working Bitcoin Client to work with pybitcoin, but it turned out the protocol is both complex and hard to understand at times. Also a high level overview of how the different scenarios play out would be incredibly helpful.

We do need alternative clients for the Network, as proven by the huge interest in a native Android client, and for that to ever happen we need a specification of the underlying protocol.

I've seen specifications take years to get completed, so much of it depends upon how much detail that you put into the specification document. Some of them are pretty good, some are abysmal in terms of how close they are to reality and even in terms of ease of re-implementation based off of the specification.

The one nice thing about having a clean spec to work off of, besides the fact that you can create a new implementation without having to copy software, is that you can also argue about specific parts of the specification as a common framework in a fashion like you argue about legislation.  In fact, the process is very similar in terms of how laws are passed in a legislative environment.  The difference is that engineers, not lawyers have to be able to use whatever it is that you come up with.

One of the best real specifications that I've ever read was the PNG image file specification:

http://www.libpng.org/pub/png/spec/1.2/

This is of course not similar to what we have here with Bitcoins, which is instead a networking protocol.  That would be more similar to the Internet RFCs which can be found here:

http://www.ietf.org/rfc.html

If you want to read a real specification and at the same time see a bit of nerd humor, I'd suggest that you read this particular spec here:

http://tools.ietf.org/html/rfc1149

I would expect this to take several man-months of effort at the least in terms of getting it prepared for one of these international bodies.  Preferably, I'd love to see this submitted as a formal network RFC once we get everything nailed down real good.  That would give Bitcoins some solid legitimacy and is a pretty high quality target to hit.

There are other standards bodies we need to work with as well, including the ECMA (European Computer Manufacturer's Association) and the W3C (Web standards committee).

I think an incremental approach is the only practical one here.

Specify first those parts that are (a) relatively easy to specify, and (b) for which it is particularly useful to have a specification. For everything else, just rely on the reference implementation for now.

For this incremental approach, the wiki is ideal. Some time in the future a more formal process might be considered, but for now it would just slow things down.

I suppose it is my time to waste getting such an effort done.  The issue here is that the protocol is the network.  I know that some software developers hate to be hamstrung with a formal spec that they must work from, under the presumption that perhaps too much planning in advance will straight jacket their ability to code.

My own personal experience is considerably different, where the time spent in planning and documenting ahead of time is time very much worth the effort and makes the job of any sort of coding considerably easier.  It also tends to make for much, much cleaner software that is easier to maintain, easier to extend, and as an indirect result less dependent upon a single person to make all of the decisions.

This is essentially the difference between a mere computer programmer and a real software engineer too.  A programmer is somebody who pulls out the compiler/editor to figure out how to get a project working, where a software engineer starts with a word processor.  That coding needs to happen eventually is true, but setting out a roadmap for how the project is to be developed is usually a good start.

We could debate and discuss various models used for software development here too, but by its very nature Bitcoins is something that deserves to have some significant effort at bringing eyeballs into its development, and the more eyeballs that we have the better that the network will behave.  At the moment it is just a minor amount of money involved, but it soon may represent some significant economic activity.  To me, this deserves some solid software engineering principles which includes documenting the effort going on here.

I'm not expecting anybody to necessarily participate in this effort, but it seems strange that there is resistance to even start such an effort and potentially thwarting such an effort.  If Bitcoins is incomplete, let's make it more complete.  If there are gaps, those gaps need to be filled.

As a veteran of the premature standardization trenches (I wrote most of the ISO/IEC 14772-1 "VRML97" specification before I changed my last name from "Bell" to "Andresen")... I agree with foreverdamaged.  It is too early to try to create a formal specification.

However, it think writing informal specifications documenting how bitcoin works right now is a great idea, and will be really helpful when it is time to go through some standardization process.

Well, there is no way how to implement unofficial clients for many users/programmers (like me), because they are not enough skilled in C++ and reverse engineering. But I'm capable to write alternate client with at least basic specification how whole thing works. Unfortunatelly because I'm not capable to write own client, I'm also not capable to help anybody with specs. At this time, I'm dependent to somebody else who starts specification process.

I'm absolutely not talking about any formal standard, wiki should help a lot in this stage.

#1 & #3 seem contradictory.  How can a connecting client initiate a handshake on an unknown port without spamming the target?  Wouldn't it still show up on a portscan that was specificly looking for a running bitcoin client?

I see.  Well, I'm not a programmer, yet I cannot see the value in obscuring, encrypting or otherwise trying to hide the port.  The port can be blocked for those who wish to hide their client, and still work; while the data in transit is only openly coded transactions and blocks.  The only risks to the port being open is a sign to potential crackers that there is a running client (and therefore a wallet.dat) on the machine.  Just close the port if that is a concern.

I've thrown some additional information onto the wiki already, at least enough to start.  I've found at least some of the relevant sections in the source code for Bitcoins and will try to get some more information put on there, as well as some threads to look through as well.  More theory certainly should be put together, and perhaps an evaluation of some of the decisions already made... which can certainly be useful.