Quote from: kjj on July 31, 2013, 06:52:32 PM

Quote from: pmlyon on July 31, 2013, 06:07:17 PM

Quote from: TierNolan on July 31, 2013, 05:42:14 PM

Quote from: pmlyon on July 31, 2013, 05:12:18 PM

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.