Yes we should start working on a standard, since diversity of node code bases is inevitable.
Adoption of new releases of the standard client will never be 100% and there are use cases
it does not serve well, so people are patching or using alternate implementations.
Creating a precise standard is something the bitcoin foundation should consider sponsoring.
In my experience, developers are really good at either ignoring documentation or interpreting it in a way different than the way the author intended.
And spec authors are really good at getting details wrong, no matter how careful they are. And they're really bad at keeping track of changes.
That's why I spent a lot of time over the past year developing test cases and tools that you can run your code against instead of writing specs.
I may just be cynical because I spent so much time in 1997 working on the ISO/IEC-14772-1 Official, Formal Standard.
It bothers me that this topic keeps coming up. The fact that Bitcoin is different to other technologies isn't intuitive but by the time you're writing an actual implementation, it should be obvious. Maybe it's worth reading the thread with grau about his reimplementation also?
The fact is that re-implementing Bitcoin exposes not only you, but all participants, to a class of "chain splitting" bugs that don't really exist in other network technologies, or at least are nowhere near as severe . . . When you reimplement Bitcoin, it's not enough to build things as you think they should work. You have to implement them exactly as Satoshi did, including all his bugs. And 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.
At some point, if you realize you have to match the behaviour of another codebase exactly, down to the tiniest detail, you realize that the only precise enough specification for that is the source code . . .
