Token flavor that implements the approveAndCall and interface for receiveApproval OR ERC23?

[yarrumretep]

Propose to add a StandardTokenWithCall token flavor that extends StandardToken with the approveAndCall() method. Also add an ApprovalReceiver interface contract that declares the receiveApproval method.

Happy to gin up a PR if that sounds good.

[yarrumretep]

Alternatively, we could just add the approveAndCall() to the StandardToken implementation - though I'm don't think it's technically part of the ERC20 spec.

[yarrumretep]

Alternatively, we could include an ERC23Token base implementation and ERC23Receiver interface. Or BOTH, I suppose...

[yarrumretep]

The ERC23 discussion is still fairly dynamic over here: ethereum/EIPs#223 so we may not have a settled direction for a bit.

[frangio]

Thanks @yarrumretep!

The proposal seems like it's still being actively developed, right? Could you share a summary of the discussion? How much consensus there is, what parts are still changing, etcetera. I think it can be useful to create some discussion around it and assess how we want to approach it in OpenZeppelin.

[yarrumretep]

Hi @frangio, the discussion is at ethereum/EIPs#223 I'll see if we can get things gelled a bit in the coming week or so - that ok by you guys?

[frangio]

Yeah, definitely.

[kylerchin]

Hi! @frangio @yarrumretep I'm working on a project called solariot and creating a token called solCredits https://github.com/solariot . The way payments work in my p2p electricity network is using smart contracts and having both parties verify the transaction of the tokens. Since the tokens are held in the smart contract, I'm looking for a secure way to implement tokens in a smart contract, where the solidity contract calls another contract address. I poked around stack exchange, but I didn't see anything. I was pointed to ERC223, but their is no secure implementation of it yet. Would be great if there was some way to hold tokens in contracts securely.

[yarrumretep]

@frangio - the ERC223 conversation still seems pretty raw. The current proposal is likely to be breaking for multi-sig wallets and other contracts that may depend on blind-contract-token transfers.

I think I'd recommend we hold off on implementing anything in open-zeppelin for the moment. How about I remove the implementation and submit only the approveAndCall() implementation which gets at the same single-transaction destination-notified token-transfer - but is backward compatible with the existing ERC20 stuff?

[dani-corie]

I think approveAndCall is pretty much industry standard at this point, beside of course manual approving-and-calling...

It should definitely be part of the OpenZeppelin library.

[come-maiz]

@yarrumretep I'm a little confused now. So can we leave this issue is for the implementation of ERC827, and #512 for the implementation of ERC233?

[nventuro]

Closing for the same reasons mentioned here.