ERC-777 A New Advanced Token Standard

[jbaylina]

Tjis is the PR discussed in #777

Pending issues required for the standard to be approved

• Approve eip820
• Decide if include listOperators(address account) constant public returns(address[]) (Will not be implemented).
• Decide if include a revokeAllOperators(address account) public (Will not be implemented)
• Approve

[0xjac]

@jbaylina
I'm currently working on revokeAllOperators: 0xjac/ERC777#35
Last time we agreed not to include listOperators. Any reason why the change of mind?

[fulldecent]

revokeAllOperators requires a for loop. Here is a way to implement deletable mappings where you can delete them with O(1).

https://ethereum.stackexchange.com/a/42540/26015

It seems ridiculous, but I'm not sure what exactly the gas cost or practicality is.

[fulldecent]

This EIP now includes a logo. And the logo is not licensed CC0 as per EIP-1.

[0xjac]

@fulldecent The reason the logo is under CC is to add a restriction to prevent the use of the logo for non ERC777 tokens and other technologies (such as wallets). I'm happy to change it to CC0 if the community think it's better that way.

Also technically the logo is only referenced in the EIP, we should include it in this repo as well. D0 you know what the best approach is? Maybe similar to #858: add an eip-777 folder containing the logo?

[MicahZoltu]

I very much prefer CC0; attribution makes everything hard if you actually follow it (which 99% of people don't, so they all violate the copyright anyway). I am also not personally a fan of copyrights in the first place.

[0xjac]

@fulldecent @MicahZoltu Alright I will move it to CC0 and add the logo in the repo. The idea was really not to do attribution or to restrict the use of the logo in any way except for false advertising.

[MicahZoltu]

Unfortunately, there are very few licenses that don't require attribution. CC0, Unlicense, WTFPL are the common ones. All of them are basically "release into public domain". There are no licenses (unfortunately) that release into public domain with exceptions. There is also no license for "release into public domain and also release all patents", which is really needed IMO.

[jbaylina]

Please comment on this: #777 (comment)

[0xjac]

@fulldecent @MicahZoltu Done, the logo is now under CC0 and is included in this repo. (Before it was just referenced from jacquesd/erc777 which contains the reference implementation)

Note that the images do appear broken, that's normal they are links to where the image will be once merged into the master branch of /ethereum/EIPs. After merging the images will appear.

[MicahZoltu]

I recommend changing this to use markdown rather than HTML and use relative links instead of absolute links. This way the images work both in the PR and on any branch.

I think the syntax is something like this for the image link, though you should look at the GitHub Markdown docs for specifics.

![Beige](EIPs/eip-777/logo/png/ERC-777-logo-beige-192px.png)

[Arachnid]

This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:

• Frontmatter is now contained between lines with only a triple dash ('---')
• Headers in the frontmatter are now lowercase.

If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR.

In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks.

Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt:

---
eip: <num>
title: <title>
author: <author>
type: [Standards Track|Informational|Meta]
category: [Core|Networking|Interface|ERC] (for type: Standards Track only)
status: Draft
created: <date>
---

[0xjac]

@Arachnid Thanks for the notice, the eip draft has been adapted to the new format.

@MicahZoltu thanks for your feedback. I have updated the links to be relative and they seem to work, but the new travis hook is complaining about them.

I have run the travis jobs locally and I noticed that links on the generated page for the EIP work fine and the images with the relative links are displayed. So I'm guessing there is something wrong with the way the links to the local eip-777 folder with the logo are validated with htmlproofer. Maybe some config I'm missing?

[Arachnid]

You need to use relative URIs - instead of /EIPS/eip-777/..., use eip-777/....

[0xjac]

@Arachnid

You need to use relative URIs - instead of /EIPS/eip-777/..., use eip-777/....

Sorry I was unclear. I did fix the links, and Jordi should update this PR soon with the fix, but at least with my fork, the build still fails because of the links related to the folder.

[Arachnid]

Sorry I was unclear. I did fix the links, and Jordi should update this PR soon with the fix, but at least with my fork, the build still fails because of the links related to the folder.

Ah, right.

htmlproofer does not like the fact that there is a directory with the same name as the file.

We probably need a better way to handle this in general. I'm open to suggestions.

[0xjac]

I based the eip-777 folder on previous eips which did the same like 107 or 858.
I would suggest having a single folder named something like static or assets and moving all the eip-X folders in there.

If the folder is named assets then it should be merged with the generated assets folder of jekyll.
I think this might be a bit cleaner and if each eip has it's own folder in there named properly, it should not create any conflict with other assets

[Arachnid]

Please put usernames in parens, so they'll be automatically linkified and the bot can determine they're authors.

[Arachnid]

Does this really replace ERC20?

[fulldecent]

@Arachnid Have the "EIP collaborators" approved this to be accepted as draft? I believe your merging here was premature.

[Arachnid]

@fulldecent To be accepted as a draft, an EIP only needs to be syntactically correct and not obviously stupid; it doesn't imply approval. An author asked me to merge it OOB, so I did.

[jbaylina]

@fulldecent I prefer for discussion to have individual concrete PRs than discuss them in the long thread.

[h3ph4est7s]

One question, imagine the scenario that a malicious person in any of both parties implement a gas exhausting function and consume deliberately the remaining gas. In the case of the sending party even if the owner gave operator permission to a third party the call will keep remaining out of gas and the operator will lose value by trying to execute the transaction in behalf of the sending party. In the other case the sending party will lose value by trying to send value to the receiving party. A standardized gas limit should be provided for tokensReceived and tokensToSend. Something like .gas(n) here and here

[yuwiggin]

Is ERC777 vulnerable from short address attack? If it is, how to avoid it?