Replies: 2 comments 1 reply
-
Nevermind - I can just normalize the input prior to passing it into the encoder! I was misunderstanding how this was being encoded. False alarm. As a matter of API convenience, it might still be worth considering dropping this validation so that those using EIP-1191 can use the |
Beta Was this translation helpful? Give feedback.
1 reply
-
Checksums should be used in user facing code only: showing checksumed addresses that users can copy&paste, and validating user input. As soon as you validate user input you should normalize the address to pass it to libaries. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I would like to use the
AbiCoder
to encode addresses that are not valid EIP-55 checksums. However,AbiCoder
doesn't seem to allow this at the moment. It will automatically validate that any mixed-caseaddress
values are valid address checksums according to EIP-55.This is problematic for me because I'm trying to replace the use of
ethereumjs-abi
with minimal breaking changes, andethereumjs-abi
has no such validation. If I were to accept this requirement that address data must be valid EIP-55 checksums, it would break compatibility with anything that used non-EIP-55 mixed-case address data.Even if it were feasible for us to accept this validation, I'm not sure we'd want to. There are legitimate reasons for wanting to use mixed-case addresses that are not valid address checksums according to EIP-55. For example, address checksums created according to EIP-1191 are currently considered as invalid by the AbiCoder. As such, this validation seems overly restrictive.
Beta Was this translation helpful? Give feedback.
All reactions