📅 Original date posted:2011-06-15
🗒️ Summary of this message: Jeff Garzik proposes mini-proposals for the Satoshi Client to better prepare the bitcoin protocol for the long term, including splitting protocol and client versions.
📝 Original message:On Wed, Jun 15, 2011 at 8:06 AM, Jeff Garzik <jgarzik at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110615/fb8ab67d/attachment.html>;
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-07 01:37:33
in reply to nevent1q…lf46
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-07 01:37:33Event JSON
{
"id": "672602a1108cd35d80c3822f01c72b5fbcafec7f9097db924662c289376e065f",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686101853,
"kind": 1,
"tags": [
[
"e",
"8aa10ca75bda6870fffeeca9f6b8526fe939c806490c5c6e585798c8693b1a5e",
"",
"root"
],
[
"e",
"6ffa7d6185aa0052258cc86913b7112fbed23394458f3cdcf4cb8510eea73589",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2011-06-15\n🗒️ Summary of this message: Jeff Garzik proposes mini-proposals for the Satoshi Client to better prepare the bitcoin protocol for the long term, including splitting protocol and client versions.\n📝 Original message:On Wed, Jun 15, 2011 at 8:06 AM, Jeff Garzik \u003cjgarzik at exmulti.com\u003e wrote:\n\n\u003e This issue has been simmering for a while...\n\u003e\n\u003e I agree with the following general principles, and it sounds like\n\u003e others on the forums do too:\n\u003e\n\u003e GP1) Alternative implementations of a protocol are beneficial to the\n\u003e ecosystem.\n\u003e\n\u003e GP2) Tying together protocol and client version is sub-optimal, and\n\u003e undesirable long term.\n\u003e\n\u003e The current, coarse-grained scheme was clearly preferred by satoshi.\n\u003e He knew what a chore creating a fully compliant client would be, and\n\u003e when I joined (July 2010), was actively discouraging alternative\n\u003e client efforts. Also, tying protocol and client version together\n\u003e certainly eased the deployment of changes.\n\u003e\n\u003e Protocol development has clearly slowed, and we have at least one\n\u003e major alternative client in the works (bitcoinj), so it seems fair to\n\u003e revisit those assumptions and preferences.\n\u003e\nLooking back I have to agree that binding the protocol to the client version\nwas in fact good, since it allowed for a fast evolution along with the then\nonly client. My proposal to split the both may have come too early, but I\npersonally grew frustrated when implementing my own networking stack. With\nthe protocol having matured, and changes becoming ever less frequent, I'd be\nhappy for the split to happen.\n\n\u003e\n\u003e Here are several mini-proposals for the Satoshi Client (anyone got a\n\u003e better nickname?) along these lines, which should better prepare the\n\u003e bitcoin protocol for the long term:\n\u003e\nI called it Mainline client (like the original Bittorrent client) as a hint\nthat this is the reference implementation everybody should refer to, but\nSatoshi Client has a nice sound too :-)\n\n\u003e\n\u003e MP1) Avoid creating four-component version numbers (W.X.Y.Z), and use\n\u003e pszSubVer as a client identification string. This proposal originally\n\u003e came from Mike Hearn, IIRC.\n\u003e\nThe version number being incremented each time a breaking change to the\nprotocol has been made? Mike and I discussed that quite a while back, and\nusing the String as client specific identifier with a version number (mainly\nfor statistical purposes) sounds like a good idea, similar to User Agent\nstrings in HTTP.\n\n\u003e\n\u003e MP2) remove IP transactions in v0.4\n\u003e\n\n\u003e MP3) create constants for protocol version, and audit code to split\n\u003e client version from protocol version. This is a THORNY patch, and far\n\u003e more difficult than https://github.com/bitcoin/bitcoin/pull/63\n\u003e implies. The code has various data structures and such versioned, so\n\u003e it is difficult to pick out at quick glance which 'version' is which.\n\u003e\nYeah, sorry for that one :-)\nI posted the request to the issue tracker before that pull, and I was asked\nto submit a pull request with the needed changes, which sounded a bit\nstrange for a conceptual change like this one. Isn't a gradual switch\npossible? I'd leave the version number as is and simply don't increment it,\nso if the code does not rely on specific values for pszSubVer it shouldn't\nbreak at all.\n\n\u003e\n\u003e MP4) split protocol and client versions in v0.4 -- though you will not\n\u003e actually notice a change until v0.4.1, when the client version changes\n\u003e but the protocol version does not.\n\u003e\nSo we could consider version 40000 the first \"stable\" protocol release?\nSounds good.\n\n\u003e\n\u003e MP5) Use a single bit inside 'nServices' to indicate the presence of\n\u003e an optional \"capabilities\" message. The purpose of this is to enable\n\u003e minor protocol changes without having to change the protocol version.\n\u003e Thus, nodes may advertise /features/ rather than simply \"I support all\n\u003e features \u003e= version X\". Most mature protocols support this sort of\n\u003e thing, rather than the simpler, coarse-grained version number system.\n\u003e\nAlways happy to hear you like my idea :D\n\nAll in all I'm really looking forward to this.\n\nRegards,\nChris\n\n\u003e\n\u003e --\n\u003e Jeff Garzik\n\u003e exMULTI, Inc.\n\u003e jgarzik at exmulti.com\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e EditLive Enterprise is the world's most technically advanced content\n\u003e authoring tool. Experience the power of Track Changes, Inline Image\n\u003e Editing and ensure content is compliant with Accessibility Checking.\n\u003e http://p.sf.net/sfu/ephox-dev2dev\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110615/fb8ab67d/attachment.html\u003e",
"sig": "145fe3be2a2f1f1dc6bf1066c56015bf937016f59920811a58b344d05646e7dbe57f0a9dbe9e74dd9f4d11ccf189b7cb35b1a3979743fb4032259d9c29e604e4"
}