Cannot run migration with fresh init using Geth (v5)

[kdelwat]

Issue

After initialising a new Truffle project, migration fails when deploying to a local geth testnet, even though it works with Ganache.

I suspect this is due to not using HDWalletProvider, but a clearer error message could be a good idea.

Steps to Reproduce

1. Install Truffle 5.0.0 beta
2. Run truffle init in an empty directory
3. Edit truffle-config.js to add a development network:

  networks: {
    // Useful for testing. The `development` name is special - truffle uses it by default
    // if it's defined here and no other network is specified at the command line.
    // You should run a client (like ganache-cli, geth or parity) in a separate terminal
    // tab if you use this network and you must also set the `host`, `port` and `network_id`
    // options below to some value.
    //
    development: {
     host: "localhost",     // Localhost (default: none)
     port: 8545,            // Standard Ethereum port (default: none)
     network_id: "*",       // Any network (default: none)
    },

4. Start a local geth node.
5. Run truffle migrate

Expected Behavior

The migration should complete successfully.

Actual Results

The migration failed with the following error:

Error: Number can only safely store up to 53 bits
    at assert (/home/cadel/.nvm/versions/node/v9.11.1/lib/node_modules/truffle/build/webpack:/~/number-to-bn/~/bn.js/lib/bn.js:6:1)
    at BN.toNumber (/home/cadel/.nvm/versions/node/v9.11.1/lib/node_modules/truffle/build/webpack:/~/number-to-bn/~/bn.js/lib/bn.js:506:1)
    at Object.hexToNumber (/home/cadel/.nvm/versions/node/v9.11.1/lib/node_modules/truffle/build/webpack:/~/web3-utils/src/utils.js:234:1)
    at Method.outputBlockFormatter [as outputFormatter] (/home/cadel/.nvm/versions/node/v9.11.1/lib/node_modules/truffle/build/webpack:/~/web3-eth/~/web3-core-helpers/src/formatters.js:236:1)
    at Method.formatOutput (/home/cadel/.nvm/versions/node/v9.11.1/lib/node_modules/truffle/build/webpack:/~/web3-eth/~/web3-core-method/src/index.js:163:1)
    at sendTxCallback (/home/cadel/.nvm/versions/node/v9.11.1/lib/node_modules/truffle/build/webpack:/~/web3-eth/~/web3-core-method/src/index.js:476:1)
    at /home/cadel/.nvm/versions/node/v9.11.1/lib/node_modules/truffle/build/webpack:/~/web3-eth/~/web3-core-requestmanager/src/index.js:147:1
    at /home/cadel/.nvm/versions/node/v9.11.1/lib/node_modules/truffle/build/webpack:/packages/truffle-provider/wrapper.js:101:1
    at XMLHttpRequest.request.onreadystatechange (/home/cadel/.nvm/versions/node/v9.11.1/lib/node_modules/truffle/build/webpack:/~/web3/~/web3-providers-http/src/index.js:79:1)
    at XMLHttpRequestEventTarget.dispatchEvent (/home/cadel/.nvm/versions/node/v9.11.1/lib/node_modules/truffle/build/webpack:/~/xhr2-cookies/dist/xml-http-request-event-target.js:34:1)
    at XMLHttpRequest._setReadyState (/home/cadel/.nvm/versions/node/v9.11.1/lib/node_modules/truffle/build/webpack:/~/xhr2-cookies/dist/xml-http-request.js:208:1)
    at XMLHttpRequest._onHttpResponseEnd (/home/cadel/.nvm/versions/node/v9.11.1/lib/node_modules/truffle/build/webpack:/~/xhr2-cookies/dist/xml-http-request.js:318:1)
    at IncomingMessage.<anonymous> (/home/cadel/.nvm/versions/node/v9.11.1/lib/node_modules/truffle/build/webpack:/~/xhr2-cookies/dist/xml-http-request.js:289:47)
    at IncomingMessage.emit (events.js:185:15)
    at endReadableNT (_stream_readable.js:1106:12)
    at process._tickCallback (internal/process/next_tick.js:178:19)

Environment

• Operating System: Ubuntu (Windows Subsystem for Linux)
• Ethereum client: geth 1.8.13
• Truffle version: Truffle v5.0.0-beta.0 (core: 5.0.0-beta.0)
• Solidity version: Solidity v0.4.24 (solc-js)
• node version: v9.11.1
• npm version: 5.6.0

[cgewecke]

@kdelwat Agree this message is not good. . . could you see if it works if you specify an unlocked from address in your network config? Also did you see any other output?

[cgewecke]

@kdelwat One more thing - we run migrations in CI against geth --dev.

• there's a test specifically for the truffle init case here
• the geth client launch script is here

If you could identify any differences between your setup and ours that would be really helpful - would like to squash this if possible.

[kdelwat]

@cgewecke Thanks for the help, I've done some digging and think it stems from something in the Geth genesis block.

These are my geth options:

geth
--port 38545 \
--mine \
--minerthreads=1 \
--rpc \
--rpcport 8545 \
--rpccorsdomain "*" \
--datadir ~/.testnet/data/ \
--port 30303 \
--nodiscover \
--rpcapi web3,eth,net,debug \
--networkid 99 \
--unlock 0x1ccb322887b44f43f2775965b3397c180d2b3275 \
console

Using the following genesis block (from here) works perfectly:

{
  "config": {
    "chainId": 15,
    "homesteadBlock": 0,
    "eip155Block": 0,
    "eip158Block": 0
  },
  "nonce": "0x0000000000000042",
  "timestamp": "0x0",
  "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "gasLimit": "0x8000000",
  "difficulty": "0x400",
  "mixhash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "coinbase": "0x3333333333333333333333333333333333333333",
  "alloc": {
    "0x1ccb322887b44f43f2775965b3397c180d2b3275": {
      "balance": "0x5337000000000000000000"
    }
  }
}

However, the Geth node I was using was created with dapptools, which generated this genesis:

{
  "alloc": {
    "0x1ccb322887b44f43f2775965b3397c180d2b3275": {
      "balance": "0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff"
    }
  },
  "config": {
    "byzantiumBlock": 0,
    "chainId": 99,
    "clique": { "epoch": 3000, "period": 0 },
    "eip155Block": 0,
    "eip158Block": 0,
    "homesteadBlock": 0
  },
  "difficulty": "0x1",
  "extraData": "0x3132333400000000000000000000000000000000000000000000000000000000ca38c3972e3e6c0c09f9baceeeebefb92a00f7410000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  "gaslimit": "0xffffffffffffffff"
}

I've confirmed directly with Geth that the second genesis block ends in the issue described above, whereas the first doesn't. I can't pin down the issue unfortunately 😞

Since this appears to be an issue with Geth rather than Truffle, this issue can probably be closed.

[cgewecke]

Ah super interesting. The only issue see at web3 triggering a similar failure is something about Quorum client timestamps where quorum is using Unix nano-second precision.

That DappTools starting balance is pretty big - I wonder if that's a possible problem. They're solidity based so they don't have to worry about translating values out to JS.

Thanks for opening, hopefully someone will find this and figure it out.