Add RLP invalid tests for insufficient bytes.

[acoglio]

These new proposed tests are for invalid encodings that do not have enough bytes
for the lengths indicated in the first few bytes.

The following, repeated from (now merged) PR #611, apply here as well:

• I tried running the scripts that check the well-formedness of the tests, but ran into problems and created Issue Test format check failure in just-cloned repo. #611. Also, I'm not sure which other requirements should be fulfilled in order for these new tests to be accepted.
• To provide some assurance, the new proposed tests are rejected by the formally verified RLP decoder available at https://github.com/acl2/acl2/blob/master/books/kestrel/ethereum/rlp/decoding-executable.lisp.

[winsvega]

empty string is 80
https://github.com/ethereum/tests/blob/develop/RLPTests/rlptest.json#L2

[acoglio]

This is a test for the empty encoding, not the empty string. An RLP encoding (i.e. the result of an RLP encoder) is never empty, it always has at least one byte. So if an RLP decoder is presented with the empty sequence of bytes, it should reject it because it is not a valid encoding. This test is meant to cover this case. Perhaps we can use a different name if it causes confusion with the test for encoding the empty string.

[winsvega]

How to tell the difference in the tests?
this PR requires aleth changes

[acoglio]

My understanding is that RLP tests of the form
{"in" : "INVALID", "out" : <encoding>}
are meant to test that whether the decoder rejects <encoding>, while RLP tests of the form
{"in" : <string-or-list>, "out" : <encoding>}
are meant to test whether (1) the encoder produces <encoding> given <string-or-list> and (2) the decoder produces <string-or-list> given <encoding>.

If that's the case, then the test for the empty encoding is
{"in" : "INVALID", "out" : ""}
as above, while the test for the empty string is
{"in" : "", "out" : "80"}
Does this address your question, or have I misunderstood what you were asking?

If aleth accepts the empty encoding, I would argue that it's a bug. The specification of RLP encoding prescribes that both strings and lists start with a byte that describes the type and either the length or the length of the length. So encodings are never empty. If an RLP decoder is given a purported encoding that is empty, it must reject it because it does not encode anything. Do you agree?

[winsvega]

Yes.
I still will have to change aleth to treat empty string in this test as empty byte input

[winsvega]

the empty string is expected to be 80
https://github.com/ethereum/tests/blob/develop/RLPTests/rlptest.json#L2