From a38ee02b65f5efd65a6afcbc00bed1153f1fd1d8 Mon Sep 17 00:00:00 2001 From: Eric Voskuil Date: Sat, 21 Jan 2017 18:33:44 -0800 Subject: [PATCH] Trim quote (unnecessary section). --- Comments:BIP-0152.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Comments:BIP-0152.md b/Comments:BIP-0152.md index b8aaa85..2d6b3ad 100644 --- a/Comments:BIP-0152.md +++ b/Comments:BIP-0152.md @@ -1,6 +1,6 @@ [This section](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#protocol-versioning) part 6: -> 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. +> 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... implies that the Bitcoin P2P protocol generally requires that messages are handled and returned in the order received. This is not reasonable to assume or require, nor is it consistent with behavior of existing nodes. This is especially problematic as it pertains to unrelated protocols, such as between ping-pong and compact blocks. The only ordering assumption is that a response can only follow its request, for message types that are response-only.