discv4: fix definition of node k-bucket distances

[jacktan1]

Restricting i to [0, 256) suggests that max XOR distance representable by a k-bucket is [510, 511] (when i=255). Given that a node public key is 512 bits (64 bytes), this means that if the first bit doesn't match (XOR distance of 512, half of all nodes), it cannot be stored in a k-bucket. Another minor issue is that the i=0 bucket represents distances [0, 1], but a node is only at distance 0 from itself?

I believe the author implied i's range to be (0, 256], with each k-bucket representing distances in [2i-1, 2i]. This way, the i=256 bucket represents distances [511, 512], and the i=1 bucket represents [1, 2].

[fjl]

The distance is XOR on the hashes of public keys, and the hash values are of size 256 bits.

[fjl]

I think the part that says

between 2i and 2i+1

was supposed to mean

between 2^i and 2^(i+1)

because the 'XOR distance' of two node IDs (key hashes) is a 256bit number.

[jacktan1]

Thanks for explaining! Yeah, I had previously mistaken distance and k-bucket number to be the same thing.

In this case, if i is in range [0, 256), then each of the k-buckets would correspond to XOR distances in [2^i, 2^(i+1)) For example:

i=0 ---> [1, 2)
i=1 ---> [2, 4)
...
i=255 ---> [2^255, 2^256)

This makes sense because the largest possible XOR distance is (2^256)-1, and the smallest being 1 (other than the distance from itself).

If my interpretation is correct, I can revise my commit and add it here!

[jacktan1]

Done! Looks ok now?