-
-
Notifications
You must be signed in to change notification settings - Fork 655
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
Better display ethereum function calls #69
Comments
I am planning to create a mechanism which will allow a wallet to upload a signed definition of {coin, token, 4byte-function} as a part of signed transaction. We would need to create a signed database where each row is signed by trusted key (public key of this keypair will be part of the Trezor firmware) and TREZOR will parse and check the signature of provided data-row. That way, we would not need to store all coins/tokens/4bytes in the firmware. |
That is a great idea! Please keep me updated on this |
I was looking at the catalog and I am quite disappointed about the very high number of collisions in the space. It is so high, I have my doubts about the usefulness of the feature. How do you solve the collision problem? Do you show all possible options? |
I do not see many collisions - I was expecting more and was surprised that there where not too many collisions. In the 23504 signatures I parse currently there are 3 collisions: aaaaaad1 yycU4() 00000000 get_block_hash_257335279069929(uint256) 0000006e bright_peace(bytes32,bytes) the first 2 (aaaaaad1 and 00000000) sound really constructed and I do not think there is real world impact with these. And even 6e can IMHO be ignored. Wonder where your observation of :
is coming from. |
I looked at |
Do you think it's possible to create something like a curated list where all collisions are resolved? That means no signature collisions (i.e. no entries for 00000000, 0000006e, etc.) and also where you pick the better value for |
hehe - no - don't judge a list by the first entry ;-) I think 00000000 is constructed - some context: |
I think currently it is possible to curate a list that resolves the collisions - but not sure how future compatible this is .. |
I will check how many collisions there will be left if I treat arguments Another question: is |
yes - uint must be resolved to uint256 for the function selector
https://solidity.readthedocs.io/en/develop/abi-spec.html PS: the collisions I showed above are without parameter names - with parameter names there are more - currently I am not sure about the parameter names - hope to be able to discuss this in about 2 weeks in person with @holiman |
linking to #15 |
duplicate? #2874 |
yes, this has more info so i suggest closing #2874 and keeping this one |
Copied from #2874: Every transaction in Ethereum can carry additional input data (e.g. Signature databases:
example
decoded data:
Possible next steps:
|
Step toward solving issue trezor#69 [no changelog]
Step toward solving issue trezor#69 Improved Ethereum address display and changed test cases to use addresses with valid checksums. [no changelog]
Step toward solving issue trezor#69 Improved Ethereum address display and changed test cases to use addresses with valid checksums. Added test for known ERC-20 token (DAI) [no changelog]
Step toward solving issue trezor#69 Improved Ethereum address display and changed test cases to use addresses including letter to see the upper/lower case formatting. Added test for known ERC-20 token (DAI) [no changelog]
Step toward solving issue trezor#69 Improved Ethereum address display and changed test cases to use addresses including letter to see the upper/lower case formatting. Added test for known ERC-20 token (DAI) [no changelog]
Step toward solving issue trezor#69 Improved Ethereum address display and changed test cases to use addresses including letter to see the upper/lower case formatting. Added test for known ERC-20 token (DAI) [no changelog]
Currently when calling ethereum functions you only see the raw hex data - also often you do not see all of it as the hex gets long fast and I was not able to scroll.
The hex can be easily made shorter and more digestible by humans by resolving the function from the 4byte signature - e.g. via https://github.com/ethereum-lists/4bytes and then displaying the function name with parameters. So a really long hex string that might not fit on the trezor and is hard to parse by a human can easily fit on the display of the trezor and better digested by humans.
A problem might be the size of the signature database - I see 2 solutions here:
The text was updated successfully, but these errors were encountered: