[WIP] clarify BIP152 sendcmpct message exchange #461

 104 | @@ -105,12 +105,12 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 105 |  ====sendcmpct====
 106 |  # The sendcmpct message is defined as a message containing a 1-byte integer followed by a 8-byte integer where pchCommand == "sendcmpct".
 107 |  # The first integer SHALL be interpreted as a boolean (and MUST have a value of either 1 or 0)
 108 | -# The second integer SHALL be interpreted as a little-endian version number. Nodes sending a sendcmpct message MUST currently set this value to 1.
 109 | -# Upon receipt of a "sendcmpct" message with the first and second integers set to 1, the node SHOULD announce new blocks by sending a cmpctblock message.
 110 | -# Upon receipt of a "sendcmpct" message with the first integer set to 0, the node SHOULD NOT announce new blocks by sending a cmpctblock message, but SHOULD announce new blocks by sending invs or headers, as defined by BIP130.
 111 | -# Upon receipt of a "sendcmpct" message with the second integer set to something other than 1, nodes MUST treat the peer as if they had not received the message (as it indicates the peer will provide an unexpected encoding in cmpctblock, and/or other, messages). This allows future versions to send duplicate sendcmpct messages with different versions as a part of a version handshake for future versions.
 112 | +# The second integer SHALL be interpreted as a little-endian version number. Nodes sending a sendcmpct message MUST currently set this value to 1. Upon receipt of a "sendcmpct" message with the second integer set to something other than 1, nodes MUST treat the peer as if they had not received the message (as it indicates the peer will provide an unexpected encoding in cmpctblock, and/or other, messages). This allows future versions to send duplicate sendcmpct messages with different versions as a part of a version handshake for future versions.
 113 | +# Upon receipt of a "sendcmpct" message with the first integer set to 1, if the node wishes to use high-bandwidth compact block mode, it MUST respond with a "sendcmpct" message with the first integer set to 1. Upon receipt of a "sendcmpct" message with the first integer set to 0, if the node wishes to use low-bandwidth compact block mode, it MUST respond with a "sendcmpct" message with the first integer set to 0.

TheBlueMatt commented at 2:47 PM on October 14, 2016:

This seems to imply, to me, that a node should wait for a sendcmpct message before sending its announce, which it should not.

 109 | -# Upon receipt of a "sendcmpct" message with the first and second integers set to 1, the node SHOULD announce new blocks by sending a cmpctblock message.
 110 | -# Upon receipt of a "sendcmpct" message with the first integer set to 0, the node SHOULD NOT announce new blocks by sending a cmpctblock message, but SHOULD announce new blocks by sending invs or headers, as defined by BIP130.
 111 | -# Upon receipt of a "sendcmpct" message with the second integer set to something other than 1, nodes MUST treat the peer as if they had not received the message (as it indicates the peer will provide an unexpected encoding in cmpctblock, and/or other, messages). This allows future versions to send duplicate sendcmpct messages with different versions as a part of a version handshake for future versions.
 112 | +# The second integer SHALL be interpreted as a little-endian version number. Nodes sending a sendcmpct message MUST currently set this value to 1. Upon receipt of a "sendcmpct" message with the second integer set to something other than 1, nodes MUST treat the peer as if they had not received the message (as it indicates the peer will provide an unexpected encoding in cmpctblock, and/or other, messages). This allows future versions to send duplicate sendcmpct messages with different versions as a part of a version handshake for future versions.
 113 | +# Upon receipt of a "sendcmpct" message with the first integer set to 1, if the node wishes to use high-bandwidth compact block mode, it MUST respond with a "sendcmpct" message with the first integer set to 1. Upon receipt of a "sendcmpct" message with the first integer set to 0, if the node wishes to use low-bandwidth compact block mode, it MUST respond with a "sendcmpct" message with the first integer set to 0.
 114 | +# If the node has sent *and* received "sendcmpct" with the first integer set to 1, the node SHOULD announce new blocks by sending a cmpctblock message.

TheBlueMatt commented at 2:49 PM on October 14, 2016:

This seems to imply, to me, that you have to send a sendcmpct message with a 1 in order to announce using cmpctblocks, which isnt true, you only need to receive one.