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.
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
Avoid duplicated signatures when building transactions #4230
base: main
Are you sure you want to change the base?
Avoid duplicated signatures when building transactions #4230
Changes from 4 commits
d4c6e33
aecd5af
650f0b8
7430933
fa5bdbf
29e0c9f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't this code only prove that
public_keys
is a subset ofother_public_keys
? Imagine thatpublic_keys = vec![x, x, y, y]
andother_public_keys = vec![w,x,y,z]
, wouldn't this logic conclude thatpublic_keys
andother_public_keys
are equivalent (because both vectors have the same length and all the elements of the former are contained in the latter)?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right! I tried a different approach in fa5bdbf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it matter that partially equivalent
Authorization
s might not have the same cryptographic hash? Or is this impossible? Could this sort of definition of partial equality confuse people in the future? (This definition seems to be calculated specifically to deal with our duplicate signatures issue (no?), but could be unintuitive in other cases/situations...)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't believe
PartialEq
should guarantee a byte-level match between the two instances but rather a logical equivalence (as I said in the previous question, when safety is critical one should explicitly rely on the digest of the expected instance).I do see your point on this implementation being potentially confusing in other situations: I could try to reintroduce the check on the signer with a more refined logic. My only concern is the case when a multisig signer is expressed as a set of keys in one instance and as an address in the other one: in this case there's no way I can resolve the equivalence without a query to storage (but there's a chance we always express multisig signers as a set of keys which would solve this issue).
An alternative could be to come up with a different function for this comparison and restore the previous implementation of
PartialEq
(net of ignoring the order of the set of keys which I think is a required update regardless).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This definition could work. But it has the implication that if
Authorization::signer
contains the variantSigner::PubKeys
and someone tampers with one of the public keys in that list so thatAuthorization::verify_signature
can no longer pass, thisPartialEq
implementation would still say that the tampered instance is still equal to the original. No? If so, is this desirable?Also, given that this function defines a partial equivalence relation, I guess
false
should be returned in those cases where there is insufficient information to check/conclude equality of the signers? No?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's correct. The representation of the signer being different in the duplicated authorizations I could see on mainnet was the drive to modify this trait implementation. My reasoning was that once we establish the equality of the signature's targets and of the signatures themselves we can safely consider the two
Authorization
s to be the same even if the signers are expressed differently. In case of the signers being straight different (which would cause one of the two instances to fail the signature verification check) I believe we are looking at something else than just equality: I guess one should check the integrity of the sections at the byte level using a digest or similar techniques (see also my answer to your next question since it's related to this one)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't this code only prove that
targets
is a subset ofother_targets
? Imagine thattargets = vec![x, x, y, y]
andother_targets = vec![w,x,y,z]
, wouldn't this logic conclude thattargets
andother_targets
are equivalent (because both vectors have the same length and all the elements of the former are contained in the latter)?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above, thanks!