diff options
| author | Matt Corallo <git@bluematt.me> | 2016-09-09 09:46:09 -0400 |
|---|---|---|
| committer | Pieter Wuille <pieter.wuille@gmail.com> | 2016-09-19 19:43:38 +0200 |
| commit | 430bf9f2355203c755cb205c6ad5671ffae5e888 (patch) | |
| tree | ecd4f0888f3d60aa0dce546d5199de9a47675d4b /bip-0152.mediawiki | |
| parent | bca0dfb3b981ac2bd35aee566dd33e14886a43f8 (diff) | |
Specify which block encoding to use in the fallback block message
Diffstat (limited to 'bip-0152.mediawiki')
| -rw-r--r-- | bip-0152.mediawiki | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki index 38c402c..1b74306 100644 --- a/bip-0152.mediawiki +++ b/bip-0152.mediawiki @@ -159,6 +159,7 @@ Compact blocks version 2 is almost identical to version 1, but supports segregat # The second integer (version number) inside sendcmpct is 2 instead of 1 (see Protocol Versioning section, above). # 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. # 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. +# Upon receipt of a getdata containing a request for a MSG_CMPCT_BLOCK object for which a cmpctblock message is not sent in response, the block message containing the requested block in non-compact form MUST be encoded with witnesses (as is sent in reply to a MSG_WITNESS_BLOCK getdata) if the protocol version used to encode the cmpctblock message would have been 2, and encoded without witnesses (as is sent in response to a MSG_BLOCK getdata) if the protocol version used to encode the cmpctblock message would have been 1. ==Implementation Notes== # For nodes which have sufficient inbound bandwidth, sending a sendcmpct message with the first integer set to 1 to up to 3 peers is RECOMMENDED. If possible, it is RECOMMENDED that those peers be selected based on their past performance in providing blocks quickly (eg the three peers which provided the highest number of the recent N blocks the quickest), allowing nodes to receive blocks which come from those peers in only 0.5*RTT. |