This repository has been archived by the owner on Apr 6, 2020. It is now read-only.
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.
Simplify transaction's constructor and EIP155 handling #153
Simplify transaction's constructor and EIP155 handling #153
Changes from all commits
37d43fc
d0c7375
48e4f57
1159315
27b8876
7f08267
1698f75
12f5de3
ed4b695
bba15cb
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.
This is the heaviest code logic change in the PR and I get that this upper part has been moved into
this._implementsEIP155()
but I am not completely sure how to read this conditional simplification.Could you give a short reasoning for the two cases in the
if
clause? That has likely already been done implicitly in your other explanations on the overall changes, but just want to make sure we are not missing anything here.Won't make this a blocker request though.
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.
Actually, they aren't completely equivalent. Not for unsigned transactions.
The decision to use EIP155 or not when signing was previously based on the
_chainId
field, and its complex initialization logic in the constructor. It's simpler now: if the hardfork is spurious dragon or later, we use EIP155.If a transaction is already signed and we are validating it, the logic is the same. It should be in spurious dragon or later and have an EIP155-encoded chain id as
v
to enable EIP155 validation.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.
All
verifySignature()
changes unproblematic, ok.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.
Changes in
sign()
are ok.