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.
AgeManning
commented
4 months ago
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.