Skip to content
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

Use ERC-681 #103

Closed
ligi opened this issue Apr 23, 2018 · 5 comments
Closed

Use ERC-681 #103

ligi opened this issue Apr 23, 2018 · 5 comments

Comments

@ligi
Copy link

ligi commented Apr 23, 2018

Hi,

it would be great if the parity-signer could use ERC-681 in this screen:

image

This would help interoperability. If you are really against using ERC-681 here - please at least consider prefixing with 0x. Currently there is no context at all - at least some context would be good ;-)

@maciejhirsz
Copy link
Contributor

maciejhirsz commented Apr 27, 2018

Hi @ligi! Unfortunately I don't think ERC-681 can work for us:

  1. The main reason being that there is no notion of nonce in the url. Signer has to be able to work offline without having to fetch anything from the network.
  2. Since the nonce has to be attached, the QR code with the transaction to sign also requires the address of the sender. This also meshes very well with the UX on both Parity UI and MyCrypto where you craft the transaction in the client with a specific sender address.
  3. Human readability isn't an issue for us at all, and using RLP encoded transaction data gives us two nice properties:
    • We have a stronger guarantee that what is being signed in the signer will match the transaction broadcast to the network.
    • It makes the Signer future proof. If at some point in the future Ethereum adds some field to the transaction, for whatever reason, that the Signer doesn't understand, it can still hash the data and sign it with a proper warning to the user. This is important if you put it on an offline device that is unlikely to get software updates.

I think ERC-681 is great, but I also think it solves a different problem, that is to present a payment request to a device that is online, can fetch things from the blockchain and broadcast a transaction itself. This is not the problem Signer is trying to solve.

I'll close this issue, but I'm also open for a discussion around a new ERC that would standardize the behavior of the Signer. I want to pen a proposal for it, if you have any suggestions on feedback for that feel free to comment here or reach out to me by other means. Cheers!

@maciejhirsz
Copy link
Contributor

Actually, I had to re-read the issue. You mean just using ERC-681 format just for the address QR code? That's quite easy I think, sorry about it :).

@maciejhirsz maciejhirsz reopened this Apr 27, 2018
@ligi
Copy link
Author

ligi commented Apr 27, 2018

@maciejhirsz yes exactly - thanks. Making an ERC for the other QR-code would also be really great - but you are right 681 is not really made for this.

@lexfrl
Copy link
Contributor

lexfrl commented Aug 17, 2018

In the new version account QR code now yields address in the ERC-681 format.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants
@ligi @lexfrl @maciejhirsz @debris and others