Revert to raw encoding for non-list entries #80
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The standard convention for signing RLP field data is to do so without the RLP header.
This was a point of confusion in the last version upgrade where no one had really accounted for RLP lists as values. The last version introduced storing the RLP header along with the value when decoding or reading an ENR. This goes against common convention and as a result, the current version cannot read a variety of common ENRs which are implementing fields with non-list RLP types.
This PR reverts the previous changes such that the signature is over RLP data without the header.
However if there is an RLP list object being encoded, we maintain the header. This may not be the common convention with other ENR crates and we might want to consider spec'ing the case of RLP list fields to avoid this confusion between various ENR implementations.