Skip to content

[WIP] clarify BIP152 sendcmpct message exchange #461

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jnewbery wants to merge 1 commit into from
Closed

[WIP] clarify BIP152 sendcmpct message exchange #461

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions bip-0152.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -105,12 +105,12 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
====sendcmpct====
# The sendcmpct message is defined as a message containing a 1-byte integer followed by a 8-byte integer where pchCommand == "sendcmpct".
# The first integer SHALL be interpreted as a boolean (and MUST have a value of either 1 or 0)
# 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 first and second integers set to 1, the node SHOULD announce new blocks by sending a cmpctblock message.
# 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.
# 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.
# 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.
# 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.
Copy link
Copy Markdown
Contributor

@TheBlueMatt TheBlueMatt Oct 14, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

# 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.
Copy link
Copy Markdown
Contributor

@TheBlueMatt TheBlueMatt Oct 14, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

# If the node has sent *and* received "sendcmpct" 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.
# Nodes SHOULD check for a protocol version of >= 70014 before sending sendcmpct messages.
# Nodes MUST NOT send a request for a MSG_CMPCT_BLOCK object to a peer before having received a sendcmpct message from that peer.
# Nodes MUST NOT send a request for a MSG_CMPCT_BLOCK object to a peer before having sent and received a "sendcmpct" message with that peer.

====MSG_CMPCT_BLOCK====
# getdata messages may now contain requests for MSG_CMPCT_BLOCK objects.
Expand Down