Right now entering a non-hex-prefixed address into the check balance field will silently fail to the user.

It would be easy enough to call ethUtil.addHexPrefix(userInput), so I think that would be better.

Standard_Token declares totalSupply var but does not implement totalSupply()

not sure if this is intentional or not

When running "truffle migrate", the following error is returned:
"Error: Could not find built Migrations contract: Could not find artifacts for ./Migrations.sol from any sources."

I cloned from this repository and built with "npm install". Did I miss any steps in building?

Truffle version: 3.2.4
OS: Windows 10

The approve function can only return true, why does it return anything?

   function approve(address _spender, uint256 _value)
        public
        returns (bool)
    {
        allowed[msg.sender][_spender] = _value;
        Approval(msg.sender, _spender, _value);
        return true;
    }

I would propose to change it to:

   function approve(address _spender, uint256 _value)
        public
    {
        allowed[msg.sender][_spender] = _value;
        Approval(msg.sender, _spender, _value);
    }

Most tests shouldn't call .catch(done) as the done should be called after the test case performs its assertions.

// Prevents methods from perfoming any value transfer
modifier noEther() {if (msg.value > 0) throw; _}

Should we add this to all the methods?

Hi, this is probably the wrong place to ask a query but I couldn't find a better option.

In the About section, it is mentioned that uPort identity is stored as a JSON structure (IPFS) and a hash of that on the blockchain. Isn't is possible for someone to simply query the smart contracts and get the list of hash available and open them on ipfs to extract customer data by going through non-empty blocks, which can raise a privacy issue.

I wanted to understand if uPort has an encryption mechanism to safegaurd data of people.

Sorry if this is not the correct place, but if someone replies then TIA.

I have the following issue: creation of nameofmycoin errored: Error encoding arguments: SyntaxError: Unexpected token ' in JSON at position 11. Is there a way to fix it?

More recent versions of solidity are issuing warnings about various deprecations.

These are not a safety concern, but it does look scary to new comers, so we should fix it.

Separate issue identified from #16

To consider, how would an attacker try to exploit the factory...

I got a problem(ParserError: Expected token LBrace got 'View') when compile the code(in HumanStandardTokenFactory.sol, StandardToken.sol, Token.sol) using "truffle compile" .

the output of error:
/home/ubuntu/git/Tokens/contracts/HumanStandardTokenFactory.sol:19:70: ParserError: Expected token LBrace got 'View'
function verifyHumanStandardToken(address _tokenContract) public view returns (bool) {

,/home/ubuntu/git/Tokens/contracts/StandardToken.sol:43:40: ParserError: Expected token LBrace got 'View'
function balanceOf(address _owner) view public returns (uint256 balance) {

,/home/ubuntu/git/Tokens/contracts/Token.sol:20:47: ParserError: Expected token LBrace got 'View'
function balanceOf(address _owner) public view returns (uint256 balance);

the output of "truffle version":
Truffle v3.4.11 (core: 3.4.11)
Solidity v0.4.15 (solc-js)

is there anything wrong with my environment?

When installing these tokens from the ethpm registry, there is an error. However, a few of the contracts do get installed. HumanStandardToken.sol, StandardToken.sol, and Token.sol are installed even with the error. These contracts do not match the ethpm.json manifest.

$ truffle install tokens
Error: Could not find object at hash 'QmSMdCxaH1H5TfyjKVtiPKnFabkQByciTBG6FTCAiCufX7' in 5000ms
    at Timeout._onTimeout (/Users/<username>/.nvm/versions/node/v6.10.0/lib/node_modules/truffle/node_modules/ethpm/lib/hosts/ipfshost.js:47:14)
    at ontimeout (timers.js:365:14)
    at tryOnTimeout (timers.js:237:5)
    at Timer.listOnTimeout (timers.js:207:5)

`//verifies if a contract that has been deployed is a Human Standard Token.
//NOTE: This is a very expensive function, and should only be used in an eth_call. ~800k gas
function verifyEIP20(address _tokenContract) public view returns (bool) {
bytes memory fetchedTokenByteCode = codeAt(_tokenContract);

    if (fetchedTokenByteCode.length != EIP20ByteCode.length) {
        return false; //clear mismatch
    }

  //starting iterating through it if lengths match
    for (uint i = 0; i < fetchedTokenByteCode.length; i++) {
        if (fetchedTokenByteCode[i] != EIP20ByteCode[i]) {
            return false;
        }
        return true;
    }
}`

Shouldn't the return true; statement be outside of the for-loop? The function will return true on the first match, even if the rest dont match.

Are these registered on a solidity package manager, like Dapple, to allow easy installing in a project?

I even think npm registration could work, if you clarified in the readme what importing entailed.

Any thoughts about ways these should be consumed?

Deploying the HumanStandardTokenFactory contract fails with the error Contract not deployed, getCode returned 0x.

Deploying to the Kovan network using Parity

I have been trying to execute the HumanStandardTokenFactory using Remix & MetaMask on a custom chain.

I keep getting the following message:
callback contain no result Gas required exceeds block gas limit: 800000000

It does say in the comments of the contract that the function 'verifyHumanStandardToken' can cost about 800k gas, therefore my transaction gas limit should be enough.
I have checked my custom chain gas limit in the genesis block and it is 4712388:

eth.getBlock("latest").gasLimit 4712388

I have not modified the template code at all, so what am I missing ?

This is the function:

    function codeAt(address _addr) internal returns (bytes o_code) {
      assembly {
          // retrieve the size of the code, this needs assembly
          let size := extcodesize(_addr)
          // allocate output byte array - this could also be done without assembly
          // by using o_code = new bytes(size)
          o_code := mload(0x40)
          // new "memory end" including padding
          mstore(0x40, add(o_code, and(add(add(size, 0x20), 0x1f), not(0x1f))))
          // store length in memory
          mstore(o_code, size)
          // actually retrieve the code, this needs assembly
          extcodecopy(_addr, add(o_code, 0x20), 0, size)
      }
    }

Its test fails. I think I have an idea as to why.

Lets enumerate the magic numbers in the line mstore(0x40, add(o_code, and(add(add(size, 0x20), 0x1f), not(0x1f))))

0x40 is the location of the free memory pointer.
0x20 is 32 bytes, which we want to leave free at the beginning of o_code so we can store the buffer size in it (mstore(o_code, size)).
0x1f appears to be a number with which we determine the amount of memory to reserve. Though its exact nature is mysterious to me.

Imagine size is 0. 0x20 + 0x1f is 0x3f. In decimal, the 32 byte size field plus the 31 byte magic number is 63 bytes. The negation of 0x1f (not(0x1f)) is 0xe0 (224). and(0x3f, 0xe0) is 0x20, or 32 bytes, which is what we would expect if we had an empty buffer: a size element storing zero followed by no data.

If the code is one byte in size and we do this math again we get 64 bytes, which also makes sense. A 32 byte size element followed by a 32 byte data element. If the code size is 33 bytes we'll get 96, which also makes sense: a 32 byte size element followed by two 32 byte data elements.

This all works until you get to code sizes greater than 192 bytes (which would correctly give you a 224 byte buffer). If you have a code size of 193 bytes, and(0x100, 0xe0) will give you 0.

0000 0001 0000 0000
0000 0000 1110 0000

And the answers will continue to be funky for all code sizes greater than 192 bytes.

So I think we need to understand where the magic number 0x1f comes from, and how we can make it not a magic number on the basis of the size of the code being examined.

Solhint and airbnb style

Things we need:

1. A contract of exactly the same length as the compiled EIP20 contracts and with a matching first byte, but non-matching trailing bytes.

2. A way to deploy that contract (theoretically easy, but if the test contract has to be hand built as bytecode, I think we’ll need to hack Truffle’s deployment pipeline a bit or otherwise do something non-standard to get it in the tests.)

Code is over-commented. Especially remove things like "uncomment this code to get different behavior".

I'd like to be able to run these tests to assess ERC20 compliance at an arbitrary address. Mainly that means a test suite that doesn't necessarily generate a new contract. Some custom npm commands would be nice too.

Hey @skmgoldin. Seems like consensus is that we should throw when not having enough balance (vs return false).

https://github.com/ethereum/EIPs/pull/610/files

Never fully liked this. It's a trade-off in its own right, but if the community is moving to this, do we want to change to this?

@alexvandesande standard token has the fallback function implement a throw(), implying that whenever Ether is sent to it, it automatically reverts. This causes the possibility for Ether to get locked up in the contract to not happen.

See here: https://gist.github.com/alexvandesande/0d1a998d949e26942212

Question: Should this be in this repo's current standard token code? Only reason why I feel this should not be the case is that one could create an etherbank contract to extend token functionality to Ether itself. But then would be a substantially different one as well.

So gut feel, yes. Add it in.

This repo no longer exists

https://github.com/ConsenSys/Tokens/blob/0357814acf6b50cadb6586d1984ca964c32456cd/package-lock.json#L4248

diff --git a/package.json b/package.json
index a8c1592..ce9d15a 100644
--- a/package.json
+++ b/package.json
@@ -28,7 +28,8 @@
   },
   "homepage": "https://github.com/ConsenSys/Tokens#readme",
   "dependencies": {
-    "truffle": "4.0.1",
+    "truffle": "4.0.4",
+    "bignumber.js": "^4.0.2",
     "truffle-hdwallet-provider": "0.0.3"
   },
   "devDependencies": {

Your contract: https://github.com/ConsenSys/Tokens/tree/master/Token_Contracts/contracts

Contract on Ethereum website: https://www.ethereum.org/token

Both are implementing ERC20 interface, I was just wondering maybe it's a good idea to have all different implementations in a single place for completeness...

I try to implement HumanStandardToken.sol on the develoment environment of an ethereum - wallet and i get: It seems this transaction will fail. If you submit it will consume all the gas you sent.

code.txt

What folder do I put the Standard Token.sol file to import by the solidity code in the ethereum wallet?

Pretty sure they're no longer being used or needed.

@skmgoldin I see you added some eslint plugins. Do you have a config file for it?

Should we add eslint as a dependency as well, or is best practice to run a global install?

I like to organize tests like this: https://github.com/ConsenSys/PLCRVoting/tree/master/test

That way you can implement coverage trackers and more easily audit whether particular functions are being adequately covered.

I've been using truffle to deploy contracts via a localhost, and using metamask to interact with the dapp. I am wondering if I can load that contract for this token into tokenfactory? When I access the tokenfactory website I can't use it unless I have metamask installed. So, Im just assuming that if I have metamask connected to a private network then any way I interact with token factory will also be on localhost (a side note is if I am not on local host then do I have to pay the gas fee to create the tokens over the mainnet?)

When I try to interact with a token (for example using the metacoin.sol test token from truffle) I use the metacoin address provided after running truffle serve. The procedure brings up:

Interacting with token at address: 0x0ef790110aa9fded64c8dff1d8d96be05c8a5024.
Total Supply is: .

How can I interact with this token I created and served using truffle using the token factory interface? Am I missing something like not adding the correct contract address?

I think the JS unit tests need to be cleaned up. I've been working on it a little bit, I'll submit a pull request if I get positive feedback. Subsections should probably be split by a describe clause. Assertion style should probably also be standardized for readability. Comments don't make much sense inside the tests unless describing some obscure bug (unit tests should be relatively self explanatory). Thoughts?

I'm not sure how this is configured, but codeship's testrpc will need to increase the gas.

@skmgoldin Maybe it's time to get this moved to not your personal codeship account?

Hello,

I wondered if there is a deployed version of the (current version of) HumanStandardTokenFactory that is already verified on etherscan and ready to use.

Cheers,
Stefan

The compile is giving a lot of warnings.
Explicit is better than implicit.

localhost/Token.sol:33:5: Warning: No visibility specified. Defaulting to "public".
    function transferFrom(address _from, address _to, uint256 _value) returns (bool success);
    ^---------------------------------------------------------------------------------------^

Slight oversight. Token.sol should be abstract to enforce implementation of the standard. ht @HCharlanes

EDIT: Replace "revert" with "returned false" in this issue; I realized StandardToken does not throw on error but then realized the issue is practically the same and still just as harmful

Reverting on 0-valued transfer and approval is an anti-pattern that pops up repeatedly in code reviews. I realized it's because many people are copying your StandardToken.

These two lines should have && _value > 0 removed:

        if (balances[msg.sender] >= _value && _value > 0) {

        if (balances[_from] >= _value && allowed[_from][msg.sender] >= _value && _value > 0) {

0-valued transfers and approvals should be valid and behave almost like no-ops, without reverting state. This is so that consumer contracts do not have to take care to work around this edge case.

https://github.com/ConsenSys/Tokens/blob/master/Token_Contracts/test/humanStandardTokenFactory.js#L1

Async await syntax is much more readable, which is useful for reviewability.

We should add an EIP 721 NFT token representation to the repo.

Cc. @alex-miller-0

For example, what does this mean?

https://github.com/ConsenSys/Tokens/pull/71/files#diff-d44cc2e3f0ad5591d79d9df53837e60fR37

I'm trying to learn how to create an alt-coin with your repo but the tests don't pass. Can you please help me out. Perhaps I'm doing something incorrectly.

Using network 'development'.

Compiling ./contracts/HumanStandardToken.sol...
Compiling ./contracts/HumanStandardTokenFactory.sol...
Compiling ./contracts/StandardToken.sol...
Compiling ./contracts/Token.sol...
Compiling ./contracts/TokenTester.sol...


  Contract: HumanStandardToken
    ✓ creation: should create an initial balance of 10000 for the creator
    ✓ creation: test correct setting of vanity information (110135ms)
    ✓ creation: should succeed in creating over 2^256 - 1 (max) tokens (19030ms)
    ✓ transfers: ether transfer should be reversed. (41641ms)
    1) transfers: should transfer 10000 to accounts[1] with accounts[0] having 10000

    Events emitted during test:
    ---------------------------

    Transfer(_from: <indexed>, _to: <indexed>, _value: 1999445)

    ---------------------------
    2) transfers: should fail when trying to transfer 10001 to accounts[1] with accounts[0] having 10000

    Events emitted during test:
    ---------------------------


    ---------------------------
    3) transfers: should handle zero-transfers normally
    > No events were emitted
    4) approvals: msg.sender should approve 100 to accounts[1]

    Events emitted during test:
    ---------------------------


    ---------------------------
    ✓ approvals: msg.sender should approve 100 to SampleRecipient and then NOTIFY SampleRecipient. It should succeed. (87628ms)
    ✓ approvals: msg.sender should approve 100 to SampleRecipient and then NOTIFY SampleRecipient and throw. (76595ms)
    5) approvals: msg.sender approves accounts[1] of 100 & withdraws 20 once.

    Events emitted during test:
    ---------------------------


    ---------------------------
    6) approvals: msg.sender approves accounts[1] of 100 & withdraws 20 twice.
    > No events were emitted
    7) approvals: msg.sender approves accounts[1] of 100 & withdraws 50 & 60 (2nd tx should fail)

    Events emitted during test:
    ---------------------------


    ---------------------------
    8) approvals: attempt withdrawal from acconut with no allowance (should fail)

    Events emitted during test:
    ---------------------------


    ---------------------------
    9) approvals: allow accounts[1] 100 to withdraw from accounts[0]. Withdraw 60 and then approve 0 & attempt transfer.

    Events emitted during test:
    ---------------------------


    ---------------------------
    10) approvals: approve max (2^256 - 1)
    > No events were emitted
    11) events: should fire Transfer event properly

    Events emitted during test:
    ---------------------------


    ---------------------------
    12) events: should fire Transfer event normally on a zero transfer
    > No events were emitted
    13) events: should fire Approval event properly
    > No events were emitted

  Contract: HumanStandardTokenFactory
    ✓ Verify a Human Standard Token once deployed using both verification functions. (75175ms)


  7 passing (17m)
  13 failing

  1) Contract: HumanStandardToken transfers: should transfer 10000 to accounts[1] with accounts[0] having 10000:
     Error: Error: Invalid number of arguments to Solidity function
      at HumanStandardToken.new.then.then.then.catch (test/humanStandardToken.js:74:31)
      at process._tickCallback (internal/process/next_tick.js:103:7)

  2) Contract: HumanStandardToken transfers: should fail when trying to transfer 10001 to accounts[1] with accounts[0] having 10000:
     AssertionError: the EVM did not throw an error or did not throw the expected error
      at HumanStandardToken.new.then.then.catch (test/humanStandardToken.js:85:7)
      at process._tickCallback (internal/process/next_tick.js:103:7)

  3) Contract: HumanStandardToken transfers: should handle zero-transfers normally:
     Error: Error: Invalid number of arguments to Solidity function
      at HumanStandardToken.new.then.then.catch (test/humanStandardToken.js:97:31)
      at process._tickCallback (internal/process/next_tick.js:103:7)

  4) Contract: HumanStandardToken approvals: msg.sender should approve 100 to accounts[1]:
     Error: Error: Invalid number of arguments to Solidity function
      at HumanStandardToken.new.then.then.then.catch (test/humanStandardToken.js:115:31)
      at process._tickCallback (internal/process/next_tick.js:103:7)

  5) Contract: HumanStandardToken approvals: msg.sender approves accounts[1] of 100 & withdraws 20 once.:
     Error: Error: Invalid number of arguments to Solidity function
      at HumanStandardToken.new.then.then.then.then.then.then.then.then.then.then.catch (test/humanStandardToken.js:181:31)
      at process._tickCallback (internal/process/next_tick.js:103:7)

  6) Contract: HumanStandardToken approvals: msg.sender approves accounts[1] of 100 & withdraws 20 twice.:
     Error: Error: Invalid number of arguments to Solidity function
      at HumanStandardToken.new.then.then.then.then.then.then.then.then.then.then.then.catch (test/humanStandardToken.js:218:31)
      at process._tickCallback (internal/process/next_tick.js:103:7)

  7) Contract: HumanStandardToken approvals: msg.sender approves accounts[1] of 100 & withdraws 50 & 60 (2nd tx should fail):
     AssertionError: the EVM did not throw an error or did not throw the expected error
      at HumanStandardToken.new.then.then.then.then.then.then.then.then.catch (test/humanStandardToken.js:248:7)
      at process._tickCallback (internal/process/next_tick.js:103:7)

  8) Contract: HumanStandardToken approvals: attempt withdrawal from acconut with no allowance (should fail):
     AssertionError: the EVM did not throw an error or did not throw the expected error
      at HumanStandardToken.new.then.then.catch (test/humanStandardToken.js:261:7)
      at process._tickCallback (internal/process/next_tick.js:103:7)

  9) Contract: HumanStandardToken approvals: allow accounts[1] 100 to withdraw from accounts[0]. Withdraw 60 and then approve 0 & attempt transfer.:
     AssertionError: the EVM did not throw an error or did not throw the expected error
      at HumanStandardToken.new.then.then.then.then.then.catch (test/humanStandardToken.js:280:7)
      at process._tickCallback (internal/process/next_tick.js:103:7)

  10) Contract: HumanStandardToken approvals: approve max (2^256 - 1):
     Error: Error: Invalid number of arguments to Solidity function
      at HumanStandardToken.new.then.then.then.catch (test/humanStandardToken.js:295:31)
      at process._tickCallback (internal/process/next_tick.js:103:7)

  11) Contract: HumanStandardToken events: should fire Transfer event properly:
     Error: Error: Invalid number of arguments to Solidity function
      at HumanStandardToken.new.then.then.catch (test/humanStandardToken.js:311:31)
      at process._tickCallback (internal/process/next_tick.js:103:7)

  12) Contract: HumanStandardToken events: should fire Transfer event normally on a zero transfer:
     Error: Error: Invalid number of arguments to Solidity function
      at HumanStandardToken.new.then.then.catch (test/humanStandardToken.js:327:31)
      at process._tickCallback (internal/process/next_tick.js:103:7)

  13) Contract: HumanStandardToken events: should fire Approval event properly:
     Error: Error: Invalid number of arguments to Solidity function
      at HumanStandardToken.new.then.then.catch (test/humanStandardToken.js:343:31)
      at process._tickCallback (internal/process/next_tick.js:103:7)

How to automatically exchange token for ether stored in the contract to pay the transaction fee of tokens between users of my token?

When I changed newTokenAddr to 0x0002, the test still passed.

These tests should be broken up, and also test for invalid verifications.

Also, the actual tests are not as thorough as the description.