diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki index cfae0c0d1b..0b5554ec16 100644 --- a/bip-0152.mediawiki +++ b/bip-0152.mediawiki @@ -21,7 +21,7 @@ Thus, decreasing the bandwidth used during block relay is very useful for many i While the goal of this work is explicitly not to reduce block transfer latency, it does, as a side effect reduce block transfer latencies in some rather significant ways. Additionally, this work forms a foundation for future work explicitly targeting low-latency block transfer. -==Specification== +==Specification for version 1== ===Intended Protocol Flow=== @@ -157,6 +157,16 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde # 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. +==Specification for version 2 == + +Compact blocks version 2 is almost identical to version 1, but supports segregated witness transactions (BIP 141 and BIP 144). The changes are: + +* The version number inside sendcmpct is 2 instead of 1. +* 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 serialization specified in BIP 144. +* 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). + +Clients that support version 2 compact blocks can continue to support peers that ask for version 1 support. + ==Justification== ====Protocol design==== @@ -190,6 +200,18 @@ In case 1, we're good. In cases 2, 3, or 4, we request the full transaction beca 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, ...). +====Separate version for segregated witness==== + +The changes to transaction and block relay in BIP 144 introduce separate MSG_FILTERED_ versions of messages in getdata, +allowing a receiver to choose individually where witness data is wanted. + +This method is not useful for compact blocks because `cmpctblock` blocks can be sent unsollicitedly in high-bandwidth +mode, so we need to negotiate at least whether those should include witness data up front. There is little use for a +validating node that only sometimes processes witness data, we may as well use that negotiation for everything and turn +it into a separate protocol version. We also need a means to distinguish different versions of the same transaction with +different witnesses for correct reconstruction, so this also forces us to use wtxids instead of txids for short IDs +everywhere in that case. + ==Backward compatibility== Older clients remain fully compatible and interoperable after this change.