Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add robustness to monero block extra field handling #5826

Merged

Conversation

hansieodendaal
Copy link
Contributor

@hansieodendaal hansieodendaal commented Oct 2, 2023

Description

Added robustness to editing and parsing 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 subfield (performed by the merge mining proxy) - NOT applicable, verification is not compromised
  • the merge mining hash is extracted from the extra field (performed by the merge mining proxy) - applicable
  • a Monero block header is verified - NOT applicable, verification is not compromised

As per Monero consensus rules, a parsing error with ExtraField::try_parse(raw_extra_field) will not represent a failure to de-serialize a block, as, upon error, it will just return the subfields that could be read. This means that when a Monero block template is requested by the merge mining proxy it can contain an "invalid" extra field, mainly due to the presence of a variable length SubField::Padding(n) with n < 255 if not the last subfield in the extra field.

If we append the merge mining tag subfield to a valid existing extra field with a variable SubField::Padding(n) with n < 255 as the last subfield, the new extra field cannot be parsed successfully. To circumvent this, we insert the merge mining subfield in front of the subfield array instead of appending it at the rear.

In the event that we have an invalid extra field to start with, we can now parse the extra field and clean it up in the same process before inserting the merge mining subfield. When extracting the merge mining hash we now also ignore an invalid extra field and return the merge mining hash if present.

Having more than one merge mining tag subfield in a block is currently not allowed in the Tari code base, so this is now checked prior to adding the merge mining tag subfield.

Motivation and Context

See above

How Has This Been Tested?

  • Pass existing tests
  • Extended unit test test_duplicate_append_mm_tag to verify that appending more than one merge mining tag will be blocked prior to validating the Monero block header and that header validation will still fail if an additional merge mining tag is present.
  • Added unit test fn test_extra_field_with_parsing_error()

What process can a PR reviewer use to test or verify this change?

Code walkthrough
Familiarize the monero.rs code base

Breaking Changes

  • None
  • Requires data directory on base node to be deleted
  • Requires hard fork
  • Other - Please specify

@ghpbot-tari-project ghpbot-tari-project added P-acks_required Process - Requires more ACKs or utACKs P-reviews_required Process - Requires a review from a lead maintainer to be merged labels Oct 2, 2023
@github-actions
Copy link

github-actions bot commented Oct 2, 2023

Test Results (CI)

1 234 tests   1 234 ✔️  14m 50s ⏱️
     39 suites         0 💤
       1 files           0

Results for commit df1a4ad.

♻️ This comment has been updated with latest results.

@github-actions
Copy link

github-actions bot commented Oct 2, 2023

Test Results (Integration tests)

  2 files  11 suites   22m 45s ⏱️
34 tests 33 ✔️ 0 💤 1
35 runs  34 ✔️ 0 💤 1

For more details on these failures, see this check.

Results for commit df1a4ad.

♻️ This comment has been updated with latest results.

Copy link
Collaborator

@SWvheerden SWvheerden left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good, I just have a nit about the new names.
Adding the word proxy there is only useful and meaningful if you have knowledge of the complete code base. I would prefer adding the specific meaning in the function name or keep as is

base_layer/core/src/proof_of_work/monero_rx/helpers.rs Outdated Show resolved Hide resolved
base_layer/core/src/proof_of_work/monero_rx/helpers.rs Outdated Show resolved Hide resolved
Copy link
Collaborator

@stringhandler stringhandler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DNM

@stringhandler stringhandler dismissed their stale review October 24, 2023 08:24

Concerns have been addressed

Copy link
Collaborator

@stringhandler stringhandler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one more concern

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.
@ghpbot-tari-project ghpbot-tari-project removed the P-reviews_required Process - Requires a review from a lead maintainer to be merged label Nov 6, 2023
@stringhandler stringhandler merged commit 597b9ef into tari-project:development Nov 6, 2023
14 of 15 checks passed
@hansieodendaal hansieodendaal deleted the ho_extra_field branch November 21, 2023 12:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P-acks_required Process - Requires more ACKs or utACKs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants