Not sure this is the right place to ask this, but I can't find anywhere better.
In the spec, H_t (the transaction tree member of a block header) is specified as type B32, but some of the client test data has left me unsure about it.
I believe that means that the RLP serialization of a B32 should always be an array that's 32 bytes long. Other B32 types, like the parent block hash, seem to behave this way. In that case, if the hash happens to start with a few leading zeros, those leading zeroes must included in the output.
In the case of H_t, though, things seem to be different. When the TreeHash is zero (as it is in the genesis block) then the RLP serialization seems to be a single zero byte, as if were a scalar value. Scalars, of course, are not allowed to have leading zeroes.
I've inferred both of the above claims from my program's interpretation of https://github.com/ethereum/pyethereum/blob/master/tests/blocks.1-1137.poc6.p28.hexdata
So, which is it? Should a writer emit the initial tree state as a one-byte 0 (P), or a 32-bytes of zeroes array (B32)?