Update transferFrom to modify allowance in-between hook calls. #1751
Conversation
|
Turns out the ERC20 behaviour didn't check for |
|
good catch, I hope nothing else is hiding in there hehe |
|
By the way I don't see why would anyone want to create a non-ERC20 compatible ERC777 token in the near 6-12 months. The tooling for ERC777 compared to ERC20 are far behind + exchange support, etc. More than that: creating non-ERC20 compatible token in OpenZeppelin might encourage mistakes for tokens creators creating non-ERC20 compatible tokens without being aware of the consequences. |
|
isOperatorFor is used both for operatorSend and operatorBurn which seems surprising in the sense that if someone authorizes an operator to send his tokens, I am not sure he also wants to authorize the operator to burn his tokens (in most cases) |
|
CI will fail until #1752 is merged, due to different error messages being emitted here and in ERC20. |
nventuro
force-pushed
the
erc777-state-change
branch
from
a72cb50 to
ad18098
Compare
|
I ended up re-doing the changes from |
|
@nventuro maybe check that address is not (case insensitive) 0xdcc703c0E500B653Ca82273B7BFAd8045D85a470 in addition to 0x0. That address is the hash of the empty/zero public key. See: https://www.reddit.com/r/ethereum/comments/493cys/if_your_address_is/ |
* Fix transferFrom not updating allowance before calling receiver. * Fix from being passed as operator. (cherry picked from commit 2ccc12b)
Anyone that can send tokens can also, e.g, send them to addresses for which no-one has the private keys, which is pretty much a burn, as far as the user is concerned. Anyway, the EIP is very clear in this aspect, so this is not for us to decide.
Yeah I've thought about this, but the list of addresses that may be accidentally called is sadly way too large. The zero address is special because in Solidity uninitialized addresses hold that value, so it is easier to accidentally use it. |
|
@nventuro 0x0 is the default from solidity side, 0xdcc703c0E500B653Ca82273B7BFAd8045D85a470 is the default (hash of empty) from the dapp side (as described in the reddit link where a common app bug can result in this address). So seems like the two main ones, can you please provide one other example of a popular bug-wise address which is invalid? |
Fixes an issue in the current release candidate ERC777 implementation, found by @guylando in #1749.
transferFromnow updates allowances after calling the send hook, but before calling the receive hook.I also, uh, did a small refactor and changed some variable names while figuring out the best way to introduce this. Sorry!
The code looks somewhat weird at the moment (e.g. I'd expect to find similarities in
_transferand_sendwhich aren't there), but all of this will make more sense once we make the ERC20 extension opt-in.We also need to add new tests cases for this, by logging extra data in our mock sender and receiver contracts, and possibly creating new behavior-like functions that check this on ERC20 calls (including
transferFrom). This may be something we want to leave for when we extract built-in ERC20 support out of the base ERC777 contract, since all of the associated ERC20 testing code will need to be changed at that point.