Published on: 2012-06-18T01:27:39+00:00
The discussion revolves around the Bitcoin protocol and its implementation. The first message suggests that the BitTorrent model, with its capability-based extension system, could be a useful example for the Bitcoin protocol to follow. This could involve trying out new algorithms, adding new features, and reverting protocol changes if necessary. The problem with implementing the Bitcoin protocol is not the protocol itself, but the fact that changes to it can happen suddenly without proper consideration or reflection.The second message highlights the complexity of the current P2P protocol in Bitcoin and the challenges faced by developers maintaining non-Satoshi codebases. The lack of documentation on the wiki makes it difficult to reference and implement. The P2P protocol is already filled with magic numbers and arbitrarily versioned binary data structures, making it a potentially buggy and insecure zoo of complicated interactions. The author posits that incremental protocol versions with clear requirements could be a better solution than the current extension system.The creator and maintainer of a full reimplementation of the Bitcoin protocol has stated that although the Bitcoin protocol is simple, it is filled with arbitrary endianness and magic numbers. The problem lies not in implementing the protocol, but in once having created a codebase, wanting to perfect and fine-tune the design. Changes to the Bitcoin protocol are more damaging than any issues with the current protocol. Although the author agrees with changes, they should be more conservative and have a longer time frame. Changes usually get added to the Satoshi client abruptly, which results in a week spent working to implement the change without proper consideration or reflection, compromising on design choices to remain compatible with the protocol. Despite this, the creator does not intend to slow down progress and tries to hedge against conservatism.Jeff Garzik responded to the above message and pointed out that for anyone maintaining a non-Satoshi codebase, the P2P protocol is already filled with all sorts of magic numbers, arbitrarily versioned binary data structures, and an unfriendly zoo of complicated and potentially buggy interactions. There is scant documentation on the wiki, making the Satoshi source code the only true reference. In comparison to other protocols, Bitcoin's P2P protocol is backwards, fragile, limited, and inflexible when it comes to parameter/extension exchange and negotiation. Jeff called the current P2P protocol "simple," but he believes that calling it so belies all the implementation details you absolutely must get right to run on mainnet today.In an email conversation, Jeff Garzik discusses the present version of Bitcoin’s peer-to-peer (P2P) protocol. While it is easy to make a protocol change and increase PROTOCOL_VERSION in the Satoshi client, other non-Satoshi codebases face difficulties since the P2P protocol already has numerous magic numbers, binary data structures, and complex interactions that are difficult to understand without complete documentation. In contrast to modern protocols like HTTP and JSON, bitcoin’s P2P protocol is fragile, inflexible, and outdated when it comes to parameter/extension exchange and negotiation. Garzik calls it a “zoo of complicated and potentially buggy interactions” with scarce, incomplete documentation, which makes it hard for other non-Satoshi codebase maintainers to work on the same. He further explains how even iSCSI, implemented on hard drive firmware, has the ability to exchange key=value parameters between local and remote sides of the Remote Procedure Call (RPC) connection.In this email conversation, Wladimir proposes standardizing the functionality of thin and thick clients without explicitly enumerating everything over the protocol. However, Andy expresses concern that the spectrum of clients will be more diverse than just "thin" or "thick." He suggests making a field that can hold more than just a bit with each value representing a specific set of features. Alternatively, they could enumerate the features instead of defining a specific set of feature-version mapping. Andy believes too much emphasis is being placed on defining a specific set of feature-version mapping, which makes it hard for future clients to implement some features but not all. He also notes that there is no easy way for a node to tell another that it doesn't have the whole blockchain available, so requesting it from it will fail. Wladimir agrees that the interaction between protocol versions and capabilities needs to be defined as well. Both agree that a capability system may be a good idea, but the granularity should be large, not command-level. They also note that the arguments might have changed between protocol versions, so offering "getdata" at protocol version 10 does not necessarily mean the same as offering it at protocol version 11. Finally, they agree that having a system for finding out what peers support makes it far easier to discover peer capabilities.A developer is concerned about the potential for Bitcoin's P2P protocol to become complex and vulnerable. They suggest being cautious about making changes unless absolutely necessary.
Updated on: 2023-08-01T03:39:15.529952+00:00