Proposed new P2P command and response: getcmds, cmdlist



Summary:

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.


Updated on: 2023-06-06T05:26:17.938884+00:00