2

I set up a geth full node on Rinkeby with the following command: /usr/bin/geth --syncmode fast --nousb --cache 3072 --trie-cache-gens 1024 --rpc --rpcaddr 127.0.0.1 --rpcport 8545 --networkid 4 2>&1

(Geth is version 1.8.12)

This should be Rinkeby, although when I get the current block:

> eth.blockNumber
3922099

This doesn't seem to match what's on Etherscan, where the most recently mined block as of this posting was 2601444 for Rinkeby, 3596981 for Ropsten, 5930232 for mainnet.

> eth.syncing
{
  currentBlock: 3922035,
  highestBlock: 3922099,
  knownStates: 11714163,
  pulledStates: 11714163,
  startingBlock: 0
}

In addition, Rinkeby's ChainData size should by ~50GB if I'm not mistaken, and:

$ du -sh chaindata
13G chaindata

So I'm scratching my head a bit: what accounts or the discrepancies in blockNumber and ChainData size?

Any thoughts are greatly appreciated!

ambertch
  • 151
  • 5
  • Look for chainId when you execute admin.nodeInfo from geth's console. The id of 4 should be rinkeby as you say (look for others ids https://ethereum.stackexchange.com/a/17101). – Ismael Jul 09 '18 at 03:17
  • Thanks, got it. Looks like there is a discrepancy in configuration somewhere: during node initialization there is a reference to chainId of 1, then network id of 4

    Initialised chain configuration config="{ChainID: 1... ... Initialising Ethereum protocol versions="[63 62]" network=4

     – ambertch Jul 10 '18 at 21:01
  • Also you can pass parameters --testnet and --rinkeby to geth to select the network you want to connect to. I'd expect that --networkid to be more generic and override the default selection it appears to not be the case. – Ismael Jul 10 '18 at 22:50
  • Yes, that was the issue: I was passing network but not --rinkeby, and it connected to ChainID 1. Thanks! – ambertch Jul 11 '18 at 23:25

1 Answers1

3

so, Ethereum has both a chain ID and network ID. Setting network ID only sets the latter, while passing in --rinkeby or --testnet correctly sets both

ambertch
  • 151
  • 5