On Wed, Jun 15, 2011 at 8:06 AM, Jeff Garzik <span dir="ltr">&lt;<a href="mailto:jgarzik@exmulti.com" target="_blank">jgarzik@exmulti.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


This issue has been simmering for a while...<br>
<br>
I agree with the following general principles, and it sounds like<br>
others on the forums do too:<br>
<br>
GP1) Alternative implementations of a protocol are beneficial to the ecosystem.<br>
<br>
GP2) Tying together protocol and client version is sub-optimal, and<br>
undesirable long term.<br>
<br>
The current, coarse-grained scheme was clearly preferred by satoshi.<br>
He knew what a chore creating a fully compliant client would be, and<br>
when I joined (July 2010), was actively discouraging alternative<br>
client efforts.  Also, tying protocol and client version together<br>
certainly eased the deployment of changes.<br>
<br>
Protocol development has clearly slowed, and we have at least one<br>
major alternative client in the works (bitcoinj), so it seems fair to<br>
revisit those assumptions and preferences.<br></blockquote><div>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&#39;d be happy for the split to happen.<br>


</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br>
Here are several mini-proposals for the Satoshi Client (anyone got a<br>
better nickname?) along these lines, which should better prepare the<br>
bitcoin protocol for the long term:<br></blockquote><div>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 :-)<br>


</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br>
MP1) Avoid creating four-component version numbers (W.X.Y.Z), and use<br>
pszSubVer as a client identification string.  This proposal originally<br>
came from Mike Hearn, IIRC.<br></blockquote><div>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. <br>


</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br>
MP2) remove IP transactions in v0.4 <br></blockquote><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br>
MP3) create constants for protocol version, and audit code to split<br>
client version from protocol version.  This is a THORNY patch, and far<br>
more difficult than <a href="https://github.com/bitcoin/bitcoin/pull/63" target="_blank">https://github.com/bitcoin/bitcoin/pull/63</a><br>
implies.  The code has various data structures and such versioned, so<br>
it is difficult to pick out at quick glance which &#39;version&#39; is which.<br></blockquote><div>Yeah, sorry for that one :-)<br>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&#39;t a gradual switch possible? I&#39;d leave the version number as is and simply don&#39;t increment it, so if the code does not rely on specific values for pszSubVer it shouldn&#39;t break at all.<br>


</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br>
MP4) split protocol and client versions in v0.4 -- though you will not<br>
actually notice a change until v0.4.1, when the client version changes<br>
but the protocol version does not.<br></blockquote><div>So we could consider version 40000 the first &quot;stable&quot; protocol release? Sounds good.<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">



<br>
MP5) Use a single bit inside &#39;nServices&#39; to indicate the presence of<br>
an optional &quot;capabilities&quot; message.  The purpose of this is to enable<br>
minor protocol changes without having to change the protocol version.<br>
Thus, nodes may advertise /features/ rather than simply &quot;I support all<br>
features &gt;= version X&quot;.  Most mature protocols support this sort of<br>
thing, rather than the simpler, coarse-grained version number system.<br></blockquote><div>Always happy to hear you like my idea :D<br><br>All in all I&#39;m really looking forward to this.<br><br>Regards,<br>Chris <br></div>


<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br>
--<br>
Jeff Garzik<br>
exMULTI, Inc.<br>
<a href="mailto:jgarzik@exmulti.com" target="_blank">jgarzik@exmulti.com</a><br>
<br>
------------------------------------------------------------------------------<br>
EditLive Enterprise is the world&#39;s most technically advanced content<br>
authoring tool. Experience the power of Track Changes, Inline Image<br>
Editing and ensure content is compliant with Accessibility Checking.<br>
<a href="http://p.sf.net/sfu/ephox-dev2dev" target="_blank">http://p.sf.net/sfu/ephox-dev2dev</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net" target="_blank">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</blockquote></div><br>