Published on: 2011-06-15T13:04:06+00:00
In an email exchange in 2011, Jeff Garzik proposed several mini-proposals for the Satoshi Client, the original Bitcoin client. He suggested that the client needed a better nickname and proposed calling it the "Mainline client" or the "Reference client." Christian Decker agreed with the latter suggestion, as it is the original reference implementation.Garzik and Chris Moore also discussed the issue of alternative implementations of the Bitcoin protocol. They agreed that having alternative clients is beneficial to the ecosystem and that tying together protocol and client version is sub-optimal and undesirable in the long term. This was contrary to the preferences of Satoshi Nakamoto, who discouraged alternative client efforts. However, since protocol development had slowed down and there was at least one major alternative client in the works (bitcoinj), they felt it was time to revisit these assumptions and preferences.The mini-proposals put forward included avoiding creating four-component version numbers (W.X.Y.Z) and using pszSubVer as a client identification string. They also suggested removing IP transactions in v0.4, creating constants for protocol version, and auditing code to split client version from protocol version. Additionally, they proposed splitting protocol and client versions in v0.4 but not noticing a change until v0.4.1. Finally, they suggested using a single bit inside 'nServices' to indicate the presence of an optional "capabilities" message. All of these proposals aimed to better prepare the Bitcoin protocol for the long term and enable minor protocol changes without having to change the protocol version.The issue of alternative implementations of the Bitcoin protocol had been previously discussed on forums and was agreed upon by many. However, with the current slowdown in protocol development and the existence of alternative clients, it was deemed necessary to reconsider these assumptions and preferences. The mini-proposals put forward by Garzik and Moore were intended to address these concerns, supporting more mature protocols that use features rather than a blanket support for all features above a certain version.
Updated on: 2023-08-01T01:59:09.856868+00:00