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

Check that destination of token transfers is not 0x #400

Closed
maraoz opened this issue Aug 23, 2017 · 4 comments
Closed

Check that destination of token transfers is not 0x #400

maraoz opened this issue Aug 23, 2017 · 4 comments
Labels
good first issue Low hanging fruit for new contributors to get involved!

Comments

@maraoz
Copy link
Contributor

maraoz commented Aug 23, 2017

Do we want to add require(_to != address(0)) to transfer and transferFrom?

@maraoz maraoz added the good first issue Low hanging fruit for new contributors to get involved! label Aug 23, 2017
pash7ka added a commit to pash7ka/zeppelin-solidity that referenced this issue Aug 23, 2017
@SylTi
Copy link
Contributor

SylTi commented Aug 24, 2017

Why? You can have use cases that need to send funds to a non-accessible address.
And why only checking for a null address? why not also check for validity?

@frangio
Copy link
Contributor

frangio commented Aug 24, 2017

What does it mean to check for validity?

In general we add checks for the null address because uninitialized values in the EVM are zero values. It helps prevent errors. A use-case where it's needed to make tokens inaccessible would be better served by a custom (non-ERC20) function that removes the tokens from circulation.

@SylTi
Copy link
Contributor

SylTi commented Aug 26, 2017

What I mean by invalidity is non-redeemable address like 0xdead, 0xwhatever etc.

I agree, but a user can't make that error (only a dev) by forgetting a parameter, the function takes 2, so you must provide 0x0 manually or the EVM will throw because of the invalid number of arguments.

Removing the tokens from circulation doesn't mean necessarily destroying them. What if you want to transfer them to 0x0 until X and make them redeemable at that point?

pash7ka added a commit to pash7ka/zeppelin-solidity that referenced this issue Aug 28, 2017
@frangio
Copy link
Contributor

frangio commented Aug 28, 2017

The thing is there is no way to identify that an address is non-redeemable. Any address is potentially non-redeemable if no user has a private key for it (and it's not a contract address).

pash7ka added a commit to pash7ka/zeppelin-solidity that referenced this issue Aug 28, 2017
frangio pushed a commit to frangio/openzeppelin-contracts that referenced this issue Aug 28, 2017
frangio pushed a commit to frangio/openzeppelin-contracts that referenced this issue Aug 28, 2017
pash7ka added a commit to pash7ka/zeppelin-solidity that referenced this issue Nov 16, 2017
pash7ka added a commit to pash7ka/zeppelin-solidity that referenced this issue Nov 16, 2017
pash7ka added a commit to pash7ka/zeppelin-solidity that referenced this issue Nov 16, 2017
pash7ka added a commit to pash7ka/zeppelin-solidity that referenced this issue Nov 16, 2017
pash7ka added a commit to pash7ka/zeppelin-solidity that referenced this issue Nov 16, 2017
pash7ka added a commit to pash7ka/zeppelin-solidity that referenced this issue Nov 16, 2017
pash7ka added a commit to pash7ka/zeppelin-solidity that referenced this issue Nov 16, 2017
pash7ka added a commit to pash7ka/zeppelin-solidity that referenced this issue Nov 16, 2017
pash7ka added a commit to pash7ka/zeppelin-solidity that referenced this issue Nov 16, 2017
pash7ka added a commit to pash7ka/zeppelin-solidity that referenced this issue Nov 16, 2017
pash7ka added a commit to pash7ka/zeppelin-solidity that referenced this issue Nov 16, 2017
ProphetDaniel pushed a commit to classicdelta/Smart-Contracts that referenced this issue Mar 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Low hanging fruit for new contributors to get involved!
Projects
None yet
Development

No branches or pull requests

3 participants