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

EIP: Payment request URL specification #681

Merged
merged 17 commits into from Feb 21, 2018

Conversation

@nagydani
Contributor

nagydani commented Aug 1, 2017

Payment request URL specification for QR codes, hyperlinks and Android Intents.

@chriseth

This comment has been minimized.

Show comment
Hide comment
@chriseth

chriseth Aug 1, 2017

Contributor

Kindly inviting @ligi @tayvano to this discussion (please also add other wallet developers).

Contributor

chriseth commented Aug 1, 2017

Kindly inviting @ligi @tayvano to this discussion (please also add other wallet developers).

@ligi

This comment has been minimized.

Show comment
Hide comment
@ligi

ligi Aug 1, 2017

Member

Great to see work on a proper specification! Just have 2 concerns currently after reading it initially:

  • the token-transfer method is different from ERC-67 (#67) and as ERC-67 is now already reality out there we would need to do some ugly code to distinguish between ERC-67 and this new approach - I also do not yet see any advantage of this new way of doing things
  • the use of decimals - this way we need to read from contracts to build a transaction. This will be a problem e.g. in offline use-cases (e.g. when building transactions with hardware like wallets - http://walleth.org/2017/06/12/offline-transactions )

This just as some initial thoughts - will think deeper about this later today.

cc @kumavis , @manuelsc , @alexvandesande , @jbenet , @prusnak

Member

ligi commented Aug 1, 2017

Great to see work on a proper specification! Just have 2 concerns currently after reading it initially:

  • the token-transfer method is different from ERC-67 (#67) and as ERC-67 is now already reality out there we would need to do some ugly code to distinguish between ERC-67 and this new approach - I also do not yet see any advantage of this new way of doing things
  • the use of decimals - this way we need to read from contracts to build a transaction. This will be a problem e.g. in offline use-cases (e.g. when building transactions with hardware like wallets - http://walleth.org/2017/06/12/offline-transactions )

This just as some initial thoughts - will think deeper about this later today.

cc @kumavis , @manuelsc , @alexvandesande , @jbenet , @prusnak

@tayvano

This comment has been minimized.

Show comment
Hide comment
@tayvano

tayvano Aug 1, 2017

About a year ago I was all for including data in the URI / QR codes / and so forth.

I'm not as for it, but I think it's a necessary thing to include. I think that it should come with a very, very large red warning to wallets that if you accept data via URI, you need warn the user about the potential downsides to this (e.g. a malicious data string could send all your tokens).

For example, we parse the signed transaction and show users, so sending a standard ERC-20 token would show "sending 1 GNT" over "sending 0 ETH". Some others do not, and show "sending 0 ETH to 0x2342342, sometimes without mention of data. I'm sure there are other potential malicious use-cases that I haven't thought of. The overall userbase today is much different than 6 months ago, 1 year ago. Do not overestimate them. 😉


This is what MEW currently does

This is not saying it's the correct way, simply what we currently use. The data and possible gas limit do not currently work due to ENS revisions, its never been a widely used or promoted feature, so I urge you to take this with a grain of salt as your progress. However, these keys match the raw / unsigned tx (found at bottom of this wall of text), which is a obvious benefit.

  • to = address, preferably prefixed with 0x

  • value = amount of ETH to send in ETH or tokens to send or ETC to send or whatever. (not WEI, IMO. It will lead to more confusion than it's worth and is the input that most UIs take as it is. Keep in mind—as a wallet provider we don't just send this TX off. We parse it, check it, and fill it in for the user, and let them review and look at fields before they take the action to send.) This warrants more thought. I'm pretty up in the air at this point.

  • gas & gasLimit = amount of gas

  • gasPrice = gas price in wei

  • data = hex data

  • chainId = we don't yet include this, but would be smart to do so.

No fields are mandatory. Obviously, not really that useful if you don't include some things, but whatever. You never know what the use case would be. Maybe someone wants to show someone how to send a message to whatever address with data string. Maybe they just want to ensure the user sets a gasPrice of 60 GWEI bc there is a token sale going on. Leave it up to the people providing these QR codes to provide what is necessary.

That said, exchanges / wallets / shops that are building these URIs / QR codes should be discouraged from including any unnecessary data. e.g. in 99% of cases, including gasLimit is overkill and they should opt for the wallet to handle it. 99% of use cases will likely be to and value. For those 1% of cases, having the ability to set the gasLimit will be nice.

Example of a URI that used to work on MEW:

https://www.myetherwallet.com/?to=0x7cB57B5A97eAbe94205C07890BE4c1aD31E486A8&value=1&gaslimit=23000&data=0x5468616e6b20796f752c204d455720322e30


Tokens

There are a few ways to handle this:

  • Provide the token address, token decimals, and token symbol (although the latter may give user a false sense of security, as I could likely send malicious URI with GNT tokens labeled as SHIT tokens)

  • Provide symbol and if the wallet provider has a match, use that. If not, UI throws error.

  • ???

Regardless, should have a key that aligns to value ERC20 that people are strongly encouraged to use when construction token transactions. This will be a pain to handle if we have a different ERC later and we don't do this now.


Contracts

We have been speaking with Matt @ Etherscan about contracts. It would be super freaking cool if there was a was for a user to click a link from Etherscan that had the specific (e.g. one function) loaded up in the user's wallet, where the user could then interact with the write functions in a given contract. In that case:

  • contractAddr — address of contract that you would want to interact with.

  • contractAbi — not the full abi, just the one function, base64'd or something URL-proof in order to eliminate any weirdness.

  • value, gaslimit, and so forth would be as described above.

This is slightly unrelated but figured I would include this anyways. Totally probably best to ignore this :P


Raw / Signed Transactions

And now we are really off topic but if we are going to discuss QR codes, someone speak up if there is a better way than just throwing the full signed / unsigned TX data in a QR code. Potential issues:

  • QR code can be too dense / large if TX has a super long data string (kumavis had recommendation to have QR gif spec. Don't think it's necessary but if anyone is bored, would love to see a POC of this for curiosity's sake.)

  • Malicious third party intercepts unsigned transaction and mutates it in some way. Should be solvable with strong confirmation dialog but worth considering. Checksum?

  • Should we have a label / key in it at least to ID it?

Above 2 maybe as separate EIP to keep this one super focused


Reference: a raw (unsigned) TX:

{ 
"nonce":"0x0174",
"gasPrice":"0x3b9aca00",
"gasLimit":"0x5208", 
"to":"0x7cB57B5A97eAbe94205C07890BE4c1aD31E486A8", 
"value":"0x0de0b6b3a7640000", 
"data":"", 
"chainId":1
}

Final Thoughts

  • I would opt for keeping the same keys across transactions & URIs / QR codes. Consistency = good. From a wallet's perspective, those fields are already very familiar. It would surprise me if an exchange wasn't familiar with this as well.

  • I see no reason for splitting Ethereum, token contract address, and beneficiary addresses in that manner. There is one address you are sending to: the receiver. The token address would only be used in the case you are providing a reference to the token you want sent, in which case you must at least include decimals too.

  • While I understand the rationale for matching whatever is going on in Bitcoin-land, if people are constructing QR codes for ETH, it should be assumed that they have a basic understanding of ETH, namely the core underlying transactions. I would prioritize making this easy and foolproof for wallets and UIs that will be preventing users from sending their life savings away accidentally. I would like to hear others' thoughts on this (Jaxx? Exodus? Coinbase? Shapeshift?). I don't really do Bitcoin at that level).

  • I have no opinion on camelCase vs underscore_all_the_things vs dash-the-fuckers

  • Users do like to touch URI strings and QR codes and construct them themselves in certain cases (e.g. "send me some eth, bro!"). Demanding / expecting these URIs to be in hex / WEI has potential downsides for that reason.

tayvano commented Aug 1, 2017

About a year ago I was all for including data in the URI / QR codes / and so forth.

I'm not as for it, but I think it's a necessary thing to include. I think that it should come with a very, very large red warning to wallets that if you accept data via URI, you need warn the user about the potential downsides to this (e.g. a malicious data string could send all your tokens).

For example, we parse the signed transaction and show users, so sending a standard ERC-20 token would show "sending 1 GNT" over "sending 0 ETH". Some others do not, and show "sending 0 ETH to 0x2342342, sometimes without mention of data. I'm sure there are other potential malicious use-cases that I haven't thought of. The overall userbase today is much different than 6 months ago, 1 year ago. Do not overestimate them. 😉


This is what MEW currently does

This is not saying it's the correct way, simply what we currently use. The data and possible gas limit do not currently work due to ENS revisions, its never been a widely used or promoted feature, so I urge you to take this with a grain of salt as your progress. However, these keys match the raw / unsigned tx (found at bottom of this wall of text), which is a obvious benefit.

  • to = address, preferably prefixed with 0x

  • value = amount of ETH to send in ETH or tokens to send or ETC to send or whatever. (not WEI, IMO. It will lead to more confusion than it's worth and is the input that most UIs take as it is. Keep in mind—as a wallet provider we don't just send this TX off. We parse it, check it, and fill it in for the user, and let them review and look at fields before they take the action to send.) This warrants more thought. I'm pretty up in the air at this point.

  • gas & gasLimit = amount of gas

  • gasPrice = gas price in wei

  • data = hex data

  • chainId = we don't yet include this, but would be smart to do so.

No fields are mandatory. Obviously, not really that useful if you don't include some things, but whatever. You never know what the use case would be. Maybe someone wants to show someone how to send a message to whatever address with data string. Maybe they just want to ensure the user sets a gasPrice of 60 GWEI bc there is a token sale going on. Leave it up to the people providing these QR codes to provide what is necessary.

That said, exchanges / wallets / shops that are building these URIs / QR codes should be discouraged from including any unnecessary data. e.g. in 99% of cases, including gasLimit is overkill and they should opt for the wallet to handle it. 99% of use cases will likely be to and value. For those 1% of cases, having the ability to set the gasLimit will be nice.

Example of a URI that used to work on MEW:

https://www.myetherwallet.com/?to=0x7cB57B5A97eAbe94205C07890BE4c1aD31E486A8&value=1&gaslimit=23000&data=0x5468616e6b20796f752c204d455720322e30


Tokens

There are a few ways to handle this:

  • Provide the token address, token decimals, and token symbol (although the latter may give user a false sense of security, as I could likely send malicious URI with GNT tokens labeled as SHIT tokens)

  • Provide symbol and if the wallet provider has a match, use that. If not, UI throws error.

  • ???

Regardless, should have a key that aligns to value ERC20 that people are strongly encouraged to use when construction token transactions. This will be a pain to handle if we have a different ERC later and we don't do this now.


Contracts

We have been speaking with Matt @ Etherscan about contracts. It would be super freaking cool if there was a was for a user to click a link from Etherscan that had the specific (e.g. one function) loaded up in the user's wallet, where the user could then interact with the write functions in a given contract. In that case:

  • contractAddr — address of contract that you would want to interact with.

  • contractAbi — not the full abi, just the one function, base64'd or something URL-proof in order to eliminate any weirdness.

  • value, gaslimit, and so forth would be as described above.

This is slightly unrelated but figured I would include this anyways. Totally probably best to ignore this :P


Raw / Signed Transactions

And now we are really off topic but if we are going to discuss QR codes, someone speak up if there is a better way than just throwing the full signed / unsigned TX data in a QR code. Potential issues:

  • QR code can be too dense / large if TX has a super long data string (kumavis had recommendation to have QR gif spec. Don't think it's necessary but if anyone is bored, would love to see a POC of this for curiosity's sake.)

  • Malicious third party intercepts unsigned transaction and mutates it in some way. Should be solvable with strong confirmation dialog but worth considering. Checksum?

  • Should we have a label / key in it at least to ID it?

Above 2 maybe as separate EIP to keep this one super focused


Reference: a raw (unsigned) TX:

{ 
"nonce":"0x0174",
"gasPrice":"0x3b9aca00",
"gasLimit":"0x5208", 
"to":"0x7cB57B5A97eAbe94205C07890BE4c1aD31E486A8", 
"value":"0x0de0b6b3a7640000", 
"data":"", 
"chainId":1
}

Final Thoughts

  • I would opt for keeping the same keys across transactions & URIs / QR codes. Consistency = good. From a wallet's perspective, those fields are already very familiar. It would surprise me if an exchange wasn't familiar with this as well.

  • I see no reason for splitting Ethereum, token contract address, and beneficiary addresses in that manner. There is one address you are sending to: the receiver. The token address would only be used in the case you are providing a reference to the token you want sent, in which case you must at least include decimals too.

  • While I understand the rationale for matching whatever is going on in Bitcoin-land, if people are constructing QR codes for ETH, it should be assumed that they have a basic understanding of ETH, namely the core underlying transactions. I would prioritize making this easy and foolproof for wallets and UIs that will be preventing users from sending their life savings away accidentally. I would like to hear others' thoughts on this (Jaxx? Exodus? Coinbase? Shapeshift?). I don't really do Bitcoin at that level).

  • I have no opinion on camelCase vs underscore_all_the_things vs dash-the-fuckers

  • Users do like to touch URI strings and QR codes and construct them themselves in certain cases (e.g. "send me some eth, bro!"). Demanding / expecting these URIs to be in hex / WEI has potential downsides for that reason.

@prusnak

This comment has been minimized.

Show comment
Hide comment
@prusnak

prusnak Aug 1, 2017

Agree that decimals should be killed with fire :-)

prusnak commented Aug 1, 2017

Agree that decimals should be killed with fire :-)

@axic

This comment has been minimized.

Show comment
Hide comment
@axic

axic Aug 1, 2017

Member

I think it would be nice to require the checksummed address format.

Member

axic commented Aug 1, 2017

I think it would be nice to require the checksummed address format.

Show outdated Hide outdated EIPS/pay_req_url_fmt.md Outdated
@MicahZoltu

This comment has been minimized.

Show comment
Hide comment
@MicahZoltu

MicahZoltu Aug 1, 2017

Contributor

I agree with @tayvano that we shouldn't be striving for bitcoin similarity. I see minimal value in such similarities and it constrains design decisions.

I think if we are going to use ethereum: it should be generic, not specific to token/ETH transfers. Of course, it would support token and ETH transfers but it would also support any arbitrary contract calls just the same. Also, I think long term ERC20 isn't going to stand the test of time (at least I sincerely hope it doesn't) so we shouldn't be designing the ethereum: URL against it.

This means that the pieces of information that should be included are:

  • source address
  • target address
  • attached value
  • method signature being called
  • list of parameters to pass to the method
  • gas
  • gas price

As @tayvano indicated, most of these things will be left out in most calls but I think there is value in allowing the caller to specify any subset of them.

Another thing that I strongly recommend is some form of protocol versioning. While the above list makes sense now, Ethereum is still very young and the set above may not make sense in a year or two. For example, there has been discussion about changing ETH to no longer be special and instead be a traditional token. If this were to go through, then attached value would no longer make sense as a parameter. Similarly, changes may be made to the protocol that allow for new transaction parameters.

A simple means of versioning would be to have the version be the first segment like ethereum:v5/....

Re @tayvano's suggestion to denominate in ETH, not WEI. I quite strongly disagree with this. While it is nice when a URI is semi-readable, the intent is not to make them user friendly, especially when it introduces risk into the system. If values are denominated in ETH then that means many transactions will contain fractional ETH. It is incredibly easy to get the parsing wrong and parse the URI into a double/float and accidentally truncate it! On top of that, the receiving system will need to send that number as WEI anyway so you are just making their life hard. The sending system also probably is using WEI under the hood (at least I hope they are), so both systems are having to convert to/from ETH/WEI and deal with the fact that you need a 300-bit (or something) floating point number to accurately store ETH (and any token with "decimals").

Contributor

MicahZoltu commented Aug 1, 2017

I agree with @tayvano that we shouldn't be striving for bitcoin similarity. I see minimal value in such similarities and it constrains design decisions.

I think if we are going to use ethereum: it should be generic, not specific to token/ETH transfers. Of course, it would support token and ETH transfers but it would also support any arbitrary contract calls just the same. Also, I think long term ERC20 isn't going to stand the test of time (at least I sincerely hope it doesn't) so we shouldn't be designing the ethereum: URL against it.

This means that the pieces of information that should be included are:

  • source address
  • target address
  • attached value
  • method signature being called
  • list of parameters to pass to the method
  • gas
  • gas price

As @tayvano indicated, most of these things will be left out in most calls but I think there is value in allowing the caller to specify any subset of them.

Another thing that I strongly recommend is some form of protocol versioning. While the above list makes sense now, Ethereum is still very young and the set above may not make sense in a year or two. For example, there has been discussion about changing ETH to no longer be special and instead be a traditional token. If this were to go through, then attached value would no longer make sense as a parameter. Similarly, changes may be made to the protocol that allow for new transaction parameters.

A simple means of versioning would be to have the version be the first segment like ethereum:v5/....

Re @tayvano's suggestion to denominate in ETH, not WEI. I quite strongly disagree with this. While it is nice when a URI is semi-readable, the intent is not to make them user friendly, especially when it introduces risk into the system. If values are denominated in ETH then that means many transactions will contain fractional ETH. It is incredibly easy to get the parsing wrong and parse the URI into a double/float and accidentally truncate it! On top of that, the receiving system will need to send that number as WEI anyway so you are just making their life hard. The sending system also probably is using WEI under the hood (at least I hope they are), so both systems are having to convert to/from ETH/WEI and deal with the fact that you need a 300-bit (or something) floating point number to accurately store ETH (and any token with "decimals").

@tayvano

This comment has been minimized.

Show comment
Hide comment
@tayvano

tayvano Aug 1, 2017

After sleeping on it.......

  • WEI not ETH works better for a variety of reasons. I don't necessarily like this, but it removes a lot of unnecessary complexity and bad things

  • ENS support is question as well (especially .eth vs .company.eth etc.

tayvano commented Aug 1, 2017

After sleeping on it.......

  • WEI not ETH works better for a variety of reasons. I don't necessarily like this, but it removes a lot of unnecessary complexity and bad things

  • ENS support is question as well (especially .eth vs .company.eth etc.

@ligi

This comment has been minimized.

Show comment
Hide comment
@ligi

ligi Aug 3, 2017

Member

Really not sure about adding ENS here - and if we really add it here IMHO it should be at least prefixed because:

  • otherwise it is not 100% clear if it is an address or an ENS name in all cases - you could assume that if the length is 40 chars it is an address - but it could also be an ENS name - a prefix would make this clear and remove the need for assumptions like this
  • It is too tightly coupled to ENS and we might end up with other name-services in the future as ENS suffers a serious squatting problem
  • same problem as with decimals: to build a transaction we need to be online to resolve the name to an address - this is a problem for offline/hardware wallet solutions
Member

ligi commented Aug 3, 2017

Really not sure about adding ENS here - and if we really add it here IMHO it should be at least prefixed because:

  • otherwise it is not 100% clear if it is an address or an ENS name in all cases - you could assume that if the length is 40 chars it is an address - but it could also be an ENS name - a prefix would make this clear and remove the need for assumptions like this
  • It is too tightly coupled to ENS and we might end up with other name-services in the future as ENS suffers a serious squatting problem
  • same problem as with decimals: to build a transaction we need to be online to resolve the name to an address - this is a problem for offline/hardware wallet solutions
@nagydani

This comment has been minimized.

Show comment
Hide comment
@nagydani

nagydani Aug 3, 2017

Contributor

I think that this is a higher-level protocol than the one in ERC #67 and it is really unfortunate that they use the same protocol name. I am willing to change it to something else. @fjl proposed ethpay: to which the two objections are that it suggests that payments are in ETH (though it is actually a reference to the blockchain, not its native token) and that not all token transfers are strictly speaking payments. I am still willing to go with ethpay: despite these two objections.

Contributor

nagydani commented Aug 3, 2017

I think that this is a higher-level protocol than the one in ERC #67 and it is really unfortunate that they use the same protocol name. I am willing to change it to something else. @fjl proposed ethpay: to which the two objections are that it suggests that payments are in ETH (though it is actually a reference to the blockchain, not its native token) and that not all token transfers are strictly speaking payments. I am still willing to go with ethpay: despite these two objections.

Daniel A. Nagy
EIP: Explicit reference to ERC #67 added. Protocol part changed to "e…
…thpay" for distinction and compatibility.
Show outdated Hide outdated EIPS/pay_req_url_fmt.md Outdated
@nagydani

This comment has been minimized.

Show comment
Hide comment
@nagydani

nagydani Aug 3, 2017

Contributor

To highlight that the purpose of this URL format is different from that in ERC #67 and to remain compatible with it, I have changed the ethereum protocol name to ethpay as suggested by @fjl . This also implies, that this standard

I am very hesitant to switch to WEI (and atomic units in general) as suggested, because human readability and writability are very important. More important than the offline use case, which should be handled though ERC #67 links, as those also help with gasprice and other low-level stuff, which cannot be decided safely offline anyway.

Contributor

nagydani commented Aug 3, 2017

To highlight that the purpose of this URL format is different from that in ERC #67 and to remain compatible with it, I have changed the ethereum protocol name to ethpay as suggested by @fjl . This also implies, that this standard

I am very hesitant to switch to WEI (and atomic units in general) as suggested, because human readability and writability are very important. More important than the offline use case, which should be handled though ERC #67 links, as those also help with gasprice and other low-level stuff, which cannot be decided safely offline anyway.

@ligi

This comment has been minimized.

Show comment
Hide comment
@ligi

ligi Aug 3, 2017

Member

because human readability and writability are very important.

can you elaborate on why you think these are important in this case. Would also appreciate some use-cases

Member

ligi commented Aug 3, 2017

because human readability and writability are very important.

can you elaborate on why you think these are important in this case. Would also appreciate some use-cases

@nagydani

This comment has been minimized.

Show comment
Hide comment
@nagydani

nagydani Aug 3, 2017

Contributor

@ligi basically, this ERC is to provide the same functionality as BIP21. People write BIP21 links and QR-codes by hand all the time. The standard, most anticipated and most important use case is that the user clicks (scans, etc.) such a link, it brings up their wallet app asking for confirming the payment. In this case, the wallet needs to know about decimals anyway in order to display a meaningful message to the user. Thus, no matter if the value in the URL is in decimal representation or in atomic units, the wallet app needs to have access to the contract to convert between the two.

Contributor

nagydani commented Aug 3, 2017

@ligi basically, this ERC is to provide the same functionality as BIP21. People write BIP21 links and QR-codes by hand all the time. The standard, most anticipated and most important use case is that the user clicks (scans, etc.) such a link, it brings up their wallet app asking for confirming the payment. In this case, the wallet needs to know about decimals anyway in order to display a meaningful message to the user. Thus, no matter if the value in the URL is in decimal representation or in atomic units, the wallet app needs to have access to the contract to convert between the two.

@ligi

This comment has been minimized.

Show comment
Hide comment
@ligi

ligi Aug 3, 2017

Member

People write BIP21 links and QR-codes by hand all the time.

Can you support this claim with data? Would also love the input of @schildbach in this regard.

Member

ligi commented Aug 3, 2017

People write BIP21 links and QR-codes by hand all the time.

Can you support this claim with data? Would also love the input of @schildbach in this regard.

@Arachnid

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Aug 3, 2017

Collaborator

I disagree about wei vs ETH - URIs are supposed to be human readable, and decimal ETH is far more readable for practical purposes. This is not a machine interchange standard, but rather a human one.

otherwise it is not 100% clear if it is an address or an ENS name in all cases - you could assume that if the length is 40 chars it is an address - but it could also be an ENS name - a prefix would make this clear and remove the need for assumptions like this

I promise we'll never issue 42 character TLDs starting with 0x.

It is too tightly coupled to ENS and we might end up with other name-services in the future as ENS suffers a serious squatting problem

You are welcome to invent your own squatting-free name service and then submit a proposal to add support for it to a standard like this.

same problem as with decimals: to build a transaction we need to be online to resolve the name to an address - this is a problem for offline/hardware wallet solutions

I would not expect offline or hardware wallets to parse these URIs themselves, though - they would get a transaction in ready-to-sign form from something online.

Collaborator

Arachnid commented Aug 3, 2017

I disagree about wei vs ETH - URIs are supposed to be human readable, and decimal ETH is far more readable for practical purposes. This is not a machine interchange standard, but rather a human one.

otherwise it is not 100% clear if it is an address or an ENS name in all cases - you could assume that if the length is 40 chars it is an address - but it could also be an ENS name - a prefix would make this clear and remove the need for assumptions like this

I promise we'll never issue 42 character TLDs starting with 0x.

It is too tightly coupled to ENS and we might end up with other name-services in the future as ENS suffers a serious squatting problem

You are welcome to invent your own squatting-free name service and then submit a proposal to add support for it to a standard like this.

same problem as with decimals: to build a transaction we need to be online to resolve the name to an address - this is a problem for offline/hardware wallet solutions

I would not expect offline or hardware wallets to parse these URIs themselves, though - they would get a transaction in ready-to-sign form from something online.

@nagydani

This comment has been minimized.

Show comment
Hide comment
@nagydani

nagydani Aug 3, 2017

Contributor

@tayvano , I disagree with you that using WEI would save complexity and bad things. Please read our discussion with @ligi above; in both cases, the user-facing app will need to do a conversion for which it will need to access the contract in case of token payments. It would, however, make it near-impossible and highly error-prone for human beings to construct payment request URLs, should they require amounts in WEI.

@ligi , I obviously have no data, but I have seen it done many times and regularly do it myself. Whenever I invoice in BTC, I include a bitcoin:... link and a QR code in the email as a courtesy in addition to simply stating my address and the invoiced amount.

Contributor

nagydani commented Aug 3, 2017

@tayvano , I disagree with you that using WEI would save complexity and bad things. Please read our discussion with @ligi above; in both cases, the user-facing app will need to do a conversion for which it will need to access the contract in case of token payments. It would, however, make it near-impossible and highly error-prone for human beings to construct payment request URLs, should they require amounts in WEI.

@ligi , I obviously have no data, but I have seen it done many times and regularly do it myself. Whenever I invoice in BTC, I include a bitcoin:... link and a QR code in the email as a courtesy in addition to simply stating my address and the invoiced amount.

@prusnak

This comment has been minimized.

Show comment
Hide comment
@prusnak

prusnak Aug 3, 2017

If you really NEED to include decimal point in the URI, please include decimals as well (so the offline signer, does not need to interact with blockchain to get the correct value for a token).

Something like the following could work:

?amount=1.2345&decimals=18

prusnak commented Aug 3, 2017

If you really NEED to include decimal point in the URI, please include decimals as well (so the offline signer, does not need to interact with blockchain to get the correct value for a token).

Something like the following could work:

?amount=1.2345&decimals=18

@ligi

This comment has been minimized.

Show comment
Hide comment
@ligi

ligi Aug 3, 2017

Member

You are welcome to invent your own squatting-free name service and then submit a proposal to add support for it to a standard like this.

OK - so we need the prefix - I don't think it will be me as I am busy with other projects currently - but we need an upgrade path here - and this is what I was stating in the original comment

I promise we'll never issue 42 character TLDs starting with 0x.

Is there anything in code that prevents it?

EDIT: with registrar.ens.domains I am at least able to spend money on a domain that is a valid address (https://etherscan.io/tx/0x5262ed605bb4c924ae627b38b26db4066c097d346f1d262d2e97011858bf5b65) - but then it is just buggy - I don't see the bids anymore and the 0.01ETH are just wasted - the ens-bids-backup does not contain the bid ..
Let's just leave ENS out - or at least prefix it

Member

ligi commented Aug 3, 2017

You are welcome to invent your own squatting-free name service and then submit a proposal to add support for it to a standard like this.

OK - so we need the prefix - I don't think it will be me as I am busy with other projects currently - but we need an upgrade path here - and this is what I was stating in the original comment

I promise we'll never issue 42 character TLDs starting with 0x.

Is there anything in code that prevents it?

EDIT: with registrar.ens.domains I am at least able to spend money on a domain that is a valid address (https://etherscan.io/tx/0x5262ed605bb4c924ae627b38b26db4066c097d346f1d262d2e97011858bf5b65) - but then it is just buggy - I don't see the bids anymore and the 0.01ETH are just wasted - the ens-bids-backup does not contain the bid ..
Let's just leave ENS out - or at least prefix it

@tayvano

This comment has been minimized.

Show comment
Hide comment
@tayvano

tayvano Aug 3, 2017

FWIW, MEW doesn't allow any ENSs names to be registered that start with 0x and there are issues with having strings that start with 0x that aren't hex.

Adjusting ENS to address 42 char / 0x is relatively easy thing to do. This is not to say that more consideration & discussion isn't warranted, but let's eliminate the technical feasibility from the discussion.

ENS meetup / panels / discussions are on Aug 11-14.

I am for moving discussion of ENS to new EIP in order to keep it focused & moving.

tayvano commented Aug 3, 2017

FWIW, MEW doesn't allow any ENSs names to be registered that start with 0x and there are issues with having strings that start with 0x that aren't hex.

Adjusting ENS to address 42 char / 0x is relatively easy thing to do. This is not to say that more consideration & discussion isn't warranted, but let's eliminate the technical feasibility from the discussion.

ENS meetup / panels / discussions are on Aug 11-14.

I am for moving discussion of ENS to new EIP in order to keep it focused & moving.

@MicahZoltu

This comment has been minimized.

Show comment
Hide comment
@MicahZoltu

MicahZoltu Aug 3, 2017

Contributor

URIs are supposed to be human readable, and decimal ETH is far more readable for practical purposes. This is not a machine interchange standard, but rather a human one.

@Arachnid I don't agree with this assessment (and this is probably the source of disagreement in general on this topic). The purpose of a URI is to make it easy for application A to talk to application B. If they are human readable that is a nice advantage, but if you look at most URIs on the internet, that isn't a primary concern. Even Google's URIs which include the URI encoded query string in them also include a bunch of crap that I still don't fully understand even though I am often fiddling with them manually. IMO, the purpose of this spec (and #67) is to facilitate data transfer between applications. I do not think we should be targeting manually constructed URIs or human read URIs. It is the job of the tool on either end to present the data to the user in a user friendly way.

In the case of eth vs attoeth, I have personally seen too many errors around parsing values into JavaScript doubles to be comfortable with anything other than hex encoded values. Just the other day some ICO lost millions of dollars due to this bug (don't remember the name). If the values are hex encoded they aren't human readable, and its much easier to encode/parse a 256-bit hex integer than a 300-bit (depending on decided mantisa size) floating point value.

Contributor

MicahZoltu commented Aug 3, 2017

URIs are supposed to be human readable, and decimal ETH is far more readable for practical purposes. This is not a machine interchange standard, but rather a human one.

@Arachnid I don't agree with this assessment (and this is probably the source of disagreement in general on this topic). The purpose of a URI is to make it easy for application A to talk to application B. If they are human readable that is a nice advantage, but if you look at most URIs on the internet, that isn't a primary concern. Even Google's URIs which include the URI encoded query string in them also include a bunch of crap that I still don't fully understand even though I am often fiddling with them manually. IMO, the purpose of this spec (and #67) is to facilitate data transfer between applications. I do not think we should be targeting manually constructed URIs or human read URIs. It is the job of the tool on either end to present the data to the user in a user friendly way.

In the case of eth vs attoeth, I have personally seen too many errors around parsing values into JavaScript doubles to be comfortable with anything other than hex encoded values. Just the other day some ICO lost millions of dollars due to this bug (don't remember the name). If the values are hex encoded they aren't human readable, and its much easier to encode/parse a 256-bit hex integer than a 300-bit (depending on decided mantisa size) floating point value.

@nagydani

This comment has been minimized.

Show comment
Hide comment
@nagydani

nagydani Aug 3, 2017

Contributor

@MicahZoltu , I disagree. What you write is true about ERC #67 , but not this ERC. It is important that payment requests be readable and writeable by humans; we know that much from Bitcoin (BIP21).

Contributor

nagydani commented Aug 3, 2017

@MicahZoltu , I disagree. What you write is true about ERC #67 , but not this ERC. It is important that payment requests be readable and writeable by humans; we know that much from Bitcoin (BIP21).

@ligi

This comment has been minimized.

Show comment
Hide comment
@ligi

ligi Aug 3, 2017

Member

we know that much from Bitcoin

no - you assume this and I have not yet seen any data that supports this.
Also in your introductional post you state it is for also for Android Intents - and they are never really hand-crafted or parsed - same goes for QR codes you mention there ..

Member

ligi commented Aug 3, 2017

we know that much from Bitcoin

no - you assume this and I have not yet seen any data that supports this.
Also in your introductional post you state it is for also for Android Intents - and they are never really hand-crafted or parsed - same goes for QR codes you mention there ..

@nagydani

This comment has been minimized.

Show comment
Hide comment
@nagydani

nagydani Aug 3, 2017

Contributor

@ligi if I see something left and right, I do not need "data" to prove that it occurs sufficiently frequently. Android intents get fired automagically upon opening URLs, and those URLs are often hand-crafted in case of BTC payment requests (in emails and chats, for example). Generating a QR-code from a hand-crafted URL is also something for which there are many on- and offline tools. I really doubt that everybody except me uses specialized bitcoin QR code generators instead of simply hand-crafting a URL and using whatever QR code generator is at hand.

Contributor

nagydani commented Aug 3, 2017

@ligi if I see something left and right, I do not need "data" to prove that it occurs sufficiently frequently. Android intents get fired automagically upon opening URLs, and those URLs are often hand-crafted in case of BTC payment requests (in emails and chats, for example). Generating a QR-code from a hand-crafted URL is also something for which there are many on- and offline tools. I really doubt that everybody except me uses specialized bitcoin QR code generators instead of simply hand-crafting a URL and using whatever QR code generator is at hand.

@ligi

This comment has been minimized.

Show comment
Hide comment
@ligi

ligi Aug 3, 2017

Member

I strongly disagree - and I think it all boils down to who you see as the target audience. Everyday humans (who I see as the future target audience for Ethereum and maybe this EIP) will not hand-craft a URL - they will use tools for this. Hand-crafting URLs will only be done by done by tech-savvy people - and I hope we overcome the time where cryptocurrencies are only used by us ..
This is also why I asked for use-cases in the beginning which you just ignored - so here are some that come to my mind:

  • Displaying QR-Codes on POS terminals - if you pay via this QR-Code the cashier hands you out the item you just paid for (no hand-crafted URL)
  • Printing QR-Codes on bills - if you pay via this QR-Code you can just leave e.g. the restaurant (no hand-crafted URL)
  • Requesting money from an Android-App (no hand-crafted URL)
  • Displaying QR-Codes on Vending machines - if you pay via this QR-Code the item is released (no hand-crafted URL)
  • Requesting money from a wallet app (like you see in the last screenshot here: http://walleth.org/2017/05/23/walleth-0.11/) - (no hand-crafted URL)
  • Attaching a QR-Code to an object/venue/.. to collect donations
  • Showing a QR-Code at a door/turnstile - if you pay you get access (no hand-crafted URL)
  • Showing a QR-Code on the info-screen of a ransom-ware - if you pay via this URL your data might get decrypted (no hand-crafted URL)
  • Showing a QR-Code at a Music-Box - so you can choose the music (no hand-crafted URL)
  • Showing a QR-Code with a transaction to be signed by a offline device (like this: http://walleth.org/2017/06/12/offline-transactions) (no hand-crafted URL)
  • Showing a QR-Code in front of a pay-wall - if you pay via this URL you can read the article or view the video (no hand-crafted URL)
  • Showing a QR-Code next to a power-outlet or charging station - if you pay via this URL power is switched on for a certain amount of time (no hand-crafted URL)
  • Showing a QR-Code to convert tokens (e.g. like shapeshift is doing) - (no hand-crafted URL)
  • ..

QR-Code could also be replaced with NFC/Bluetooth solutions - same applies

Member

ligi commented Aug 3, 2017

I strongly disagree - and I think it all boils down to who you see as the target audience. Everyday humans (who I see as the future target audience for Ethereum and maybe this EIP) will not hand-craft a URL - they will use tools for this. Hand-crafting URLs will only be done by done by tech-savvy people - and I hope we overcome the time where cryptocurrencies are only used by us ..
This is also why I asked for use-cases in the beginning which you just ignored - so here are some that come to my mind:

  • Displaying QR-Codes on POS terminals - if you pay via this QR-Code the cashier hands you out the item you just paid for (no hand-crafted URL)
  • Printing QR-Codes on bills - if you pay via this QR-Code you can just leave e.g. the restaurant (no hand-crafted URL)
  • Requesting money from an Android-App (no hand-crafted URL)
  • Displaying QR-Codes on Vending machines - if you pay via this QR-Code the item is released (no hand-crafted URL)
  • Requesting money from a wallet app (like you see in the last screenshot here: http://walleth.org/2017/05/23/walleth-0.11/) - (no hand-crafted URL)
  • Attaching a QR-Code to an object/venue/.. to collect donations
  • Showing a QR-Code at a door/turnstile - if you pay you get access (no hand-crafted URL)
  • Showing a QR-Code on the info-screen of a ransom-ware - if you pay via this URL your data might get decrypted (no hand-crafted URL)
  • Showing a QR-Code at a Music-Box - so you can choose the music (no hand-crafted URL)
  • Showing a QR-Code with a transaction to be signed by a offline device (like this: http://walleth.org/2017/06/12/offline-transactions) (no hand-crafted URL)
  • Showing a QR-Code in front of a pay-wall - if you pay via this URL you can read the article or view the video (no hand-crafted URL)
  • Showing a QR-Code next to a power-outlet or charging station - if you pay via this URL power is switched on for a certain amount of time (no hand-crafted URL)
  • Showing a QR-Code to convert tokens (e.g. like shapeshift is doing) - (no hand-crafted URL)
  • ..

QR-Code could also be replaced with NFC/Bluetooth solutions - same applies

@skywinder skywinder referenced this pull request Apr 10, 2018

Open

Support EIP67 and related standarts #9

0 of 3 tasks complete
@captainreptile

This comment has been minimized.

Show comment
Hide comment
@captainreptile

captainreptile May 3, 2018

I was reading 2 threads starting from Feb 2016, and still dont get it
What is the "standard" address for QR codes?

Below is not recognized when scanning with blockchain.info wallet:
ethereum:$PayToAddr?value=$EtherAmountToPay

captainreptile commented May 3, 2018

I was reading 2 threads starting from Feb 2016, and still dont get it
What is the "standard" address for QR codes?

Below is not recognized when scanning with blockchain.info wallet:
ethereum:$PayToAddr?value=$EtherAmountToPay

@ligi

This comment has been minimized.

Show comment
Hide comment
@ligi

ligi May 3, 2018

Member

you don't have to read long threads - this should be all you need: https://eips.ethereum.org/EIPS/eip-681
Not sure if blockchain.info supports ERC-681 - could not even try - seems to require a login?

ethereum:$PayToAddr?value=$EtherAmountToPay

looks correct - but maybe addr or amount are wrongly formatted - can you make a real example you tried? You can also try with WallETH (https://walleth.org) when you have an android phone

Member

ligi commented May 3, 2018

you don't have to read long threads - this should be all you need: https://eips.ethereum.org/EIPS/eip-681
Not sure if blockchain.info supports ERC-681 - could not even try - seems to require a login?

ethereum:$PayToAddr?value=$EtherAmountToPay

looks correct - but maybe addr or amount are wrongly formatted - can you make a real example you tried? You can also try with WallETH (https://walleth.org) when you have an android phone

@captainreptile

This comment has been minimized.

Show comment
Hide comment
@captainreptile

captainreptile May 3, 2018

@ligi Thank you for your reply, a simillar format used with bitcoin works - but could be blockchain.info specific.
example output:
ethereum:0x414795eF431eBa832Ed160900a5f0350909372a8?amount=0.011143015007287

captainreptile commented May 3, 2018

@ligi Thank you for your reply, a simillar format used with bitcoin works - but could be blockchain.info specific.
example output:
ethereum:0x414795eF431eBa832Ed160900a5f0350909372a8?amount=0.011143015007287

@ligi

This comment has been minimized.

Show comment
Hide comment
@ligi

ligi May 3, 2018

Member

ah - this is not correct - you can either do scienctific notation:
ethereum:0x414795eF431eBa832Ed160900a5f0350909372a8?amount=0.011143015007287e18

or in wei:

ethereum:0x414795eF431eBa832Ed160900a5f0350909372a8?amount=1114301500728700

Member

ligi commented May 3, 2018

ah - this is not correct - you can either do scienctific notation:
ethereum:0x414795eF431eBa832Ed160900a5f0350909372a8?amount=0.011143015007287e18

or in wei:

ethereum:0x414795eF431eBa832Ed160900a5f0350909372a8?amount=1114301500728700

@rmeissner

This comment has been minimized.

Show comment
Hide comment
@rmeissner

rmeissner May 4, 2018

shouldn't it be value instead of amount?

rmeissner commented May 4, 2018

shouldn't it be value instead of amount?

@ligi

This comment has been minimized.

Show comment
Hide comment
@ligi

ligi May 4, 2018

Member

yes - you are correct - he stated value in the initial template so I was just looking at the fillers this time - and then even copied it - must be value!

Member

ligi commented May 4, 2018

yes - you are correct - he stated value in the initial template so I was just looking at the fillers this time - and then even copied it - must be value!

@maciejhirsz

This comment has been minimized.

Show comment
Hide comment
@maciejhirsz

maciejhirsz May 17, 2018

I'm really late to the party here, but looking over the proposal I see what can be a potential implementation issue with the optional "pay-" prefix. The prefix is in front of the ethereum_address, which can be an ENS name, however ENS domain names allow dashes (-), so address ethereum:pay-foobar.eth becomes ambiguous. This becomes even more problematic since dash (-) is meant as a separator for future extensions of the standard.

maciejhirsz commented May 17, 2018

I'm really late to the party here, but looking over the proposal I see what can be a potential implementation issue with the optional "pay-" prefix. The prefix is in front of the ethereum_address, which can be an ENS name, however ENS domain names allow dashes (-), so address ethereum:pay-foobar.eth becomes ambiguous. This becomes even more problematic since dash (-) is meant as a separator for future extensions of the standard.

@ligi

This comment has been minimized.

Show comment
Hide comment
@ligi

ligi May 18, 2018

Member

@maciejhirsz welcome to the party - you are not to late - just late - happy to have more eyes on this

Happily @pirapira already pointed out the problem before and we found a solution for this:

When the prefix is omitted, the payload must start with 0x. Also prefixes must not start with 0x. So starting with 0x can be used as a clear signal that there is no prefix.

see: https://eips.ethereum.org/EIPS/eip-831

Member

ligi commented May 18, 2018

@maciejhirsz welcome to the party - you are not to late - just late - happy to have more eyes on this

Happily @pirapira already pointed out the problem before and we found a solution for this:

When the prefix is omitted, the payload must start with 0x. Also prefixes must not start with 0x. So starting with 0x can be used as a clear signal that there is no prefix.

see: https://eips.ethereum.org/EIPS/eip-831

@maciejhirsz

This comment has been minimized.

Show comment
Hide comment
@maciejhirsz

maciejhirsz May 18, 2018

@ligi thanks! That makes sense. Shouldn't the schema be updated to reflect it, something like:

request                 = "ethereum" ":" target_address [ "@" chain_id ] [ "/" function_name ] [ "?" parameters ]
target_address          = ( "0x" 40*40HEXDIG ) / ( "pay-" ethereum_address )
chain_id                = 1*DIGIT
function_name           = STRING
ethereum_address        = ( "0x" 40*40HEXDIG ) / ENS_NAME
parameters              = parameter *( "&" parameter )
parameter               = key "=" value
key                     = "value" / "gas" / "gasLimit" / "gasPrice" / TYPE
value                   = number / ethereum_address / STRING
number                  = [ "-" / "+" ] *DIGIT [ "." 1*DIGIT ] [ ( "e" / "E" ) [ 1*DIGIT ] [ "+" UNIT ]

"0x" 40*40HEXDIG should probably be abstracted out to it's own label in this case, but I don't know what a good name would be that isn't ethereum_address, ethereum_raw_address?

maciejhirsz commented May 18, 2018

@ligi thanks! That makes sense. Shouldn't the schema be updated to reflect it, something like:

request                 = "ethereum" ":" target_address [ "@" chain_id ] [ "/" function_name ] [ "?" parameters ]
target_address          = ( "0x" 40*40HEXDIG ) / ( "pay-" ethereum_address )
chain_id                = 1*DIGIT
function_name           = STRING
ethereum_address        = ( "0x" 40*40HEXDIG ) / ENS_NAME
parameters              = parameter *( "&" parameter )
parameter               = key "=" value
key                     = "value" / "gas" / "gasLimit" / "gasPrice" / TYPE
value                   = number / ethereum_address / STRING
number                  = [ "-" / "+" ] *DIGIT [ "." 1*DIGIT ] [ ( "e" / "E" ) [ 1*DIGIT ] [ "+" UNIT ]

"0x" 40*40HEXDIG should probably be abstracted out to it's own label in this case, but I don't know what a good name would be that isn't ethereum_address, ethereum_raw_address?

@ligi

This comment has been minimized.

Show comment
Hide comment
@ligi

ligi May 18, 2018

Member

@maciejhirsz you might be right about this - but I would tend to inherit from #831 rather than inlining it here (DRY over WET) - will talk to @nagydani about this later - thanks for pointing it out

Member

ligi commented May 18, 2018

@maciejhirsz you might be right about this - but I would tend to inherit from #831 rather than inlining it here (DRY over WET) - will talk to @nagydani about this later - thanks for pointing it out

ligi added a commit to ligi/EIPs that referenced this pull request May 18, 2018

@meronym

This comment has been minimized.

Show comment
Hide comment
@meronym

meronym May 29, 2018

The specification lists chain_id = 1*DIGIT but there are networks (e.g. Kovan) with multi-digit chain IDs. Shall we update the formal spec to allow for such cases?

meronym commented May 29, 2018

The specification lists chain_id = 1*DIGIT but there are networks (e.g. Kovan) with multi-digit chain IDs. Shall we update the formal spec to allow for such cases?

@meronym

This comment has been minimized.

Show comment
Hide comment
@meronym

meronym May 29, 2018

Are there any plans for a provisional registration of this URI scheme with the official IANA registry? What would be the next steps for doing so?

meronym commented May 29, 2018

Are there any plans for a provisional registration of this URI scheme with the official IANA registry? What would be the next steps for doing so?

@rmeissner

This comment has been minimized.

Show comment
Hide comment
@rmeissner

rmeissner May 29, 2018

@meronym as pointed out in one of the comments the 1* doesn't mean it is exactly one digit, but it means it is at least one digit (see definition of number)

rmeissner commented May 29, 2018

@meronym as pointed out in one of the comments the 1* doesn't mean it is exactly one digit, but it means it is at least one digit (see definition of number)

@masterial

This comment has been minimized.

Show comment
Hide comment
@masterial

masterial Aug 31, 2018

When is this gonna get implemented?

masterial commented Aug 31, 2018

When is this gonna get implemented?

@ligi

This comment has been minimized.

Show comment
Hide comment
@ligi

ligi Aug 31, 2018

Member

@destinatis It is implemented - e.g. in WallETH

Member

ligi commented Aug 31, 2018

@destinatis It is implemented - e.g. in WallETH

@masterial

This comment has been minimized.

Show comment
Hide comment
@masterial

masterial Aug 31, 2018

@ligi IOS required.

masterial commented Aug 31, 2018

@ligi IOS required.

@ligi

This comment has been minimized.

Show comment
Hide comment
@ligi

ligi Aug 31, 2018

Member

why?

Member

ligi commented Aug 31, 2018

why?

@masterial

This comment has been minimized.

Show comment
Hide comment
@masterial

masterial Aug 31, 2018

@ligi that's what a lot of people use.

masterial commented Aug 31, 2018

@ligi that's what a lot of people use.

@ligi

This comment has been minimized.

Show comment
Hide comment
@ligi

ligi Aug 31, 2018

Member

yea - but they have other problems than missing 681 ..

Anyway this goes way out of topic. They could easily implement it - not sure why they don't. Guess they are busy fighting x-code and trying to get their apps in the store. Really sad people waste their time this way.

Member

ligi commented Aug 31, 2018

yea - but they have other problems than missing 681 ..

Anyway this goes way out of topic. They could easily implement it - not sure why they don't. Guess they are busy fighting x-code and trying to get their apps in the store. Really sad people waste their time this way.

@masterial

This comment has been minimized.

Show comment
Hide comment
@masterial

masterial Aug 31, 2018

5 major wallets (trust, imtoken, toshi, cypher, blockchain). none have support. seriously, WTF am I missing here?

masterial commented Aug 31, 2018

5 major wallets (trust, imtoken, toshi, cypher, blockchain). none have support. seriously, WTF am I missing here?

@ligi

This comment has been minimized.

Show comment
Hide comment
@ligi

ligi Aug 31, 2018

Member

yes I also think we need more support in general: https://ethereum-magicians.org/t/we-need-more-support-for-erc-681/897
@vikmeup told me trust should support it soon - but this is also already a while ago ..
Write to your favorite wallets and demand it! Android wallets can also use this lib: https://github.com/walleth/kethereum/tree/master/erc681 - could even be used on iOS - but not that easily out of the box - but again - why would you waste your time with iOS anyway.

Member

ligi commented Aug 31, 2018

yes I also think we need more support in general: https://ethereum-magicians.org/t/we-need-more-support-for-erc-681/897
@vikmeup told me trust should support it soon - but this is also already a while ago ..
Write to your favorite wallets and demand it! Android wallets can also use this lib: https://github.com/walleth/kethereum/tree/master/erc681 - could even be used on iOS - but not that easily out of the box - but again - why would you waste your time with iOS anyway.

@masterial

This comment has been minimized.

Show comment
Hide comment
@masterial

masterial Aug 31, 2018

dude, i can't just tell my customers to use android. they tell me what they use. i also did write to them today. this is kind the most important feature of ethereum. they will probably implement it eventually. but once again, wtf? also seems like QR does not even work on Trust anymore for regular send input. unbelievable.

masterial commented Aug 31, 2018

dude, i can't just tell my customers to use android. they tell me what they use. i also did write to them today. this is kind the most important feature of ethereum. they will probably implement it eventually. but once again, wtf? also seems like QR does not even work on Trust anymore for regular send input. unbelievable.

@skywinder

This comment has been minimized.

Show comment
Hide comment
@skywinder

skywinder Sep 8, 2018

@ligi Challenge accepted! We will do that in ETHBerlin! 🔥
Keep in touch!

skywinder commented Sep 8, 2018

@ligi Challenge accepted! We will do that in ETHBerlin! 🔥
Keep in touch!

@brunobar79

This comment has been minimized.

Show comment
Hide comment
@brunobar79

brunobar79 Sep 12, 2018

Hey guys, just wanted to share two tools here that might be useful for people trying to implement this on their end:

  • eth-url-parser - JS module that handles parsing and building ethereum standard urls

  • link generator - Web app that allows you to generate valid ethereum links (and it's corresponding QR code)

Note: I wrote both in a rush so please lmk if you find any issues with it (or even better submit a PR and fix it!)

brunobar79 commented Sep 12, 2018

Hey guys, just wanted to share two tools here that might be useful for people trying to implement this on their end:

  • eth-url-parser - JS module that handles parsing and building ethereum standard urls

  • link generator - Web app that allows you to generate valid ethereum links (and it's corresponding QR code)

Note: I wrote both in a rush so please lmk if you find any issues with it (or even better submit a PR and fix it!)

Arachnid added a commit that referenced this pull request Oct 15, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment