Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Added robustness to handling the extra field in a Monero block. Use cases for the extra field are: the extra field is changed to add a merge mining hash sub field, the merge mining hash is extracted from the extra field and a Monero block header is verified to contain only one merge mining hash. Parsing an extra field from bytes will always return a valid extra field, even if it does not represent the original extra field. As per Monero consensus rules, a parsing error here will not represent a failure to de-serialize a block, so no need to handle the error in such cases. Having more than one merge mining tag sub field in a block is currently not allowed in the Tari code base, so this is now checked prior to adding the merge mining tag sub field. When adding the merge mining tag sub field, care is taken to not invalidate an existing extra field. If `SubField::Padding(n)` with `n < 255` is the last sub field in the extra field, then appending a new field will always fail deserialization (`ExtraField::try_parse`) - the new field cannot be parsed in that sequence. To circumvent this, we create a new extra field by appending the original extra field sub fields to the merge mining sub field instead.
- Loading branch information