P2P feature discovery (was Re: BIP 33 [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2012-05-16T18:46:49+00:00


Summary:

In a discussion on May 16, 2012, Jeff Garzik and Luke-Jr debated the idea of passing a large list of nodes along as part of the address. Luke-Jr suggested that service bits be propagated as part of the address to make it easier for users to identify nodes they want to connect to for specific services. However, Jeff Garzik raised concerns about the stratification of the peer list and the potential overload on bitcoin's P2P network. He believed that if the peer list becomes too stratified, clients should consider using another network instead. Luke-Jr clarified that his intention was for clients to be able to connect to specific nodes without connecting to every node.In an email exchange, Luke-Jr explained that service bits are already propagated as part of the address, allowing users to easily identify nodes for specific services. He acknowledged that passing long lists of nodes might not always be practical, but it could work for protocol changes that don't add new services. Jeff Garzik cautioned against using bitcoin's P2P network for unrelated tasks and emphasized the importance of not overloading the network with non-bitcoin related activities.On May 16, 2012, Jeff Garzik proposed an alternative solution to further overloading service bits or altering the version message. He suggested creating a new command called "get-features" that would return a list of key/value pairs. The key would be a string, and the value type would be determined by the key. This solution assumes that one already has a connection to the peer in question. By using this approach, clients can discover the features of a peer in an easy, flexible, and extensible manner. Passing a large list of nodes along may be unwieldy, but it could be useful for protocol changes that don't introduce new services.Amir Taaki proposed a different approach called BIP 33, which aimed to provide new functionality while maintaining compatibility with the existing Bitcoin protocol. This proposal suggested allowing a parallel system to operate alongside the main Bitcoin network without affecting current Bitcoin clients. However, Jeff Garzik suggested improving the discovery process by creating the "get-features" command. He proposed that this could be implemented as BIP 34 if there was enough interest from the community. The standard behavior of clients would be to send the "get-features" command after receiving remote version information as part of the initial connection handshake.


Updated on: 2023-08-01T03:32:21.429865+00:00