Version 2 sendcmpct for integration of segwit with CB #423

sipa commented at 3:02 PM on July 22, 2016: member

No description provided.

sipa force-pushed on Jul 22, 2016

in bip-0152.mediawiki:None in 833a37be28 outdated

 199 | @@ -190,6 +200,18 @@ In case 1, we're good. In cases 2, 3, or 4, we request the full transaction beca
 200 |  
 201 |  This means that ''B = 48'' bits short IDs suffice for blocks with up to ''t = 10000'' transactions, mempools up to ''m = 100000'' transactions, with failure to reconstruct at most one in ''F = 281474'' blocks. Since failure to reconstruct just means we fall back to normal inv/header based relay, it isn't necessary to avoid such failure completely. It just needs to be sufficiently rare they have a lower impact than random transmission failures (for example, network disconnection, node overloaded, ...).
 202 |  
 203 | +====Separate version for segregated witness====
 204 | +
 205 | +The changes to transaction and block relay in BIP 144 introduce separate MSG_FILTERED_ versions of messages in getdata,
 206 | +allowing a receiver to choose individually where witness data is wanted.
 207 | +
 208 | +This method is not useful for compact blocks because `cmpctblock` blocks can be sent unsollicitedly in high-bandwidth

btcdrak commented at 3:06 PM on July 22, 2016:

s/unsollicitedly/unsolicitedly/

sipa force-pushed on Jul 22, 2016

btcdrak commented at 3:14 PM on July 22, 2016: contributor

ping @TheBlueMatt

btcdrak commented at 3:15 PM on July 22, 2016: contributor

@sipa Maybe you should like to the pull request that enables this feature in the reference implementation section.

sipa cross-referenced this on Jul 22, 2016 from issue Support for compact blocks together with segwit by sipa

sipa force-pushed on Jul 22, 2016

sipa commented at 3:23 PM on July 22, 2016: member

@btcdrak Done.

luke-jr added the label Proposed BIP modification on Jul 22, 2016

sdaftuar commented at 12:59 PM on July 25, 2016: member

I'm not sure I understand the thinking behind how feature negotiation is intended to work.

The original BIP made a reference to a version "handshake" in the future, which I figured meant that peers would be looking at each others sendcmpct version number to choose, say, the minimum common behavior.

This BIP modification doesn't really talk about how the handshake works between version 1 and version 2 clients, and looking at the implementation in bitcoin/bitcoin#8393, it seems that extra state is used to make this determination (namely the nServices advertised by a node). My initial thought was that it might be better to not rely on state outside the sendcmpct message (but I'm not sure, maybe for segwit this is appropriate) -- but regardless I think it'd be helpful to at least spell out more exactly in the BIP what the intended protocol here is.

in bip-0152.mediawiki:None in 55ed38f6b5 outdated

 142 | +
 143 | +# The version number inside sendcmpct is 2 instead of 1.
 144 | +# Transactions inside cmpctblock messages (both those used as direct announcement and those in response to getdata) and in blocktxn should include witness data, using the same format as responses to getdata MSG_WITNESS_TX, specified in BIP144.
 145 | +# Short transaction IDs sent to us in cmpctblock messages, and sent by us in getblocktxn messages, will be computed using the witness hash (the wtxid as defined in BIP 141).
 146 | +
 147 | +For nodes that support segwit, it is RECOMMENDED to support both version 1 and 2 compact blocks. To do so, two sendcmpct messages can be sent at startup: the first one for version 1 and a second one for version 2.

TheBlueMatt commented at 6:46 PM on July 30, 2016:

I would argue MAY, not RECOMMENDED.

in bip-0152.mediawiki:None in 55ed38f6b5 outdated

 140 | +==Specification for version 2==
 141 | +Compact blocks version 2 is almost identical to version 1, but supports segregated witness transactions (BIP 141 and BIP 144). The changes are:
 142 | +
 143 | +# The version number inside sendcmpct is 2 instead of 1.
 144 | +# Transactions inside cmpctblock messages (both those used as direct announcement and those in response to getdata) and in blocktxn should include witness data, using the same format as responses to getdata MSG_WITNESS_TX, specified in BIP144.
 145 | +# Short transaction IDs sent to us in cmpctblock messages, and sent by us in getblocktxn messages, will be computed using the witness hash (the wtxid as defined in BIP 141).

TheBlueMatt commented at 6:48 PM on July 30, 2016:

"by following the same process as in version 1" or something like that, to be more specific.

sipa force-pushed on Jul 30, 2016

sipa commented at 12:58 AM on August 1, 2016: member

Modified the proposal to use the announce-multiple-sendcmpct-versions mechanism instead, and adapted the related core PR.

sipa commented at 8:24 PM on August 3, 2016: member

@sdaftuar @TheBlueMatt Comments on the modification?

in bip-0152.mediawiki:None in 246554a77f outdated

 142 | +
 143 | +# The version number inside sendcmpct is 2 instead of 1.
 144 | +# Transactions inside cmpctblock messages (both those used as direct announcement and those in response to getdata) and in blocktxn should include witness data, using the same format as responses to getdata MSG_WITNESS_TX, specified in BIP144.
 145 | +# Short transaction IDs sent to us in cmpctblock messages, and sent by us in getblocktxn messages, are computed using the same process as in version 1, but using the wtxid as defined in BIP 141 instead of the txid.
 146 | +
 147 | +Nodes that support segwit MAY choose to support both version 1 and 2 compact blocks. To do so, two sendcmpct messages can be sent at startup: the first one for version 1 and a second one for version 2.

sdaftuar commented at 5:22 PM on August 4, 2016:

As I mentioned in https://github.com/bitcoin/bitcoin/pull/8393#discussion_r73564353, I think that if we require the version messages to be sent in a particular order for correct operation, then we should clarify the language here. Perhaps:

To do so, two sendcmpct messages can be sent at startup and MUST be in this order: the first one for version 1 and a second one for version 2.

However I think I'd prefer to drop the requirement that they be sent in a particular order -- is there a good reason to require this?

EDIT: just saw @sipa's response in bitcoin/bitcoin#8393. I'm fine with leaving this requirement in.

sdaftuar commented at 5:39 PM on August 4, 2016: member

I have one more observation, aside from what I mentioned above regarding the strict ordering of version messages.

BIP 152 isn't clear on how getdata messages for MSG_CMPCT_BLOCK should be handled if the peer requesting the compact block hasn't sent us a sendcmpct message. The BIP prohibits requesting a compact block before receiving a sendcmpct, but there's no similar prohibition in the other direction. However, if your peer hasn't sent you a sendcmpct, then you don't know what version to use for the response.

The natural thing to do would be to fall through to the next requirement in the BIP, which is that if you don't respond with a compact block, then you must respond with a block. However post-segwit, there's no mechanism to figure out whether the block should be with or without witness.

I propose that the BIP be updated to indicate that nodes either SHOULD or MUST not respond to a getdata(MSG_CMPCT_BLOCK) if the requestor never sent a sendcmpct message to begin with (as there's no way to know what version to use). I think then it should be pretty safe for the fallback-to-sending-a-block code to also use the information from the negotiated compact block version to determine whether to include witnesses. @TheBlueMatt @sipa Thoughts?

sipa force-pushed on Aug 5, 2016

sipa commented at 11:59 PM on August 5, 2016: member

@sdaftuar Addressed comments, I hope.

sipa commented at 9:08 PM on August 15, 2016: member

Ping @sdaftuar @TheBlueMatt ?

sdaftuar commented at 1:37 PM on August 18, 2016: member

@sipa Looks good to me, thanks!

TheBlueMatt commented at 2:02 AM on August 22, 2016: contributor

Upon thinking more, I think my versioing proposal was very ill-conceived. "sendcmpct" has two meanings - both "send me this version of unsolicited compact blocks/send me this version of compact blocks when I request them" and "I can send you this version of compact blocks". It is hard to read into it exactly what version of compact block will be sent to you in response to your request for a compact block. We could tie the two together explicitly and make clear that you shouldnt request compact blocks until you have both send your own sendcmpct and received one, at which point you know that the version they will be sending you is the version you requested last which they also had in one of their sendcmpct messages. Otherwise we need a way to tell the two cmpctblock messages apart (could use a different message name, or a different encoding).

sipa commented at 12:35 PM on August 31, 2016: member

@TheBlueMatt Yes, I was realizing that too. I don't think it's a problem at this point, but it complicates reasoning a bit.

Right now, there are two ways through which the sending of compact blocks is requested: one through the bool in the sendcmpct and the other is through a getdata CMPCTBLOCK. As long as you wait until the exchange of version messages has completed before sending either of those, combined with the fact that you send multiple sendcmpcts for different versions in increasing order, it's always well defined what is being asked for.

My suggestion would be to keep things as-is now, but for a future extension, we introduce an explicit sendcmpctack with version number, and a third one sendcmpctdirect or so to request unsollicited blocks using compact blocks. At that point, it becomes illegal to send a getdata CMPCTBLOCK or sendcmpctdirect before the sendcmpct-sendcmpctack completed, and it's always well-defined.

TheBlueMatt commented at 2:14 PM on August 31, 2016: contributor

Its well-defined but not well-defined in the spec right now. At least we need to specify what, exactly, a sendcmpct is indicating to the other side, which isnt particularly well-defined, nor how you should select version for different directions, etc.

I can take a crack at wording if you prefer.

sipa commented at 2:31 PM on August 31, 2016: member

I can take a crack at wording if you prefer.

Please do!

TheBlueMatt commented at 9:12 PM on September 5, 2016: contributor

Proposed version negotiation semantics: https://github.com/TheBlueMatt/bips/commit/7059fd119f779cd87c4c44fa16ff98e080be5181

Note that I think these might actually need some slight tweaks to the implementation, but provide better features than I thought they would, sorry about that.

TheBlueMatt commented at 9:13 PM on September 5, 2016: contributor

That suggestion codifies that ping/pong serializes p2p messages with sendcmpct messages at startup, which I think is perfectly reasonable, but if we decide against it a cmpctverack or so can easily be added instead.

Version 2 sendcmpct for integration of segwit with CB 316d4f32a0

Add version negotiation details 367eade6e8

sipa force-pushed on Sep 6, 2016

sipa commented at 11:15 AM on September 6, 2016: member

Cherry-picked @TheBlueMatt's suggestions.

TheBlueMatt commented at 3:09 PM on September 8, 2016: contributor

I added a few more commits to https://github.com/bitcoin/bips/compare/master...TheBlueMatt:segwitcb. The first two clarify some things and add an example. The only change is that priority order is now highest-priority-first instead of highest-priority-last, which simplifies implementation somewhat.

The last commit changes the protocol entirely, adding a cmpctack message. This has the advantage that you could implement receiving of some version of compactlocks without implementing sending that encoding, as well as simplifying the protocol slightly (instead of having to check if the current protocol version is higher-priority according to your probably-compile-time list of supported version you know which version you're using directly from the ack message) at the expensee of complicating the implementation somewhat (now you have to add support for another message type and special-case version 1). The last commit is definitely not worth it if we dont anticipate adding more than one or so more versions, but might be worth it if we anticipate compact blocks version 4, 5, 6 at some point. I'll bring this up in the IRC meeting later today.

in bip-0152.mediawiki:None in 367eade6e8 outdated

107 | @@ -108,9 +108,10 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
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 | +# 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. See Protocol Versioning section, below, for more info on the specifics of the version-negotiation mechanics.
113 | # Nodes SHOULD check for a protocol version of >= 70014 before sending sendcmpct messages.
114 | # Nodes MUST NOT send a request for a MSG_CMPCT_BLOCK object to a peer before having received a sendcmpct message from that peer.
115 | +# Nodes MUST NOT request a MSG_CMPCT_BLOCK object before having sent all sendcmpct messages to that peer which they intend to send, as the peer cannot know what version protocol to use in the response.

luke-jr commented at 8:21 PM on September 15, 2016:

Should be combined with previous line.

TheBlueMatt commented at 1:24 AM on September 16, 2016:

Wait, why?

luke-jr commented at 6:28 AM on September 16, 2016:

Because they're both setting the conditions for requesting a compact block?

in bip-0152.mediawiki:None in 367eade6e8 outdated

 136 | @@ -136,7 +137,23 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 137 |  ## For each short transaction ID from the original cmpctblock, in order, find the corresponding transaction either from the blocktxn message or from other sources and place it in the first available position in the block.
 138 |  # Once the block has been reconstructed, it shall be processed as normal, keeping in mind that short transaction IDs are expected to occasionally collide, and that nodes MUST NOT be penalized for such collisions, wherever they appear.
 139 |  
 140 | -===Implementation Notes===
 141 | +==Protocol Versioning==
 142 | +# The protocol version negotiation allows two nodes to agree on the version of compact blocks which they will exchange. As it is only in a single field, it does not allow a node to support a specific version in only one direction (sending or receiving).
 143 | +# Upon connection establishment, a node SHOULD send a burst of sendcmpct messages containing every version of compact block encodings for which they are willing to support sending cmpctblock and blocktxn messages, and receiving getblocktxn messages. These messages SHOULD be ordered in the order of the priority which the node wishes to receive cmpctblock/blocktxn messages, with the highest-priority version sendcmpct message sent last.
 144 | +# The encoding version used to send a cmpctblock or blocktxn message or to receive a getblocktxn message MUST be the second integer (version number) in the most recent sendcmpct message received for which a sendcmpct message with the same version number was sent.

luke-jr commented at 8:22 PM on September 15, 2016:

This sounds confusing. @sipa says it is outdated as well.

TheBlueMatt commented at 1:26 AM on September 16, 2016:

You want to be reviewing as of commit af6330a573ad8c452ae2044c0f0e84c64d7d4124, I believe. Still, the version there has pretty much the same text. Any suggestions to clarify?

luke-jr commented at 6:31 AM on September 16, 2016:

I would try splitting it into two sentences... or maybe "The encoding version used for sending compact blocks is determined by the union of those supported by both nodes, specifically the most recent one received from the peer."

sipa commented at 5:46 PM on September 19, 2016:

Oops, I forgot that @TheBlueMatt had proposed changes which weren't included yet. Fixed now.

in bip-0152.mediawiki:None in 367eade6e8 outdated

 136 | @@ -136,7 +137,23 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 137 |  ## For each short transaction ID from the original cmpctblock, in order, find the corresponding transaction either from the blocktxn message or from other sources and place it in the first available position in the block.
 138 |  # Once the block has been reconstructed, it shall be processed as normal, keeping in mind that short transaction IDs are expected to occasionally collide, and that nodes MUST NOT be penalized for such collisions, wherever they appear.
 139 |  
 140 | -===Implementation Notes===
 141 | +==Protocol Versioning==
 142 | +# The protocol version negotiation allows two nodes to agree on the version of compact blocks which they will exchange. As it is only in a single field, it does not allow a node to support a specific version in only one direction (sending or receiving).
 143 | +# Upon connection establishment, a node SHOULD send a burst of sendcmpct messages containing every version of compact block encodings for which they are willing to support sending cmpctblock and blocktxn messages, and receiving getblocktxn messages. These messages SHOULD be ordered in the order of the priority which the node wishes to receive cmpctblock/blocktxn messages, with the highest-priority version sendcmpct message sent last.
 144 | +# The encoding version used to send a cmpctblock or blocktxn message or to receive a getblocktxn message MUST be the second integer (version number) in the most recent sendcmpct message received for which a sendcmpct message with the same version number was sent.
 145 | +# Nodes MUST NOT send a sendcmpct message which contains a version number other than the version number which has been negotiated for receiving cmpctblock/blocktxn messages after sending a request for a MSG_CMPCT_BLOCK object, sending a cmpctblock, getblocktxn, blocktxn, or pong message.

luke-jr commented at 8:23 PM on September 15, 2016:

This is also confusing. Maybe start the sentence with "After"?

TheBlueMatt commented at 1:27 AM on September 16, 2016:

Are you suggestiong just flipping the sentence? I find that to be slightly more confusing.

luke-jr commented at 6:33 AM on September 16, 2016:

Yes, it is very unclear how to parse this current sentence.

in bip-0152.mediawiki:None in 367eade6e8 outdated

 141 | +==Protocol Versioning==
 142 | +# The protocol version negotiation allows two nodes to agree on the version of compact blocks which they will exchange. As it is only in a single field, it does not allow a node to support a specific version in only one direction (sending or receiving).
 143 | +# Upon connection establishment, a node SHOULD send a burst of sendcmpct messages containing every version of compact block encodings for which they are willing to support sending cmpctblock and blocktxn messages, and receiving getblocktxn messages. These messages SHOULD be ordered in the order of the priority which the node wishes to receive cmpctblock/blocktxn messages, with the highest-priority version sendcmpct message sent last.
 144 | +# The encoding version used to send a cmpctblock or blocktxn message or to receive a getblocktxn message MUST be the second integer (version number) in the most recent sendcmpct message received for which a sendcmpct message with the same version number was sent.
 145 | +# Nodes MUST NOT send a sendcmpct message which contains a version number other than the version number which has been negotiated for receiving cmpctblock/blocktxn messages after sending a request for a MSG_CMPCT_BLOCK object, sending a cmpctblock, getblocktxn, blocktxn, or pong message.
 146 | +# Nodes MUST NOT set the first integer (boolean) value in sendcmpct messages to 1 in any sendcmpct message prior to the last sendcmpct message which contains a novel second integer (version number).

luke-jr commented at 8:27 PM on September 15, 2016:

This is also confusing. So all sendcmpct messages will have non-1 for the first integer, except for the final such message?

TheBlueMatt commented at 1:28 AM on September 16, 2016:

This line is removed in the changes I proposed sipa include.

instagibbs commented at 1:58 PM on September 19, 2016: member

is this up to date with the code PR?

TheBlueMatt commented at 3:32 PM on September 19, 2016: contributor

My currently proposed version (which I believe is up to date with the code) is https://github.com/TheBlueMatt/bips/blob/af6330a573ad8c452ae2044c0f0e84c64d7d4124/bip-0152.mediawiki

instagibbs commented at 5:38 PM on September 19, 2016: member

~~@TheBlueMatt (can't seem to comment there) might want to mention up front that the Protocol Versioning is all related to version 2+. As-is it kind of blends together.~~

Switch priority order to highest-first and add sample negotiation a380daff16

Fix message type bca0dfb3b9

Specify which block encoding to use in the fallback block message 430bf9f235

sipa commented at 5:47 PM on September 19, 2016: member

Included some commits from @TheBlueMatt's branch.

instagibbs commented at 5:51 PM on September 19, 2016: member

Oh I'm commenting on an out-of-date version, nevermind.

in bip-0152.mediawiki:None in 430bf9f235 outdated

 136 | @@ -136,7 +137,31 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 137 |  ## For each short transaction ID from the original cmpctblock, in order, find the corresponding transaction either from the blocktxn message or from other sources and place it in the first available position in the block.
 138 |  # Once the block has been reconstructed, it shall be processed as normal, keeping in mind that short transaction IDs are expected to occasionally collide, and that nodes MUST NOT be penalized for such collisions, wherever they appear.
 139 |  
 140 | -===Implementation Notes===
 141 | +==Protocol Versioning==
 142 | +# The protocol version negotiation allows two nodes to agree on the version of compact blocks which they will exchange. As it is only in a single field, it does not allow a node to support a specific version in only one direction (sending or receiving).

instagibbs commented at 6:54 PM on September 20, 2016:

/version/versions? Each node can request different versions first that both can support.

TheBlueMatt commented at 8:21 PM on September 21, 2016:

ACK, @sipa you want to fix the second version in the line to versions?

in bip-0152.mediawiki:None in 430bf9f235 outdated

 147 | +# Thus, if a node wishes to determine exactly which version of compact blocks will be used before requesting a compact block object, it must send all of its sendcmpct version announcements, followed by a ping, and wait for the pong response to ensure it has received all sendcmpctblock version announcement messages from the remote peer. Nodes can, obviously, however, determine that the version used will be at least a certain version (in their priority order) after having received a sendcmpct message from the remote peer containing that version as the second integer.
 148 | +
 149 | +===Sample Version Implementation===
 150 | +# By way of example, an implementation of the above protocol might look like the following.
 151 | +# Upon exchanging version/verack messages, a node immediately sends its list of sendcmpct announcements to the other side, with the version which it wants to receive sent first.
 152 | +# Upon receiving the first sendcmpct announcement with a protocol version which is understood from the remote peer, a node will "lock in" the compact block encoding version which will be used to encode compact blocks to that peer.

instagibbs commented at 7:00 PM on September 20, 2016:

Perhaps add:

The node then sets the current receive-protocol-version in use on the connection as that version, and uses it to decode new compact block messages.

And on the following line:

/Upon receiving a sendcmpct announcement/Upon receiving subsequent sendcmpct announcements/

Makes it much easier to parse the meaning.

btcdrak commented at 8:35 PM on September 20, 2016:

Yes, that's better.

TheBlueMatt commented at 8:24 PM on September 21, 2016:

Seems reasonable to me, though maybe make it three lines then, as receiving and sending versions have logically distinct behavior.

Fix a few nits suggested by @instagibbs 78cbaca940

sipa commented at 2:53 AM on September 28, 2016: member

@instagibbs Added a commit to incorporate your suggestions.

in bip-0152.mediawiki:None in 78cbaca940

 148 | @@ -149,7 +149,8 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 149 |  # By way of example, an implementation of the above protocol might look like the following.
 150 |  # Upon exchanging version/verack messages, a node immediately sends its list of sendcmpct announcements to the other side, with the version which it wants to receive sent first.
 151 |  # Upon receiving the first sendcmpct announcement with a protocol version which is understood from the remote peer, a node will "lock in" the compact block encoding version which will be used to encode compact blocks to that peer.
 152 | -# Upon receiving a sendcmpct announcement with a protocol version which is understood from the remote peer, a node will check if that protocol version is higher-receive-priority than the current receive-protocol-version in use on the connection, and switch to that version for decoding new compact block messages received.
 153 | +# The node then sets the current receive-protocol-version in use on the connection as that version, and uses it to decode new compact block messages.

TheBlueMatt commented at 7:04 PM on September 28, 2016:

s/as/to/

in bip-0152.mediawiki:None in 78cbaca940

 148 | @@ -149,7 +149,8 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 149 |  # By way of example, an implementation of the above protocol might look like the following.
 150 |  # Upon exchanging version/verack messages, a node immediately sends its list of sendcmpct announcements to the other side, with the version which it wants to receive sent first.
 151 |  # Upon receiving the first sendcmpct announcement with a protocol version which is understood from the remote peer, a node will "lock in" the compact block encoding version which will be used to encode compact blocks to that peer.
 152 | -# Upon receiving a sendcmpct announcement with a protocol version which is understood from the remote peer, a node will check if that protocol version is higher-receive-priority than the current receive-protocol-version in use on the connection, and switch to that version for decoding new compact block messages received.
 153 | +# The node then sets the current receive-protocol-version in use on the connection as that version, and uses it to decode new compact block messages.
 154 | +# Upon receiving subsequent sendcmpct announcements with a protocol version which is understood from the remote peer, a node will check if that protocol version is higher-receive-priority than the current receive-protocol-version in use on the connection, and switch to that version for decoding new compact block messages received.

TheBlueMatt commented at 7:05 PM on September 28, 2016:

s/which is understood from the remote peer,/which is understood from the remote peer (ie which has been announced),/

petertodd commented at 8:08 AM on October 10, 2016: contributor

utACK https://github.com/bitcoin/bips/pull/423/commits/78cbaca9408ea03470379479b93592b75f9ddc0f

jnewbery cross-referenced this on Oct 11, 2016 from issue [WIP] clarify BIP152 sendcmpct message exchange by jnewbery

TheBlueMatt cross-referenced this on Oct 14, 2016 from issue SegWit Compact Blocks by TheBlueMatt

luke-jr merged this on Oct 14, 2016

luke-jr closed this on Oct 14, 2016

naumenkogs cross-referenced this on Mar 20, 2020 from issue A minor issue of SENDCMPCT msg in handshaking process by seungww