path: root/10/473d7ea3ac087ef191af73d30b49ffc54bba7c

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <decker.christian@gmail.com>) id 1QWpV4-0007Sn-G8
	for bitcoin-development@lists.sourceforge.net;
	Wed, 15 Jun 2011 12:47:14 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.210.47 as permitted sender)
	client-ip=209.85.210.47;
	envelope-from=decker.christian@gmail.com;
	helo=mail-pz0-f47.google.com; 
Received: from mail-pz0-f47.google.com ([209.85.210.47])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1QWpV0-0006kU-6M
	for bitcoin-development@lists.sourceforge.net;
	Wed, 15 Jun 2011 12:47:14 +0000
Received: by pzk36 with SMTP id 36so239455pzk.34
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 15 Jun 2011 05:47:04 -0700 (PDT)
Received: by 10.68.5.227 with SMTP id v3mr190722pbv.420.1308142024090; Wed, 15
	Jun 2011 05:47:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.51.167 with HTTP; Wed, 15 Jun 2011 05:46:24 -0700 (PDT)
In-Reply-To: <BANLkTi=4UeK2D0cCHYGp1tHUTGA2iyWHcA@mail.gmail.com>
References: <BANLkTi=4UeK2D0cCHYGp1tHUTGA2iyWHcA@mail.gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Wed, 15 Jun 2011 14:46:24 +0200
Message-ID: <BANLkTikCQ8g9bEpf2uosKm1Q_K_SSrh0nQ@mail.gmail.com>
To: Jeff Garzik <jgarzik@exmulti.com>
Content-Type: multipart/alternative; boundary=bcaec52158a9a963d204a5bf8c74
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM          Sender email is freemail
	(decker.christian[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
	0.0 RFC_ABUSE_POST Both abuse and postmaster missing on sender domain
	0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QWpV0-0006kU-6M
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Protocol versioning
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2011 12:47:14 -0000

--bcaec52158a9a963d204a5bf8c74
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 15, 2011 at 8:06 AM, Jeff Garzik <jgarzik@exmulti.com> wrote:

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

--bcaec52158a9a963d204a5bf8c74
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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


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 ecosys=
tem.<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. =A0Also, 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 bac=
k I have to agree that binding the protocol to the client version was in fa=
ct good, since it allowed for a fast evolution along with the then only cli=
ent. My proposal to split the both may have come too early, but I personall=
y grew frustrated when implementing my own networking stack. With the proto=
col having matured, and changes becoming ever less frequent, I&#39;d be hap=
py for the split to happen.<br>


</div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;b=
order-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 Mainli=
ne 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=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;b=
order-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. =A0This proposal originally<br=
>
came from Mike Hearn, IIRC.<br></blockquote><div>The version number being i=
ncremented 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 spe=
cific identifier with a version number (mainly for statistical purposes) so=
unds like a good idea, similar to User Agent strings in HTTP. <br>


</div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;b=
order-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br>
MP2) remove IP transactions in v0.4=A0<br></blockquote><blockquote class=3D=
"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(2=
04, 204, 204);padding-left:1ex">
<br>
MP3) create constants for protocol version, and audit code to split<br>
client version from protocol version. =A0This is a THORNY patch, and far<br=
>
more difficult than <a href=3D"https://github.com/bitcoin/bitcoin/pull/63" =
target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/63</a><br>
implies. =A0The code has various data structures and such versioned, so<br>
it is difficult to pick out at quick glance which &#39;version&#39; is whic=
h.<br></blockquote><div>Yeah, sorry for that one :-)<br>I posted the reques=
t to the issue tracker before that pull, and I was asked to submit a pull r=
equest with the needed changes, which sounded a bit strange for a conceptua=
l 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 al=
l.<br>


</div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;b=
order-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 conside=
r version 40000 the first &quot;stable&quot; protocol release? Sounds good.=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8=
ex;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 o=
f<br>
an optional &quot;capabilities&quot; message. =A0The 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;=3D version X&quot;. =A0Most mature protocols support this sor=
t 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=3D"gmail_quote" style=3D"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=3D"mailto:jgarzik@exmulti.com" target=3D"_blank">jgarzik@exmulti.co=
m</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=3D"http://p.sf.net/sfu/ephox-dev2dev" target=3D"_blank">http://p.sf=
.net/sfu/ephox-dev2dev</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br>

--bcaec52158a9a963d204a5bf8c74--