In addition to defining witness structures and requiring commitments in future blocks (BIPxxxx - Consensus segwit BIP), new mechanisms must be defined to allow peers to advertise support for segregated witness and to relay the witness structures and request them from other peers without breaking compatibility with older nodes.
Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeeded, such a transaction would contain no inputs and a single output.
Witness objects can be extended to contain other kinds of witness data not yet specified. This BIP is agnostic to the witness data structure, defined in BIPxxxx (Consensus Segwit BIP), and treats it as an arbitrary byte array.
* '''Rationale for not having an independent message type with its own serialization''': this would require separate "tx" and "block" messages, and all RPC calls operating on raw transactions would need to be duplicated, or need inefficinent or nondeterministic guesswork to know which type is to be used.
* '''Rationale for not using just a single 0x00 byte as marker''': that would lead to empty transactions (no inputs, no outputs, which are used in some tests) to be interpreted as new serialized data.
* '''Rationale for the 0x01 flag byte in between''': this will allow us to easily add more extra non-committed data to transactions (like txouts being spent, ...). It can be interpreted as a bitvector.
New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only
for use in getdata. Inventory messages themselves still use just MSG_TX and MSG_BLOCK,
similar to MSG_FILTERED_BLOCK.
* '''Rationale for not advertizing witnessness in invs''': we don't always use invs anymore (with 'sendheaders' BIP 130), plus it's not useful: implicitly, every transaction and block have a witness, old ones just have empty ones.
MSG_WITNESS_TX getdata requests should use the non-witness serialized hash. The peer shall respond with a tx message, and if the witness structure is nonempty, the witness serialization shall be used.
MSG_WITNESS_BLOCK requests will return a block message with transactions that have a witness using witness serialization.