We wrote a blog post, how replacing ERC20 with ERC827, can lead to unexpected reentrancy attacks.
…
Given that potential use cases of transferAndCall are unclear, I see the value of our article in clarifying how it should not be used.
Similar issues apply to approveAndCall, however, given that this functionality does not exist in ERC20 (as you said), we would have had to construct an example with vulnerable code to use it. If you have concrete cases, where approveAndCall is called from a smart contract we would be happy to check.
Overall, our intention was just to notify people that special care is needed when using these functions inside a smart contract.
Hello @jpitts, thanks for bringing this up on the ethereum-magicians community.
The issue with transferAndCall is that there is no way to verify the actual balance that was transfered, that is why we recommend the use of approveAndCall to work with “verified” balance in the EIP description.
We are working on changes on the standard to prevent this from happening, the main proposal that we have for now is the use of “allowed” callbacks, wich means that the receiver contracts will be able to allow functions to be executed on it.
I think the allowedCallbacks is a good solution, it adds the necessary interface to allow contracts to execute specific and tested arbitrary calls over them. Removing this permission of execute calls on any contract form the token contract, and it adds only a ~50 lines of code.