Update EIP-7702: Change MAGIC from 0x05 to 0x1a
#8835
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Ethereum signatures are scoped by signing domain to ensure that when data of different types happens to encode as same byte representation that the resulting hash being signed does not collide across domains. This is typically done by prefixing the data with the domain constant before signing it. The following signing domain constants are defined: - 0x00: Unused for signing, but represents Homestead tx on JSON-RPC - 0x01: EIP-2930 transaction - 0x02: EIP-1559 transaction - 0x03: EIP-4844 transaction - 0x04: EIP-7702 transaction - 0x05: EIP-7702 authorization - 0x19: EIP-191 signed data - 0x80-0xfe: Homestead transaction - 0xff: Reserved by EIP-2718 EIP-2718 aliases transaction types to a subset of the signing domains: - 0x00 represents a tx but is not used for signing. - 0x01-0x04 represent a tx and are used for signing. - 0x05 and 0x19 do not represent a tx but are used for signing. - 0x80-0xfe represent as 0x00 on JSON-RPC but are used for signing. - 0xff is reserved and neither represents a tx nor is used for signing. To improve simplicity as future transaction types are introduced, it may be desirable to group related constants together. For that reason, it is proposed to change the signing domain used for EIP-7702 authorization from `0x05` to `0x1a`. Rationale: - This allows a future transaction type to use type 0x05 sequentially. - If transaction types ever enumerate through 0x18, there is already the problem of 0x19 being in use. Therefore, assigning 0x1a to be used for EIP-7702 authorizations does not introduce additional problems beyond what already will have to be dealt with. - If a new signature algorithm is introduced, one may still do so by setting the upper bits in the signing domain, e.g., 0x40 or 0x20 are still left untouched if 0x1a is assigned. This is an advantage over, e.g., assigning 0x20 to EIP-7702 authorization signatures.
github-actions
bot
added
c-update
Collaborator
File
|
Member
|
This change is okay to me. Generally indifferent on it. |
This was referenced Oct 1, 2024
|
This is a reasonable proposal, is it still being considered? Or has ACD decided against it? |
Member
|
@Thegaram I think it should be proposed to ACD again. Last time I think everyone was mostly indifferent. |
31 tasks
etan-status
added a commit
to etan-status/execution-specs
that referenced
this pull request
Mar 14, 2025
EIP-7702 defines transaction type 0x04, and also uses magic 0x05 for signing authorizations. Discussion about 0x05 is here: - ethereum/EIPs#8835
etan-status
added a commit
to etan-status/execution-specs
that referenced
this pull request
Mar 14, 2025
EIP-7702 defines transaction type 0x04, and also uses magic 0x05 for signing authorizations. Discussion about 0x05 is here: - ethereum/EIPs#8835
SamWilsn
pushed a commit
to ethereum/execution-specs
that referenced
this pull request
Mar 14, 2025
EIP-7702 defines transaction type 0x04, and also uses magic 0x05 for signing authorizations. Discussion about 0x05 is here: - ethereum/EIPs#8835
Shashwat-Nautiyal
pushed a commit
to Shashwat-Nautiyal/execution-specs
that referenced
this pull request
Mar 17, 2025
EIP-7702 defines transaction type 0x04, and also uses magic 0x05 for signing authorizations. Discussion about 0x05 is here: - ethereum/EIPs#8835
|
There has been no activity on this issue for six months. It will be closed in 7 days if there is no new activity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
Contributor
Author
|
This was shipped to mainnet with 0x05. Updated documentation to match reality here: https://github.com/ethereum/execution-specs/tree/forks/osaka/lists/signature-types |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Ethereum signatures are scoped by signing domain to ensure that when data of different types happens to encode as same byte representation that the resulting hash being signed does not collide across domains. This is typically done by prefixing the data with the domain constant before signing it. The following signing domain constants are defined:
EIP-2718 aliases transaction types to a subset of the signing domains:
To improve simplicity as future transaction types are introduced, it may be desirable to group related constants together.
For that reason, it is proposed to change the signing domain used for EIP-7702 authorization from
0x05to0x1a. Rationale: