This issue has been simmering for a while...
I agree with the following general principles, and it sounds like
others on the forums do too:
GP1) Alternative implementations of a protocol are beneficial to the ecosystem.
GP2) Tying together protocol and client version is sub-optimal, and
undesirable long term.
The current, coarse-grained scheme was clearly preferred by satoshi.
He knew what a chore creating a fully compliant client would be, and
when I joined (July 2010), was actively discouraging alternative
client efforts. Also, tying protocol and client version together
certainly eased the deployment of changes.
Protocol development has clearly slowed, and we have at least one
major alternative client in the works (bitcoinj), so it seems fair to
revisit those assumptions and preferences.
Looking back I have to agree that binding the protocol to the client version was in fact good, since it allowed for a fast evolution along with the then only client. My proposal to split the both may have come too early, but I personally grew frustrated when implementing my own networking stack. With the protocol having matured, and changes becoming ever less frequent, I'd be happy for the split to happen.
Here are several mini-proposals for the Satoshi Client (anyone got a
better nickname?) along these lines, which should better prepare the
bitcoin protocol for the long term:
I called it Mainline client (like the original Bittorrent client) as a hint that this is the reference implementation everybody should refer to, but Satoshi Client has a nice sound too :-)
MP1) Avoid creating four-component version numbers (W.X.Y.Z), and use
pszSubVer as a client identification string. This proposal originally
came from Mike Hearn, IIRC.
The version number being incremented each time a breaking change to the protocol has been made? Mike and I discussed that quite a while back, and using the String as client specific identifier with a version number (mainly for statistical purposes) sounds like a good idea, similar to User Agent strings in HTTP.
MP2) remove IP transactions in v0.4
MP3) create constants for protocol version, and audit code to split
client version from protocol version. This is a THORNY patch, and far
more difficult than https://github.com/bitcoin/bitcoin/pull/63
implies. The code has various data structures and such versioned, so
it is difficult to pick out at quick glance which 'version' is which.
Yeah, sorry for that one :-)
I posted the request to the issue tracker before that pull, and I was asked to submit a pull request with the needed changes, which sounded a bit strange for a conceptual change like this one. Isn't a gradual switch possible? I'd leave the version number as is and simply don't increment it, so if the code does not rely on specific values for pszSubVer it shouldn't break at all.
MP4) split protocol and client versions in v0.4 -- though you will not
actually notice a change until v0.4.1, when the client version changes
but the protocol version does not.
So we could consider version 40000 the first "stable" protocol release? Sounds good.
MP5) Use a single bit inside 'nServices' to indicate the presence of
an optional "capabilities" message. The purpose of this is to enable
minor protocol changes without having to change the protocol version.
Thus, nodes may advertise /features/ rather than simply "I support all
features >= version X". Most mature protocols support this sort of
thing, rather than the simpler, coarse-grained version number system.
Always happy to hear you like my idea :D
All in all I'm really looking forward to this.
Regards,
Chris
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development