Published on: 2013-06-20T13:35:11+00:00
In a discussion about the relay field of a network packet, Addy Yeow emphasized its importance and explained that it is not an optional field. To read the packet correctly, one should first retrieve the header information, get the actual payload length, and then parse the payload accordingly. Yeow also mentioned that including 0x00 for the relay field in the outgoing packet and reflecting it in the length field in the header is possible.Jeff Garzik, a Senior Software Engineer and open source evangelist at BitPay, responded to Yeow's message by stating that although the logic of parsing fields may be ugly, there is no need to change it now. He argued that updating the version message to a different design solely for cleanliness reasons is not sufficient cause to migrate the entire bitcoin universe to a new and different version/feature negotiation setup.In this conversation, the participants discuss the issue of variable-length messages in Bitcoin protocol and their effect on parsing messages. They agree that optional lengths shouldn't be used and for every field change, the protocol version should be upgraded. The fRelayTxes field is specifically discussed and it is mentioned that it has been made a part of the protocol, but old clients don't send it so it has to be optional. The participants also discuss BIP 60, which proposes a protocol upgrade and details everything that needs to be done. Ultimately, they agree that having a fixed number of fields per protocol version would be beneficial for parsing messages and considered good practice.The Bitcoin protocol version was last bumped when Bloom filtering was added, and there is no need to bump it again. The existence of the nStartingHeight field depends on the message length and not anything else, and given that the old clients have to be handled no matter what, it is consistent with how other version fields are handled. A user named Turkey Breast brought up the issue that optional lengths shouldn't be used and for every field change, the protocol version should be upgraded. However, this is the first time anyone has suggested this minor detail is a problem, and it doesn't present any issues for the C++ code or bitcoinj where message objects know their own length at parse time. Additionally, Bitcoin version messages have always had variable length, and it is not inherent in the Bitcoin protocol that all messages are fixed length.Mike Hearn notes that if one wants to criticize the Bitcoin protocol for sloppiness, the variable length of some messages isn't where he would start. He points out that ping has the same issue, its length has changed over time to include the nonce. If one's parser can't handle that kind of thing, they need to fix it since the protocol has always worked that way. Similarly, when new fields are added to the version message, it's not a big deal to say that this protocol version has X number of fields, that (higher) protocol version message has X + N number of fields. Deterministic number of fields per protocol version is sensible and how Bitcoin has been for a long time.Turkey Breast believes that the existence of an unclear behavior that depends on some magic from one implementation doesn't help other implementations. He suggests that a fixed number of fields per protocol should be made, so given a protocol version number, one knows the number of fields in a message. This is not only easier for parsing messages but just good practice.Mike Hearn clarifies that it's not a bug (although there was recently a change to make bitcoind/qt always send this field anyway). He doesn't know where Amir is going with BIP 60, and he notes that version messages have always been variable length. There's nothing inherent in the Bitcoin protocol that says all messages are fixed length.In an email thread between Mike Hearn and Paul Lyon, they discuss the issue of the fRelayTxes field missing from some Bitcoin version messages. Turkey Breast also chimes in, suggesting that it would be better if messages always had a fixed number of fields per protocol version, rather than having variable length. Some argue that this is not a bug, but rather just how the protocol has always worked, with variable length messages being allowed for tx messages, for example. Ultimately, it is suggested that the protocol version should be upgraded to reflect the inclusion of fRelayTxes.The Bitcoin protocol has variable message length, which is also the case with ping messages. The issue may be a problem for some parsers who cannot handle it, but it has always been that way, and if you experience issues now, it means no sufficiently old nodes were talking to yours. The standard does not say the version message field should appear. There was a recent change to make bitcoind/qt always send the fRelayTxes field anyway, although it doesn't affect anything. The Bitcoin protocol has allowed tx messages to have arbitrary data appended after them that gets relayed.
Updated on: 2023-08-01T05:10:52.387811+00:00