Based on what you're saying, it sounds like the wiki should indicate that the transaction count is a single byte then, not a varint?
It is a varint. The varint for zero is a single 0 byte.
When the header is part of the block, it gives the transaction count.
Based on Mike's reply and in the context of the headers message, though, it sounds like there shouldn't be a varint here, just a single zero byte. For zero that comes out to the same thing but I'm trying to understand the correct parsing behavior. If I ever see a non-zero byte in that position what would the correct behavior be? Consider the entire message invalid? Alternatively, if I ignore the difference I'd need to know if I should read just that last byte or if I should try to read it as a varint.
/sigh
You should endeavor to follow Postel's law. In this case, that means (using
RFC2119 notation):
If you are creating a "headers" packet, you
must include a properly coded varint representing the number of transactions that are included in the packet. The number of transactions included
must be zero.
(The only valid encoding for zero is a single octet: 0x00. 0x05 is right out.)If you are reading a "headers" packet, you
must parse that field as a varint. You
should reject any packets that include a non-zero number of transactions. You
may disconnect the peer that sent it, and attempt to publicly shame the authors of that implementation.
Sadly this is one of those cases where it can be easy to get it wrong. It does seem worth investigating whether there was any breakage or behavior changes since 0.3.x days. We have changed CBlock to CBlockHeader and it is entirely conceivable that one might have output the "number of transactions" variable, and another did not. Worth checking.