Added ERC223 feature

[ProphetDaniel]

No description provided.

[DavidKnott]

intor to into

[DavidKnott]

@ProphetDaniel This looks like it'll be a great addition! Could you explain how having 2 transfer functions in the same contract works? (I'm curious) I'm assuming it's smart enough to choose which function to use based on if bytes data is provided?

[Dexaran]

@DavidKnott this transfer functions would have different signatures.
The signature of transfer(address,uint256) function is 0xa9059cbb.
The signature of transfer(address,uint256,bytes) function is 0xbe45fd62.
You are right, if bytes data is provided, then the signature of the called function will match the transfer (address, uint256, bytes), and if the data is not provided, the signature will match the transfer (address, uint256).

Function calls in the Ethereum Virtual Machine are specified by the first four bytes of data sent with a transaction. These 4-byte signatures are defined as the first four bytes of the Keccak hash (SHA3) of the canonical representation of the function signature.

[ProphetDaniel]

Thank you for answering him @Dexaran!

[izqui]

We have a more complex implementation we did at https://github.com/aragon/erc23 that has the tokenPayablemodifier that i think it is very interesting for using tokens as ether for calling functions

[DavidKnott]

@Dexaran @izqui Thanks a lot for explaining this!

[ProphetDaniel]

@izqui , Indeed tokenPayable modifier is very interesting. Can you make a PR to this feature branch?

[ProphetDaniel]

Another point to be considered is the cost for the added complexity the tokenPayable modifyer adds. Anyway I think it a good practice to implement first the basic ERC223 token standard. And later on the more complex implementation that adds features like the tokenPayable modifyer.

[se3000]

@izqui I like your tokenPayable modifier and tkn storage technique. It adds a little complexity, but would be a good example for other contracts in the future.

It looks like your tokenFallback function accepts an extra parameter, address _origin, which is not specified in the original spec. Can you clarify for me why it is a worth while parameter to add?

[maraoz]

@ProphetDaniel this still needs rebasing to be mergeable.

[maraoz]

@ProphetDaniel still needs to be rebased correctly. Remember not to do a git pull before pusing, and do a git push -f instead

[frangio]

Closing as stale. Furthermore, our implementation shouldn't be a clone of the reference implementation, but written from scratch.

[kylerchin]

Please reopen this @frangio . ERC223 tokens are necessary for storing tokens in my contract. I am building my token around the ERC223 for payment solutions and anti fraud using smart contracts between 2 people. I think people would like a safe way to use tokens such as these ones.

[frangio]

Hi @kylerschin. We appreciate your input. This PR was closed for different reasons. Please refer to #346, we'd love to have your opinion over there.

[ProphetDaniel]

It is quite amusing this specific actitude @frangio.

Closing as stale.

@kylerschin, I tested this implementation with truffle tests and LETH wallet. More tests can be added though. One of the important questions is if it will work flawlessly with ERC20 wallets that could be awaiting ERC20 events for example. I took special care with that for the event triggering strategy. A great real life token wallet with which I have also tested is Inzhoop LETH.