`ErrorMessage.error_message` is a leftover from an older version of SSZ
that was able to encode unbounded lists. This is no longer the case -
all collection types now have a fixed upper bound on length.
In general, the `error_message`, just like the `graffitti` field, should
not be interpreted in any particular way except for debugging and vanity
- as such, using the same type, a `Bytes32`, seems reasonable.
An alternative would be `List[byte, 256]` which maybe could be
"reasonably backwards compatible" with whatever clients are are doing
now - depending on how they are dealing with this field type that no
longer exists in the SSZ spec :) It would however be the only place
where `List[uintN, N]` is used in the current spec.
As an exercise, this could be considered a security issue since it's
essentially unbounded and undefined behaviour.
Per the spec, if I request range 5-10, it is permissible for a client to
answer with block 7, 9 - even if the blocks 5, 6 and 8 exist.
Because blocks 7 and 9 cannot be validated as they arrive in such a
request, it seems better to close this gap - this update adds the spec
language that forbids well-behaving clients from answering this way.
There's room for ambiguity as to what `count` means - this clarifies
that it always relates to the slot, and not the number of blocks in the
response which allows clients to request ranges epoch by epoch (for
example) without worrying about overlaps caused by empty slots.
Declares that only a verified block can stop an attestation from being propagated.
This achieves two things:
1. Ensures that clients don't need to scan invalid blocks for attestations and then modify their state based upon them.
1. Disallows "muting" attestations by sending around a junk block with that attestation in it.
There is no need to mention clock disparity when comparing two static slot values (assuming the clock disparity is less than a slot, even then I don't think that's the intention).
