APIs for Transferable Fungibles

[ethers]

The specification is at the wiki https://github.com/ethereum/wiki/wiki/Standardized_Contract_APIs#transferable-fungibles so that it can be edited by anyone.
The wiki is initially from https://gist.github.com/frozeman/090ae32041bcfe120824 from which prior discussion should be viewed.
This issue is created per obscuren's suggestion on Gitter.
Anyone can provide content/suggestions for Abstract, Motivation etc.

  EIP: 
  Title: APIs for Transferable Fungibles
  Author: 
  Status: Draft
  Type: Informational
  Created: 2015-11-19

==Abstract==
Although Ethereum allows developers to create absolutely any kind of application without restriction to specific feature types, and prides itself on its "lack of features", there is nevertheless a need to standardize certain very common use cases in order to allow users and applications to more easily interact with each other. This includes sending currency units.

==Motivation==

==Specification==
https://github.com/ethereum/wiki/wiki/Standardized_Contract_APIs#transferable-fungibles

==Rationale==

==Implementation==

[ethers]

recent discussion from https://gist.github.com/frozeman/090ae32041bcfe120824

@vbuterin said:
Yeah, createCheque and cashCheque as above, plus transferCheque(address _from, address _to, uint256 _value) sounds good. In that case, we should probably remove the _to argument from cashCheque; generally, you can only cash cheques from your own bank account.

We probably also want getChequeValue(address _from, address _for). We then have a choice of whether we want to keep the value argument in cashCheque rather than simply only allowing cashing in 100% of whatever is in there. If we want to fully follow the cheque analogy, this triad seems most intuitive to me:

function createCheque(address _for, uint256 _maxValue)
function cashCheque(address _from)
function getChequeValue(address _from, address _for)
Question: does running createCheque twice add the value of the two cheques together? Are there legitimate use cases for creating a cheque multiple times and then cashing either once or multiple times?

@nmushegian said:
All the functions that return uint should return (uint, bool) instead. You can easily make up scenarios where a 0 return value is ambiguous and significant. Is there any other simpler pattern for handling this?

@niran said:
I think the value parameter is useful in cashCheque. It absolves callers from having to verify that the amount they needed was provided, and from having to refund amounts greater than what was needed. cashCheque would only succeed if the provided value was remaining in the cheque.
Also, I think using createCheque(2**100) for the approve use case is going to lead to less clear code. It gets better if you make the magic number a constant, like createCheque(UNLIMITED_CHEQUE_VALUE), but lots of people won't do that. I think it's worth having a createBlankCheque or something for the approve scenario. Most tokens will use the TokenLib to handle all of the cheque logic, so it doesn't really make things worse for token authors.

[simondlr]

Please continue discussion here instead: #20