Why is the requested hash size 46 bytes when the transaction hash size is 243 bytes?

Question

In the IRI, the byte size of a request hash is defined as having 46 bytes:

// Configuration.java
public static final String REQ_HASH_SIZE = "46";

However, in Hash.java the hash size of a regular transaction is 243 bytes.

For reference, it will be resolved here and all regular transactions will be defined as having 243 bytes allocated: https://github.com/iotaledger/iri/blob/dev/src/main/java/com/iota/iri/model/Hash.java#L66

Why is the requested hash size 46 bytes when the size of a transmitted transaction hash is 243 bytes?

Doesn't this make it impossible to actually request a transaction?

Answer 1

In one byte: you can encode up to 2 ⁸ values (i.e. 256 values).

When a transaction hash is encoded in a byte[243] , only 3 values within the 256 possibilities are effectively used in each byte. This representation encodes one trit per byte.

When a transaction hash is encoded in a byte[49] : 243 values within the 256 possibilities are used in each byte. This representation encodes 5 trits per byte.

Now, the funny part is that on the main net a valid transaction hash ends with 14 zero trits. So a valid transaction hash contains 229 significant trits (i.e. 243-14). When a valid transaction hash is encoded using the "5 trits per byte" scheme: it requires only 46 bytes (46*5 = 230 and 229<230).

The "one trit per byte" scheme is used for internal representation only. i.e. when it comes to networking (or permanent storage) : the more efficient "5 trits per byte" scheme is used. The REQ_HASH_SIZE parameter is used in the context of networking (it's the size of the transaction to request in a packet).

It is obvious that the "one trit per byte" scheme is not the very efficient regarding memory consumption. (note that in previous version of the IRI it was worse: one trit was encoded in 4 bytes).