diff options
author | Luke-Jr <luke_github1@dashjr.org> | 2016-11-03 19:22:27 +0000 |
---|---|---|
committer | GitHub <noreply@github.com> | 2016-11-03 19:22:27 +0000 |
commit | 1286a7793eda14a71f3edbb87772fc872908f665 (patch) | |
tree | ef53579be9f49c4794a8e30b483ce0fcee1a9583 /bip-0152.mediawiki | |
parent | dd4833f171a9708d0b3fd0d1a87ef579624e643c (diff) | |
parent | 30620da93cb7841e7c7f4d8797ebbaeaf02b8e64 (diff) | |
download | bips-1286a7793eda14a71f3edbb87772fc872908f665.tar.xz |
Merge pull request #473 from sdaftuar/bip152-invalid-blocks
[BIP 152] Update compact block BIP for banning behavior
Diffstat (limited to 'bip-0152.mediawiki')
-rw-r--r-- | bip-0152.mediawiki | 4 |
1 files changed, 3 insertions, 1 deletions
diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki index 53ccce6..b1cc468 100644 --- a/bip-0152.mediawiki +++ b/bip-0152.mediawiki @@ -26,7 +26,7 @@ While the goal of this work is explicitly not to reduce block transfer latency, ===Intended Protocol Flow=== <img src=bip-0152/protocol-flow.png></img> -The protocol is intended to be used in two ways, depending on the peers and bandwidth available, as discussed [[#Implementation_Details|later]]. The "high-bandwidth" mode, which nodes may only enable for a few of their peers, is enabled by setting the first boolean to 1 in a <code>sendcmpct</code> message. In this mode, peers send new block announcements with the short transaction IDs already (via a <code>cmpctblock</code> message), possibly even before fully validating the block (as indicated by the grey box in the image above). In some cases no further round-trip is needed, and the receiver can reconstruct the block and process it as usual immediately. When some transactions were not available from local sources (ie mempool), a <code>getblocktxn</code>/<code>blocktxn</code> roundtrip is necessary, bringing the best-case latency to the same 1.5*RTT minimum time that nodes take today, though with significantly less bandwidth usage. +The protocol is intended to be used in two ways, depending on the peers and bandwidth available, as discussed [[#Implementation_Notes|later]]. The "high-bandwidth" mode, which nodes may only enable for a few of their peers, is enabled by setting the first boolean to 1 in a <code>sendcmpct</code> message. In this mode, peers send new block announcements with the short transaction IDs already (via a <code>cmpctblock</code> message), possibly even before fully validating the block (as indicated by the grey box in the image above). In some cases no further round-trip is needed, and the receiver can reconstruct the block and process it as usual immediately. When some transactions were not available from local sources (ie mempool), a <code>getblocktxn</code>/<code>blocktxn</code> roundtrip is necessary, bringing the best-case latency to the same 1.5*RTT minimum time that nodes take today, though with significantly less bandwidth usage. The "low-bandwidth" mode is enabled by setting the first boolean to 0 in a <code>sendcmpct</code> message. In this mode, peers send new block announcements with the usual inv/headers announcements (as per BIP130, and after fully validating the block). The receiving peer may then request the block using a MSG_CMPCT_BLOCK <code>getdata</code> request, which will receive a response of the header and short transaction IDs. In some cases no further round-trip is needed, and the receiver can reconstruct the block and process it as usual, taking the same 1.5*RTT minimum time that nodes take today, though with significantly less bandwidth usage. When some transactions were not available from local sources (ie mempool), a <code>getblocktxn</code>/<code>blocktxn</code> roundtrip is necessary, bringing the latency to at least 2.5*RTT in this case, again with significantly less bandwidth usage than today. Because TCP often exhibits worse transfer latency for larger data sizes (as a multiple of RTT), total latency is expected to be reduced even when the full 2.5*RTT transfer mechanism is used. @@ -183,6 +183,8 @@ Compact blocks version 2 is almost identical to version 1, but supports segregat # Any undefined behavior in this spec may cause failure to transfer block to, peer disconnection by, or self-destruction by the receiving node. A node receiving non-minimally-encoded CompactSize encodings should make a best-effort to eat the sender's cat. +# As high-bandwidth mode permits relaying of CMPCTBLOCK messages prior to full validation (requiring only that the block header is valid before relay), nodes SHOULD NOT ban a peer for announcing a new block with a CMPCTBLOCK message that is invalid, but has a valid header. For avoidance of doubt, nodes SHOULD bump their peer-to-peer protocol version to 70015 or higher to signal that they will not ban or punish a peer for announcing compact blocks prior to full validation, and nodes SHOULD NOT announce a CMPCTBLOCK to a peer with a version number below 70015 before fully validating the block. + ==Justification== ====Protocol design==== |